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分钟。通过几天的测试，证明泄漏的问题得到解决。
数据库连接池问题
某财务应用运行在JavaEE服务器上，后台连接Oracle数据库。并发用户数量超过100人左右的时候系统停止响应。通过操作系统层面的进程监控工具发现进程并没有被杀死或挂起，而CPU使用率几乎为零。那么是什么原因导致系统停止响应用户请求呢？我们利用Java虚拟机的工具（kill -3 pid）将当前的所有线程状态DUMP出来，发现JavaEE服务器的大部分处理线程都在等待数据库连接池的连接，而那些已经获得数据库连接的线程却处于阻塞状态。数据库管理员应要求检查了数据库的状态，发现所有的连接的session都处于死锁状态。显然，这是因为数据库端出现了死锁的操作，阻塞了那些有数据库操作的请求，占用了所有数据库连接池中的连接。后续的请求如果还要从连接池中获取连接，就会阻塞在连接池上。当解决数据库死锁的问题之后，性能问题迎刃而解。