大型企业门户网站页架构生成源代码优化
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 getKey() throws RemoteException { return KeyValue++; }"
" }"
2.8 及时清除不再需要的会话
许多通常的Java性能问题都起源于在设计过程早期中的类设计的思想, 早在许多开发者开始考虑性能问题之前. 在这个系列中, Brian Goetz 讨论了通常的 Java 性能上的冒险以及怎么在设计时候避免它们. 在第二部分, 他讨论了减少临时对象创建的一些技术。
虽然许多程序员把性能管理一直推迟到开发过程的最后, 性能考虑应该从天起就和设计周期结合在一起. 这个系列探索一些早期的设计思想能够极大影响应用程序性能的方法.在这篇文章里, 我继续探索大量临时对象创建的问题, 并且提供一些避免它们的一些技术.
临时对象就是一些生命周期比较短的对象, 一般用于保存其他数据而再没有其他用途. 程序员一般用临时变量向一个方法传递数据或者从一个方法返回数据. 部分探讨了临时对象是怎样给一个程序的性能带来负面的冲击, 以及一些类接口的设计思想怎样提供了临时对象的创建. 避免了那些接口的创建, 你就能极大地减少那些影响你的程序性能的临时对象创建的需求。
只是对 String 说不吗?
当它要创建临时变量时, String 类是的罪人中的一个. 为了演示, 在部分我写了一个正规表达式匹配的例子, 通过和一个类似的但是经过仔细设计的接口相比较, 演示了看起来无害的接口是怎样引起大量对象的创建, 而慢上几倍. 这里是原来的和好一些的类的接口:
坏的正则表达式匹配实例：
public class BadRegExpMatcher {
public BadRegExpMatcher(String regExp);
public String match(String inputText);
}
好的正则表达式匹配实例：
class BetterRegExpMatcher {
public BetterRegExpMatcher(...);//省略了一些
public int match(String inputText);
public int match(char[] inputText);
public int match(char[] inputText, int offset, int length);
public int getMatchLength();
public String getMatchText();
}
实体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实现了本地接口，则其引用不可串行化。
大量使用 BadREgExpMatcher 的程序比使用 BtterRegExpMatcher 的要慢好多. 首先,调用者不得不创建一个 String 传入 match(), 接着 match() 又创建了一个 String 来返回匹配的文本. 结果是每次调用都有两个对象创建, 看起来不多, 但是如果要经常调用match(), 这些对象创建带给性能的代价就太大了. BadRegExpMatcher 的性能问题不是在它的实现中, 而是它的接口; 象它定义的接口, 没有办法避免一些临时变量的创建。
BetterRegExpMatcher 的 match() 用原类型(整数和字符数组)代替了 String 对象; 不需要创建中间对象来在调用者和 match() 之间传递信息.
既然在设计时候避免性能问题要比写完整个系统以后再修改要容易一些, 你应该注意你的类中控制对象创建的方法. 在 RegExpMatcher 的例子中, 它的方法要求和返回 String 对象, 就应该为潜在的性能冒险提个警告信号. 因为 String 类是不可变的, 除了最常用以外, 所有的 String 参数在每次调用处理函数时都需要创建一个新的 String.
不可变性对于性能来说是否很坏?
因为 String 经常和大量的对象创建联系在一起, 一般来说归咎于它的不可变性. 许多程序员认为不可变的对象与生俱来对性能没有好处. 但是, 事实多少会更复杂一些. 实际上, 不可变性有时候提供了性能上的优势, 可变性的对象有时候导致性能问题. 不管可变性对性能来说有帮助或者有害, 依赖于对象是怎么使用的.
程序经常处理和修改文本字符串 -- 这和不可变性非常不匹配。每次你想处理一个 String --想查找和解析出前缀或者子串, 变小写或者大写, 或者把两个字符串合并 -- 你必须创建一个新的 String 对象. (在合并的情况下, 编译器也会隐藏地创建一个 StringBuffer() 对象)
另一个方面, 一个不可变的对象的一个引用可以自由共享, 而不用担心被引用的对象要被修改, 这个比可变对象提供性能优势, 就象下一节例子所说的。
可变的对象有它们自己的临时对象问题.
旗下_E网中国（#），专业做网站、网站建设。从事网络信息化建设应用，提供网站建设、网页设计、域名注册、空间租用、模板定制、平面设计、网络推广、搜索优化等服务等。
郑州亚龙软件有限公司（www.yeloon.com），从事网络、软件信息化建设应用，专注软件开发、软件定制、ERP系统、进销存管理系统、客户关系管理系统等服务。基于互联网络，我们为您提供全面的电子商务咨询与解决方案。
公司自主研发的产品有：ERP系统，客户关系管理（CRM）系统，进销存管理系统，学校收费管理系统。
地址： 郑州市东风路天明路交叉路口向东天明森林国际公寓1号楼6层
网址：#(软件开发）
#（网站建设）
客服QQ： 3711121,999706,80031367
联系电话： 0371-55512385，55512365,88886548