J2EE网站开发与优化如何提高代码运行效率
下面讨论的J2EE问题适合于使用JSP（Java Server Pages）、EJB(Enterprise JavaBean)或JDBC（Java Data Base Connectivity,java数据库连接）的应用。


    一、使用缓冲标记


    一些应用服务器加入了面向JSP的缓冲标记功能。例如，BEA的WebLogic Server从6.0版本开始支持这个功能，Open Symphony工程也同样支持这个功能。JSP缓冲标记既能够缓冲页面片断，也能够缓冲整个页面。当JSP页面执行时，如果目标片断已经在缓冲之中，则 生成该片断的代码就不用再执行。页面级缓冲捕获对指定URL的请求，并缓冲整个结果页面。对于购物篮、目录以及门户网站的主页来说，这个功能极其有用。对于这类应用，页面级缓冲能够保存页面执行的结果，供后继请求使用。


    对于代码逻辑复杂的页面，利用缓冲标记提高性能的效果比较明显；反之，效果可能略逊一筹。


    二、始终通过会话Bean访问实体Bean


    直接访问实体Bean不利于性能。当客户程序远程访问实体Bean时，每一个get方法都是一个远程调用。访问实体Bean的会话Bean是本地的， 能够把所有数据组织成一个结构，然后返回它的值。


    用会话Bean封装对实体Bean的访问能够改进事务管理，因为会话Bean只有在到达事务边界时才会提交。每一个对get方法的直接调用产生一个事务，容器将在每一个实体Bean的事务之后执行一个“装入-读取”操作。


    一些时候，使用实体Bean会导致程序性能不佳。如果实体Bean的唯一用途就是提取和更新数据，改成在会话Bean之内利用JDBC访问数据库可以得到更好的性能。


    三、选择合适的引用机制


    在典型的JSP应用系统中，页头、页脚部分往往被抽取出来，然后根据需要引入页头、页脚。当前，在JSP页面中引入外部资源的方法主要有两种： include指令，以及include动作。


    include指令：例如该指令在编译时引入指定的资源。在编译之前，带有include指令的页面和指定的资源被合并成一个文件。被引用的外部资源在编译时就确定，比运行时才确定资源更高效。


    include动作：例如该动作引入指定页面执行后生成的结果。由于它在运行时完成，因此对输出结果的控制更加灵活。但时，只有当被引用的内容频繁地改变时，或者在对主页面的请 求没有出现之前，被引用的页面无法确定时，使用include动作才合算。


    四、在部署描述器中设置只读属性


    实体Bean的部署描述器允许把所有get方法设置成“只读”。当某个事务单元的工作只包含执行读取操作的方法时，设置只读属性有利于提高性能，因为容器不必再执行存储操作。


    五、缓冲对EJB Home的访问


    EJB Home接口通过JNDI名称查找获得。这个操作需要相当可观的开销。JNDI查找最好放入Servlet的init()方法里面。如果应用中多处频繁地 出现EJB访问，最好创建一个EJBHomeCache类。EJBHomeCache类一般应该作为singleton实现。


    六、为EJB实现本地接口


    本地接口是EJB 2.0规范新增的内容，它使得Bean能够避免远程调用的开销。所有数据和返回值都通过引用的方式传递，而不是传递值。本地接口必须在EJB部署的机器上使用。简而言之，客户程序和提供服务的组件必须在同一个JVM上运行。如果Bean实现了本地接口，则其引用不可串行化。


    七、生成主键


    在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进行查找。


    八、及时清除不再需要的会话


    许多通常的Java性能问题都起源于在设计过程早期中的类设计的思想, 早在许多开发者开始考虑性能问题之前. 在这个系列中, Brian Goetz 讨论了通常的 Java 性能上的冒险以及怎么在设计时候避免它们. 在第二部分, 他讨论了减少临时对象创建的一些技术。


    虽然许多程序员把性能管理一直推迟到开发过程的最后, 性能考虑应该从第一天起就和设计周期结合在一起. 这个系列探索一些早期的设计思想能够极大影响应用程序性能的方法.所以下面继续探索大量临时对象创建的问题, 并且提供一些避免它们的技术.


    临时对象就是一些生命周期比较短的对象, 一般用于保存其他数据而再没有其他用途. 程序员一般用临时变量向一个方法传递数据或者从一个方法返回数据. 第一部分探讨了临时对象是怎样给一个程序的性能带来负面的冲击, 以及一些类接口的设计思想怎样提供了临时对象的创建. 避免了那些接口的创建, 你就能极大地减少那些影响你的程序性能的临时对象创建的需求。


    那么是不是只是对 String 说不。其实当它要创建临时变量时, String 类是最大的罪人之一.


    大量使用 BadREgExpMatcher 的程序比使用 BtterRegExpMatcher 的要慢好多. 首先,调用者不得不创建一个 String 传入 match(), 接着 match() 又创建了一个 String 来返回匹配的文本. 结果是每次调用都有两个对象创建, 看起来不多, 但是如果要经常调用match(), 这些对象创建带给性能的代价就太大了.

BadRegExpMatcher 的性能问题不是在它的实现中, 而是它的接口; 象它定义的接口, 没有办法避免一些临时变量的创建。


    BetterRegExpMatcher 的 match() 用原类型(整数和字符数组)代替了 String 对象; 不需要创建中间对象来在调用者和 match() 之间传递信息.


    既然在设计时候避免性能问题要比写完整个系统以后再修改要容易一些, 你应该注意你的类中控制对象创建的方法. 在 RegExpMatcher 的例子中, 它的方法要求和返回 String 对象, 就应该为潜在的性能冒险提个警告信号. 因为 String 类是不可变的, 除了最常用以外