使用技巧：Java EE性能问题解决手册8

• 　　1. 程序请求一个对象
• 　　2. 缓存检测这个对象是否已经存在于缓存中
• 　　3. 缓存决定把一个对象开除出缓存(一般采用的算法是遗弃最近使用次数最少的对象)
• 　　4. 把这个对象扔出缓存(称为passivated)
• 　　5. 把从数据库中装载这个新对象并放入到缓存(称为activated)
• 　　6. 把指向这个对象的引用返回给程序

　　Figure 11. Because the requested object is not in the cache, an object must be selected for removal from the cache and removed from it.

　　如果多数的请求都需要执行这些步骤的话，那你采用缓存技术就不是好的选择了!如果这些处理步骤频繁发生的话，你就需要重新推敲下你的缓存了。回忆一下:从缓存中去除一个对象称为passivation，从持久存储区取出一个对象放入缓存称为activation。能在缓存中找到的请求(缓存中有此请求的对象)的百分率称为hit ratio，相反找不到的请求的百分率称为miss ratio。

　　缓存刚被初始化的时候，hit ratio是0，它的activation数量非常高，因此在初始化后你需要去观察缓存的性能。初始化以后，你应该跟踪passivation的数量并把它和与向缓存请求对象的请求的总量相比较，因为passivations只会发生在缓存被初始化以后。但一般来说，我们更需要关心缓存的miss ratio。如果miss ratio超过25%，那么缓存可能是太小了。因此，如果missratio的数量超过75%，那么不是你的缓存设置的太小就是你不需要缓存这个技术。

　　一旦你觉得你的缓存太小，就去尝试着增大大小，并测试增加的性能。如果miss ration下降到20%以下，那你的缓存的大小就非常棒了，如果没有什么效果，那么你就需要和这个程序的技术员联系，看是这个对象是不是需要缓存或者是否应该修正程序中这个对象的代码。

Staless session bean和message-driven bean池

　　Stateless session bean 和message-driven bean 在商业应用方面很重要，不要期望它们会保持自己特有的状态信息。当你的程序需要使用这些BEAN的商业功能的时候，它就从一个池中取出一个BEAN实例，用这个实例来调用一个个方法，用完后再将BEAN的实例再放回到池中。如果你的程序过了一会又需要这个一摸一样的BEAN，就从池中再得到一个实例，但不能保证你得到的就是上一个实例。池能够让程序共享资源，但是会让你的程序付出潜在的等待时间。如果你无法从池中得到想要的BEAN，请求就会等待，一直到这个BEAN被放入到池中。很多程序服务器都会把这些池调整的很好，但是我碰到过因为在环境中把他们设置的太小而引发的不少麻烦。Stateless bean池的大小应该和可执行线程池的大小一般大，因为一个线程同时只能使用一个对象，再多了就造成浪费的。因此，一些程序服务器把池的大小和线程的数量设置成同样的数量。为了保险起见，你应该亲自把它设置成这个数。

　　事务

　　使用Enterprise Java的一个好处就是它天生就支持事务。通过JAVAEE 5 EJB(Enterprise javaBeans)的注释，你可以控制事务中方法的使用。事务会以下面2中方式结束:

• 　　1. 事务提交
• 　　2. 事务回滚

　　当一个事务被提交的时候，说明它已经完全成功了，但是当它回滚的时候，就说明发生了一些错误。回滚会是下面2种情况:

• 　　1. 程序造成的回滚(程序回滚)
• 　　2. 非程序造成的回滚(非程序回滚)

　　通常，程序回滚是因为商业的规定。比如一个WEB程序做一个素描画的价格的调查，程序可能让用户输入年龄，并且商业规定18岁以上才可以进入。如果一个16岁的提交了信息，那么程序就会抛出一个错误，打开一个网页告诉他，他年龄还不能参与到这个信息的调查。因为程序抛出了异常，因此包含在程序中的事务的就会发生回滚。这只是普通的程序回滚，只有当发生大量的程序回滚才值得我们注意。

　　另一方面，非程序回滚是非常糟糕的。有三种情形的非程序回滚:

• 　　1. 系统回滚
• 　　2. 超时回滚
• 　　3. 资源回滚

　　系统回滚意味着程序服务器中的一些东西非常的糟糕，恢复的几率很渺茫。超时回滚就是当程序服务器中的程序处理请求时超时;除非你把超时设置的很短才会出现这种错误。资源回滚就是当一个程序服务器管理内部的资源的时候发生错误。例如，如果你设置你的程序服务器通过一个简单的SQL语句去测试数据库的连接，但数据库对于程序服务器来说是无法连接的，这个时候任何和这个资源相关的事情都会发生资源回滚。

　　如果发生非程序回滚，我们应该立刻注意，这个是不小的问题，但是你也需要留意程序回滚发生的频率。很多时候人们对发生的异常很敏感，因此你需要哪些异常对你程序来说才是重要的。

　　总结

　　尽管各个程序和他们的环境都各不相同，但是有一些共同的问题困扰着他们。这篇文章的注意力并不是放在程序代码的问题上，因为把注意力放在因为环境的问题而导致的低性能的问题上:

• 　　1.内存溢出
• 　　2.线程池大小
• 　　3.JDBC连接池大小
• 　　4.JDBC预先声明语句缓存大小
• 　　5.缓存大小
• 　　6.池大小
• 　　7.执行事务时候的回滚

　　为了有效的诊断性能的问题，你应该了解什么问题会导致什么样的症状。如果主要是程序的代码导致的恶果那你应该带着问题去寻求负责代码的人寻求帮助，但是如果问题是由环境引起的，那么就要依靠你的操作来解决了。

　　问题的根源依赖于很多要素，但是一些指示器可以增加一些你处理问题时候的一些信心，依靠他们可以完全排除一些其他的原因。我希望这个文章能对你排解JAVAEE环境问题起到帮助。