Java虚拟机性能管理神器 - VisualVM(7) 排查JAVA应用程序线程泄漏【转】
版权声明:本文为博主原创文章,未经博主允许不得转载。
Java虚拟机性能管理神器 - VisualVM(7) 排查JAVA应用程序线程泄漏
1. 线程泄漏原因
搞清楚线程泄漏原因之前,我们先了解一下什么是线程泄漏和线程溢出。(已经了解这两个概念的同学,请直接看下一节)。
泄漏:一般指工业中不应该流出或漏出的物质或流体,流出或漏出机械设备以外,造成损失,称之为泄漏(百度百科)。
线程泄漏:指系统中动态分配的线程,在使用完毕后未关闭,导致相关资源未释放,结果导致一直占据系统资源,直到系统结束。直白点说,就是线程使用完毕后没有关闭或者正常停止,即线程泄漏。
溢出:是指就是某个容器装满了东西后,再装就流出来了,即溢出。
线程溢出:指系统中达到了线程分配的极限,无法再创建新的线程时,还在收到新创建线程的请求,无法创建的一种状态,即线程溢出。
在系统中,泄漏和溢出是有因果关系的:即,发生线程泄漏后,会导致线程溢出。或者说泄漏是原因,溢出是结果。但是有时候溢出不一定是泄漏造成的,例如:目前系统允许程序最多创建100个线程,由于当前并发量大,线程池目前已有98个线程正在处理业务,如果此时又并发请求创建了5个线程,就会造成线程池溢出,但是这个不能算是线程泄漏造成的,只能算是高并发业务场景下产生的线程溢出。
弄明白线程泄漏的含义后,我们就明白了线程泄漏的原因:线程使用完后没有正常关闭导致。
再说说实际应用中的问题:在生产环境,发生了数据修改后不更新的问题。业务逻辑是修改组织数据后,会将修改信息通过消息中间件通知订阅的服务,订阅的服务收到通知后,根据修改的信息更新缓存中的数据。由于缓存中的数据没有更新,所以刚开始怀疑是消息中间件没有传输成功。
2. 线程泄漏排查
有了排查目标后,就跟踪日志进行排查,发现消息能到应用服务接收方,说明消息传输成功,是应用收到消息后没有更新导致。那么就通过VisualVM远程监控JVM的运行状态,首先发现内存异常,Old区内存满了,说明有资源没有释放,而监视页面显示实时线程接近5000个,而一般应用的线程基本在100以下,说明线程运行不正常。将程序放到本机进行运行,查看线程标签,显示出具体业务线程运行后,一直处于运行和休眠状态,排查具体业务线程的逻辑,发现是在调用线程的逻辑中,每次都新建了一个业务线程,调用的任务又是通过定时器每隔几分钟运行一次,而业务线程只需要启动一次就行了,重复调用就会导致业务线程不断创建,最终导致线程资源泄漏而产生溢出,影响其他业务正常运行。
3. 线程泄漏处理
发现线程泄漏后,根据业务逻辑,将对应的代码进行重构,将定时调用的业务线程,做成静态方法进行调用,或者在调用任务类中,业务线程作为参数进行引用,避免重复创建。