WebLogic平台下J2EE调优攻略.doc

文档名称 第  PAGE 30 页 共  NUMPAGES 30 页 前 言 　　随着近来J2EE软件广泛地应用于各行各业，系统调优也越来越引起软件开发者和应用服务器提供商的重视。而对于最终客户来说，在一个高效、稳定地实现他们的业务需求已经是他们的基本要求。所以J2EE调优显得非常重要，而BEA webLogic Server是业界领先的应用服务器，BEA webLogic平台下的J2EE调优也就尤为重要,她将为我们提供普遍的J2EE调优方案。最近网络、杂志上的J2EE调优文章层出不穷。本人也将自己平时工作中的一些经验积累分享给大家，抛砖引玉。　　本文从J2EE应用架构（下图）来分别剖析系统调优，首先我们一般会从应用程序出发，去审核代码，做到代码级的优化，然后再调整应用服务器(BEA webLogic8.1)和数据库 (Oracle9i)的参数，最后当然是调整操作系统和网络的性能(包括硬件升级)。诚然,在我遇到的很多项目中,都是出现了性能问题后才想到调优,而且一般都是先进行系统参数调整,实在解决不了才会对代码进行检查.实际上,我们应当将代码级的调优放在应用设计时来做,测试生产时修改代码将是一件极其痛苦的事情。 webLogic平台J2EE应用架构 第一章 应用程序调优 通用代码调优 减小没有必要的操作 　　对象的创建是个很昂贵的工作,所以我们应当尽量减少对象的创建,在需要的时候声明它,初 始化它,不要重复初始化一个对象,尽量能做到再使用,而用完后置null有利于垃圾收集。让类实现Cloneable接口,同时采用工厂模式,将减少类的创建,每次都是通过clone()方法来获得对象。另外使用接口也能减少类的创建。对于成员变量的初始化也应尽量避免, 特别是在一个类派生另一个类时。　　异常抛出对性能不利。抛出异常首先要创建一个新的对象。Throwable接口的构造函数调用名为, fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，VM就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。 异常只能用于错误处理，不应该用来控制程序流程。　　此外, 建议关闭Debug输出,尽量少用串行化、同步操作和耗时昂贵的服务(如Date())。 使用合适的类型 　　当原始类型不能满足我们要求时,使用复杂类型。String和StringBuffer的区别自不必说了,是我们使用最多的类型,在涉及到字符运算时,强烈建议使用StringBuffer。在做String匹配时使用intern()代替equal()。　　带有final修饰符的类是不可派生的, 如果指定一个类为final，则该类所有的方法都是final。　　java编译器会寻找机会内联所有的final方法,这将能够使性能平均提高50%。类的属性和方式使用final或者static修饰符也是有好处的。　　调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快。所以尽量使用局部变量。　　ArrayList和Vector,HashMap和Hashtable是我们经常用到的类,前者不支持同步,后者支持同步,前者性能更好,大多数情况下选择前者。 尽量使用pool,buffer和cache 　　使用pool、buffer和cache能大大提高系统的性能,这在J2EE的大部分技术中都是适用的。　　在webLogic中就大量使用了池:JDBC Connection Pool、Socket Pool、Object Pool和Thread Pool。I/O操作中,buffer是必须的,特别是对大文件的操作,不然容易造成内存溢出。字节操作最快,所以尽可能采用write(byte[])，Buffered FileOutputStream比Buffered FileWriter要快,因为FileWriter需要Unicode到Byte的转换。　　而后面讲到的JDBC、jsp、EJB和JMS我们都非常建议使用buffer和cache。为HttpServletResponse设置buffersize,使用wl-cache,缓存在JNDI树上获取的对象等等。　　此外,使用JDK 1.4的非阻塞I/O对性能也有很大提高。  JDBC代码调优 严格资源使用 　　JDBC代码调优最大的原则就是使用webLogic的连接池,而不是自己直连数据库。在我接触的很多自己实现连接池的项目中,大部分遇到死锁和连接泄漏的问题，最后得不得修改代码。而webLogic提供了功能强大，性能良好的数据库连接池，我们要做的只是封装一个连接管理类，从JNDI树