《性能优化课堂笔记和培训心得.docxVIP

软件性能优化心得体会随着企业级开发平台诸如J2EE的普及和发展，越来越多的企业应用采用了这些技术作为快速开发平台，但是，这些应用也面临着一些困扰，特别是性能问题。这主要是由这些系统的分布性、复杂性和数据无关性引起的。高性能是软件高质量的重要体现，也是用户满意度提高的重要软件特征，为了提高软件的性能，在这次培训中，老师从以下几个层次讨论软件性能优化。Java底层代码的性能优化1、首先根据Jvm虚拟机的内存机制来优化系统堆（Heap）是一个复杂的结构，对象及其成员通常保存在堆中。运行时在数据区, 动态创建，堆中的内容由 GC 负责回收。栈（Stack）是一个简单的结构，方法的参数（基本型别的值、指向对象的引用）通常保存在栈中。栈中的内容在方法执行完时就被回收了。栈的存取速度比堆要快,栈数据可以共享,存在栈中的数据大小与生存期必须是确定的,栈中主要存放一些基本类型的变量（,int, short, long, byte, float, double, boolean, char）和对象句柄。使用局部变量的好处在于作用范围是变量定义的方法内部，一旦离开作用域，栈内存将被快速释放，与GC无关，而其他变量，如静态变量、实例变量等，都在堆（Heap）中创建，速度较慢，但是可以自动回收。所以要尽量使用局部变量。在这里，培训的老师举了个人例子A for(int i=0;i10000; i++){Object o = new Object();}BObject o = null; for(int i=0;i10000; i++){o = new Object();}A和B之间究竟哪个性能更加好呢？在这里A和B的唯一区别在于，B在循环体外定义Object，而A是在循环体内定义Object，显然A的Object作用域是在局部，一旦执行下一轮循环，立即释放原先定义的Object，而B的Object作用域是在全局，必须等到循环全部结束，Object才能被释放，因此A的性能要好于B，而且两者运行速度不是一个数量级。2、需要慎用异常处理机制因为异常只能用于错误处理，不适合用来控制流程，抛出异常的同时，系统往往会创建一个新的对象，只要有异常被抛出，VM就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。这样对系统的性能会造成一定的影响，因此，要尽量少用自定义的异常抛出机制。3、使用多线程会提高系统的性能，但是处理多线程的时候，为了防止资源竞争，需要加锁。一般锁是Synchronized，jdk 1.5 版本多加了个ReetrantLock，我查阅了官方说明：重入锁（ReentrantLock）是一种递归无阻塞的同步机制，它可重入的互斥锁定 Lock，它具有与使用 synchronized 方法和语句所访问的隐式监视器锁定相同的一些基本行为和语义，但功能更强大。ReentrantLock 将由最近成功获得锁定，并且还没有释放该锁定的线程所拥有。当锁定没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁定并返回。如果当前线程已经拥有该锁定，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。虽然 ReentrantLock 是个非常动人的实现，相对 synchronized 来说，它有一些重要的优势，但是我认为急于把 synchronized 视若敝屣，绝对是个严重的错误。 java.util.concurrent.lock 中的锁定类是用于高级用户和高级情况的工具。一般来说，除非对 Lock 的某个高级特性有明确的需要，或者有明确的证据（而不是仅仅是怀疑）表明在特定情况下，同步已经成为可伸缩性的瓶颈，否则还是应当继续使用 synchronized。为什么在一个显然“更好的”实现的使用上主张保守呢？因为对于 java.util.concurrent.lock 中的锁定类来说，synchronized 仍然有一些优势。比如，在使用 synchronized 的时候，不能忘记释放锁；在退出 synchronized 块时，JVM 会为你做这件事。很容易忘记用 finally 块释放锁，这对程序非常有害。你的程序能够通过测试，但会在实际工作中出现死锁，那时会很难指出原因（这也是为什么根本不让初级开发人员使用 Lock 的一个好理由。）另一个原因是因为，当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。 Lock 类只是普通的类，JVM 不知道具体哪个线程拥有 Lock 对象。而且，几乎每个开发人员都熟悉 synchronized，它可以在 JVM 的所有版本