讲述J2EE系统优化的几点体会

核心提示：说到系统优化，是一个比较复杂的问题，讲述J2EE系统优化的几点体会，涉及到软件的各个方面：需求、模块划分、数据库设计、程序编码以及一些非凡的优化方法如缓存技术等，而不同的应用又有其非凡的优化策略和技术，假如为-1则跳出循环，这个例子告诉我们：对循环一定要搞清循环的循环规模、每次循环体执行时间、循环结束条件包括异常情况等

　　说到系统优化，是一个比较复杂的问题，涉及到软件的各个方面：需求、模块划分、数据库设计、程序编码以及一些非凡的优化方法如缓存技术等。而不同的应用又有其非凡的优化策略和技术。同时优化是贯穿系统从需求到实现再到维护的各个阶段的一项活动，而在各个阶段又有其不同的着眼点和具体方法。
　　
　　本文立足于具体的J2EE项目实践，结合一些已有的优化条例，提出自己的一些体会，也算是作为一次对实际项目经验教训的总结。
　　
　　优化一般意义上说是提高已有系统的性能，减少如内存、数据库、网络带宽等资源的占用，是在系统开发告一段落的前提下进行。一般是通过压力测试或具体使用发现性能方面的问题，然后寻找性能瓶颈，并结合项目进度、人员安排、技术储备等因素，提出相应的优化策略。
　　
　　下面结合一些案例，进行具体的讨论，并希望能总结出一些具有代表性的条例：
　　
　　条例一：尽量重用对象，避免创建过多短时对象
　　
　　对象在面向对象编程中随处可见，甚至可以毫不夸张的说是：“一切都是对象”。如何更好的创建和使用对象，是优化中要考虑的一个重要方面。笔者将对象按使用分为两大类：独享对象和共享对象。独享对象指由某个线程单独拥有并维护其生命周期的对象，一般是通过new 创建的对象，线程结束且无其它对这个对象的引用，这个对象将由垃圾收集机制自动GC。共享对象指由多个线程共享的对象，各线程保持多个指向同一个对象的引用，任何对这个对象的修改都会在其它引用上得到体现，共享对象一般通过Factory工厂的getInstace()方法创建，单例模式就是创建共享对象的标准实现。独享对象由于无其它指向同一对象的引用，不用担心其它引用对对象属性的修改，在多线程环境里，也就不需要对其可能修改属性的方法加以同步，减少了出错的隐患和复杂性，但由于需要为每个线程都创建对象，增加了对内存的需求和JVM GC的负担。共享对象则需要进行适当的同步（避免较大的同步块，同时防止死锁）。
　　
　　还有几种非凡对象：不变对象和方法对象。不变对象指对象对外不含有修改对象属性的方法（如set方法），外部要修改属性只能通过new新的实例来实现。不变对象最大的好处就是无需担心属性被修改，避免了潜在的bug，并能无需任何额外工作（如同步）就很好的工作在多线程环境下。如jdk的String对象就是典型的不变对象。方法对象简单的说就是仅包含方法，不含有属性的对象。由于没有对象属性，方法中无需进行修改属性的操作，也就能采用static方法或单例模式，避免每次使用都要new对象，减少对象的使用。
　　
　　那么该如何确定创建何种对象，这就要结合对象的使用方式和生命周期、对象大小、构建花销等方面来综合考虑。假如对象生命周期较长，会存在修改操作，不能容忍其它线程对其的修改，就应该采用独享对象，如常见的Bean类。而假如对象生命周期较长，且能为各个线程共享，就可以考虑共享对象。共享有2种常见情况，一种是系统全局对象，如配置属性等，各个线程应该引用同一对象，任何对这个对象的修改都会影响其它线程；另一种是由于对象创建开销较大，各线程对此对象是瞬时访问，且无需再次读取其属性，如常见的Date 对象，一般这种对象的使用是瞬时的，比如把它format成String，假如每次创建然后等待GC就会浪费大量内存和CPU时间，较好做法就是做成共享对象，各个线程先set再使用，注重对进行set并访问的方法要同步。不变对象一般使用在对象创建开销较小（属性较少，类层次较少），且需要能自由共享的情形。如一个对象里的常量对象，使用public static final AAA=new AAA(…) 创建。方法对象使用较广，如Util类、DAO类等，这些对象提供操作其它对象(一般是bean对象)的接口，能对系统在层次和功能上进行解耦合。
　　
　　条例二：在循环处，多下功夫
　　
　　循环作为程序编写的基本语法，可以说是随处可见。一些小的细节能带来性能上的提升，而对循环体的一些改写，能带来性能的大幅提升。
　　
　　比如最简单的List遍历，会有这样的写法：for(int i=0;i
　　
　　同样是对List的操作，假如要在遍历同时进行增加和删除操作，代码如下：for(int i=0,j=l.size();i=0;i--){l.remove(i);}。经过测试，假如采用ArrayList，两种写法在循环次数较少时没有太大的区别，循环次数为1000，均为1ms以内，次数为10000，前一种为60ms左右，后一种为1ms以内，，而次数上到100000，前一种为6000ms左右，后一种为15ms，随着循环次数的增多，后一种较前一种的效率优势明显提高。
　　
　　这是由Collection库ArrayList的实现决定的，以下是jdk1.3的ArrayList源码：
　　
　　public Object remove(int index) {
　　RangeCheck(index);
　　modCount++;
　　Object oldValue = elementData[index];
　　int numMoved = size - index - 1;
　　if (numMoved > 0)
　　System.arraycopy(elementData, index+1, elementData, index,
　　numMoved);
　　elementData[--size] = null; // Let gc do its work
　　return oldValue;
　　}
　　
　　从中我们可以看出，numMoved代表了需要进行arraycopy操作的数量，它是由remove的位置决定的，假如index＝0，也就是删除第一个元素，则需要arraycopy后面的所有数据，
　　
　　而假如index＝size-1，则只需将最后一个元素设为null即可。所以从后面向前循环remove是比较好的写法。
　　
　　假如List中的确存在较多的add或remove操作，且容量较大（如存储几万个对象），则应该采用LinkedList作为实现。LinkedList内部采用双向链表作为数据结构，比ArrayList占用较多内存空间，且随机访问操作较慢（需要从头或尾循环到相应位置），但插入删除操作很快（仅需进行链表操作，无须大量移动或拷贝）。
　　
　　对于List操作假如循环规模较小，其实对性能影响非常小（ms级），远远不是性能瓶颈所在。但心中有着优化的意识，并力求写出简洁高效的程序应该是我们每个程序员的追求。而且一旦在循环规模较大时，假如有了这些意识，也就能有效的消除性能隐患。
　　
　　再举一个与优化无关但确实可能成为性能杀手（可以说是bug）的循环的例子。下面是源代码：
　　
　　for(; totalRead < m_totalBytes; totalRead += readBytes)
　　{
　　readBytes = m_request.getInputStream().read(m_binArray, totalRead, m_totalBytes - totalRead);
　　}
　　
　　这个代码意图很清楚，就是将一个InputStream流读到一个byte数组中去。它使用read方法循环读取InputStream，该方法返回读取的字节数。正常情况下，该循环运行良好，当totalRead＝m_totalBytes时，结束循环，byte数组被正常填充。但假如仔细看一下InputStream的read方法的说明，了解一下其返回值就会发现，返回值可能为－1，即已读到InputStream末尾再继续读时。假如发生读取异常，可能出现这个问题，而这个循环没有检查readBytes值是否为－1就往totalRead上加，这样再次进入循环体继续读取InputStream，又返回－1，继续循环。如此循环直到int溢出才会跳出循环。而这个循环也就成了实实在在的CPU杀手，可以占去大量的CPU时间（取决于操作系统）。其实解决很简单，对readBytes进行判定，假如为-1则跳出循环。
　　
　　这个例子告诉我们：对循环一定要搞清循环的循环规模、每次循环体执行时间、循环结束条件包括异常情况等，只有这样才能写出高效且没有隐患的代码。