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

核心提示： 数据库连接池问题 某财务应用运行在JavaEE服务器上，后台连接Oracle数据库，JavaEE应用程序在Glassfish上的性能调优案例分析(2)，并发用户数量超过100人左右的时候系统停止响应，通过操作系统层面的进程监控工具发现进程并没有被杀死或挂起，并调整回收算法（使用增量回收的算法），

数据库连接池问题

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

大对象缓存问题

电信应用运行在64位Java虚拟机上，系统运行得很不稳定，系统经常停止响应。使用进程工具查看，发现进程并没有被杀死或挂起。利用Java虚拟机的工具发现系统在长时间的进行内存回收，内存回收的时间长达15分钟，整个系统在内存回收的时候就像挂起一样。另外还观察到系统使用了12G的内存（因为是 64位虚拟机所以突破了4G内存的限制）。从开发人员那里了解到，这个应用为了提高性能，大量使用了对象缓存，但是事与愿违，在Java中使用过多的内存，虽然在正常运行的时候能够获得很好的性能，但是会大大增加内存回收的时间。特别是对象缓存，本系统使用了8G的缓存空间，共缓存了6000多万个对象，对这些对象的遍历导致了长时间的内存回收。根据我们的建议，将缓存空间减少到1G，并调整回收算法（使用增量回收的算法），使得系统由于内存回收而造成的最大停顿时间减少到4秒，基本满足用户的需求。