JavaEE应用程序在Glassfish上的性能调优案例分析

核心提示：Java EE应用的性能问题对严肃的项目和产品来说是一个非常重要的问题，特别是企业级的应用，JavaEE应用程序在Glassfish上的性能调优案例分析，并发用户多，数据传输量大，应该点击这个 logout的链接；并且将session的timeout时间修改为5分钟，通过几天的测试，业务逻辑复杂，占用系统资源多

Java EE应用的性能问题对严肃的项目和产品来说是一个非常重要的问题。特别是企业级的应用，并发用户多，数据传输量大，业务逻辑复杂，占用系统资源多，因此性能问题在企业级应用变得至关重要，它和系统的稳定性有着直接的联系。更加重要的是，性能好的应用在完成相同任务的条件下，能够占用更少的资源，获得更好的用户体验，换句话说，就是能够节省费用和消耗，获得更高的利润。

要获得更好的性能，就需要对原来的系统进行性能调优。对运行在Glassfish上的JavaEE应用，调优是一件相对复杂的事情。在调优以前必须要认识到：对JavaEE的系统，调优是多层次的。一个JavaEE的应用其实是整个系统中很少的一部分。开发人员所开发的JavaEE程序，无论是JSP还是 EJB，都是运行在JavaEE应用服务器（Glassfish）之上。而应用服务器本身也是Java语言编写的，需要运行在Java虚拟机之上。 Java虚拟机也只不过是操作系统的一个应用而已，和其他的应用（如Apache）对于操作系统来说没有本质的区别。而操作系统却运行在一定的硬件环境中，包括CPU，内存，网卡和硬盘等等。在这么多的层次中，每一个层次的因素都会影响整个系统的性能。因此，对一个系统的调优，事实上需要同时对每个层次都要调优。JavaEE应用性能调优不仅仅和Glassfish有关，Java语言有关，还要和操作系统以及硬件都有关系，需要调优者有综合的知识和技能。这些不同层面的方法需要综合纵效，结合在一起灵活使用，才能快速有效的定位性能瓶颈。下面是一些具体的案例分析:

内存泄漏问题

某个JavaEE应用运行在8颗CPU的服务器上。上线运行发现性能不稳定。性能随着时间的增加而越来越慢。通过操作系统的工具（mpstat），发现在系统很慢的时候，只有一颗CPU很忙，其他的CPU都很空闲。因此怀疑是Java虚拟机经常进行内存回收，因为虚拟机在内存回收的时候，有的回收算法通常只能运行在一个CPU上。通过Java虚拟机的工具“jstat”可以清楚的看到，Java虚拟机进行内存回收的频率非常高，几乎每5秒中就有一次，每次回收的时间为2秒钟。另外，通过“jstat”的输出还发现每次回收释放的内存非常有限，大多数对象都无法回收。这种现象很大程度上暗示着内存泄漏。使用 Java虚拟机的工具“jmap”来获得当前的一个内存映象。发现有很多（超过10000）个的session对象。这是不正常的一个现象。一般来说， session对应于一个用户的多次访问，当用户退出的时候，session就应该失效，对象应该被回收。当我们和这个系统的开发工程师了解有关 session的设置，发现当他们部署应用的时候，竟然将session的timeout时间设置为50分钟，并且没有提供logout的接口。这样的设置下，每个session的数据都会保存50分钟才会被回收。根据我们的建议，系统提供了logout的链接，并且告诉用户如果退出应用，应该点击这个 logout的链接；并且将session的timeout时间修改为5分钟。通过几天的测试，证明泄漏的问题得到解决。