开发晋级篇:Java性能优化技巧集锦
2008-01-05 10:37:56 来源:WEB开发网核心提示:1.1 不用new要害词创建类的实例用new要害词创建类的实例时,构造函数链中的所有构造函数都会被自动调用,开发晋级篇:Java性能优化技巧集锦,但假如一个对象实现了Cloneable接口,我们可以调用它的clone()方法,似乎只有一个答案比较理想:结合运用RMI和JNDI,先通过RMI注册把RMI远程对象绑定到JN
1.1 不用new要害词创建类的实例
用new要害词创建类的实例时,构造函数链中的所有构造函数都会被自动调用。但假如一个对象实现了Cloneable接口,我们可以调用它的clone()方法。clone()方法不会调用任何类构造函数。
在使用设计模式(Design Pattern)的场合,假如用Factory模式创建对象,则改用clone()方法创建新的对象实例非常简单。例如,下面是Factory模式的一个典型实现:
public static Credit getNewCredit()
{
return new Credit();
}
改进后的代码使用clone()方法,如下所示:
PRivate static Credit
BaseCredit = new Credit();
public static Credit getNewCredit()
{
return (Credit) BaseCredit.clone();
}
上面的思路对于数组处理同样很有用。
1.2 使用非阻塞I/O
版本较低的JDK不支持非阻塞I/O API。为避免I/O阻塞,一些应用采用了创建大量线程的办法(在较好的情况下,会使用一个缓冲池)。这种技术可以在许多必须支持并发I/O流的应用中见到,如Web服务器、报价和拍卖应用等。然而,创建java线程需要相当可观的开销。
JDK 1.4引入了非阻塞的I/O库(java.nio)。假如应用要求使用版本较早的JDK,在这里有一个支持非阻塞I/O的软件包。
1.3 慎用异常
异常对性能不利。抛出异常首先要创建一个新的对象。Throwable接口的构造函数调用名为fillInStackTrace()的本地(Native)方法,fillInStackTrace()方法检查堆栈,收集调用跟踪信息。只要有异常被抛出,VM就必须调整调用堆栈,因为在处理过程中创建了一个新的对象。
异常只能用于错误处理,不应该用来控制程序流程。
1.4 不要重复初始化变量
默认情况下,调用类的构造函数时, Java会把变量初始化成确定的值:所有的对象被设置成null,整数变量(byte、short、int、long)设置成0,float和double变量设置成0.0,逻辑值设置成false。当一个类从另一个类派生时,这一点尤其应该注重,因为用new要害词创建一个对象时,构造函数链中的所有构造函数都会被自动调用。
1.5 尽量指定类的final修饰符
带有final修饰符的类是不可派生的。在Java核心API中,有许多应用final的例子,例如java.lang.String。为String类指定final防止了人们覆盖length()方法。
另外,假如指定一个类为final,则该类所有的方法都是final。Java编译器会寻找机会内联(inline)所有的final方法(这和具体的编译器实现有关)。此举能够使性能平均提高50%。
1.6 尽量使用局部变量
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈(Stack)中,速度较快。其他变量,如静态变量、实例变量等,都在堆(Heap)中创建,速度较慢。另外,依靠于具体的编译器/JVM,局部变量还可能得到进一步优化。请参见《尽可能使用堆栈变量》。
1.7 乘法和除法
考虑下面的代码:
for (val = 0;
val < 100000; val +=5)
{
alterX = val * 8;
myResult = val * 2;
}
用移位操作替代乘法操作可以极大地提高性能。下面是修改后的代码:
for (val = 0;
val < 100000;
val += 5)
{
alterX = val << 3;
myResult = val << 1;
}
修改后的代码不再做乘以8的操作,而是改用等价的左移3位操作,每左移1位相当于乘以2。相应地,右移1位操作相当于除以2。值得一提的是,虽然移位操作速度快,但可能使代码比较难于理解,所以最好加上一些注释。
二、J2EE篇
前面介绍的改善性能技巧适合于大多数Java应用,接下来要讨论的问题适合于使用jsp、EJB或JDBC的应用。
2.1 使用缓冲标记
一些应用服务器加入了面向JSP的缓冲标记功能。例如,BEA的WebLogic Server从6.0版本开始支持这个功能,Open Symphony工程也同样支持这个功能。JSP缓冲标记既能够缓冲页面片断,也能够缓冲整个页面。当JSP页面执行时,假如目标片断已经在缓冲之中,则生成该片断的代码就不用再执行。
页面级缓冲捕捉对指定URL的请求,并缓冲整个结果页面。对于购物篮、目录以及门户网站的主页来说,这个功能极其有用。对于这类应用,页面级缓冲能够保存页面执行的结果,供后继请求使用。
对于代码逻辑复杂的页面,利用缓冲标记提高性能的效果比较明显;反之,效果可能略逊一筹。
2.2 始终通过会话Bean访问实体Bean
直接访问实体Bean不利于性能。当客户程序远程访问实体Bean时,每一个get方法都是一个远程调用。访问实体Bean的会话Bean是本地的,能够把所有数据组织成一个结构,然后返回它的值。
用会话Bean封装对实体Bean的访问能够改进事务治理,因为会话Bean只有在到达事务边界时才会提交。每一个对get方法的直接调用产生一个事务,容器将在每一个实体Bean的事务之后执行一个“装入-读取”操作。
一些时候,使用实体Bean会导致程序性能不佳。假如实体Bean的唯一用途就是提取和更新数据,改成在会话Bean之内利用JDBC访问数据库可以得到更好的性能。
2.3 选择合适的引用机制
在典型的JSP应用系统中,页头、页脚部分往往被抽取出来,然后根据需要引入页头、页脚。当前,在JSP页面中引入外部资源的方法主要有两种:include指令,以及include动作。
include指令:例如。该指令在编译时引入指定的资源。在编译之前,带有include指令的页面和指定的资源被合并成一个文件。被引用的外部资源在编译时就确定,比运行时才确定资源更高效。
include动作:例如。该动作引入指定页面执行后生成的结果。由于它在运行时完成,因此对输出结果的控制更加灵活。但时,只有当被引用的内容频繁地改变时,或者在对主页面的请求没有出现之前,被引用的页面无法确定时,使用include动作才合算。
2.4 在部署描述器中设置只读属性
实体Bean的部署描述器答应把所有get方法设置成“只读”。当某个事务单元的工作只包含执行读取操作的方法时,设置只读属性有利于提高性能,因为容器不必再执行存储操作。
2.5 缓冲对EJB Home的访问
EJB Home接口通过JNDI名称查找获得。这个操作需要相当可观的开销。JNDI查找最好放入Servlet的init()方法里面。假如应用中多处频繁地出现EJB访问,最好创建一个EJBHomeCache类。EJBHomeCache类一般应该作为singleton实现。
2.6 为EJB实现本地接口
本地接口是EJB 2.0规范新增的内容,它使得Bean能够避免远程调用的开销。请考虑下面的代码。
PayBeanHome home = (PayBeanHome)
javax.rmi.PortableRemoteObject.narrow
(ctx.lookup ("PayBeanHome"), PayBeanHome.class);
PayBean bean = (PayBean)
javax.rmi.PortableRemoteObject.narrow
(home.create(), PayBean.class);
第一个语句表示我们要寻找Bean的Home接口。这个查找通过JNDI进行,它是一个RMI调用。然后,我们定位远程对象,返回代理引用,这也是一个RMI调用。第二个语句示范了如何创建一个实例,涉及了创建IIOP请求并在网络上传输请求的stub程序,它也是一个RMI调用。
要实现本地接口,我们必须作如下修改:
方法不能再抛出java.rmi.RemoteException异常,包括从RemoteException派生的异常,比如TransactionRequiredException、TransactionRolledBackException和NoSUChObjectException。
EJB提供了等价的本地异常,如TransactionRequiredLocalException、TransactionRolledBackLocalException和NoSuchObjectLocalException。所有数据和返回值都通过引用的方式传递,而不是传递值。
本地接口必须在EJB部署的机器上使用。简而言之,客户程序和提供服务的组件必须在同一个JVM上运行。假如Bean实现了本地接口,则其引用不可串行化。
2.7 生成主键
在EJB之内生成主键有许多途径,下面分析了几种常见的办法以及它们的特点。利用数据库内建的标识机制(SQL Server的IDENTITY或Oracle的SEQUENCE)。这种方法的缺点是EJB可移植性差。由实体Bean自己计算主键值(比如做增量操作)。它的缺点是要求事务可串行化,而且速度也较慢。
利用NTP之类的时钟服务。这要求有面向特定平台的本地代码,从而把Bean固定到了特定的OS之上。另外,它还导致了这样一种可能,即在多CPU的服务器上,同一个毫秒之内生成了两个主键。
借鉴Microsoft的思路,在Bean中创建一个GUID。然而,假如不求助于JNI,Java不能确定网卡的MAC地址;假如使用JNI,则程序就要依靠于特定的OS。
还有其他几种办法,但这些办法同样都有各自的局限。似乎只有一个答案比较理想:结合运用RMI和JNDI。先通过RMI注册把RMI远程对象绑定到JNDI树。客户程序通过JNDI进行查找。下面是一个例子:
public class keyGenerator extends
UnicastRemoteObject implements Remote
{
private static long KeyValue =
System.currentTimeMillis();
public static synchronized long ge
[]
赞助商链接