Java虚拟机性能管理神器 - VisualVM(7) 排查JAVA应用程序线程泄漏【转】

 

Java虚拟机性能管理神器 - VisualVM(7) 排查JAVA应用程序线程泄漏【转】

标签: javajvm线程泄漏
 分类:
VisualVM(8) 
 

目录(?)[+]

 

Java虚拟机性能管理神器 - VisualVM(7)  排查JAVA应用程序线程泄漏

1. 线程泄漏原因

        搞清楚线程泄漏原因之前,我们先了解一下什么是线程泄漏和线程溢出。(已经了解这两个概念的同学,请直接看下一节)。

        泄漏:一般指工业中不应该流出或漏出的物质或流体,流出或漏出机械设备以外,造成损失,称之为泄漏(百度百科)。

        线程泄漏:指系统中动态分配的线程,在使用完毕后未关闭,导致相关资源未释放,结果导致一直占据系统资源,直到系统结束。直白点说,就是线程使用完毕后没有关闭或者正常停止,即线程泄漏。

        溢出:是指就是某个容器装满了东西后,再装就流出来了,即溢出。

        线程溢出:指系统中达到了线程分配的极限,无法再创建新的线程时,还在收到新创建线程的请求,无法创建的一种状态,即线程溢出。

在系统中,泄漏和溢出是有因果关系的:即,发生线程泄漏后,会导致线程溢出。或者说泄漏是原因,溢出是结果。但是有时候溢出不一定是泄漏造成的,例如:目前系统允许程序最多创建100个线程,由于当前并发量大,线程池目前已有98个线程正在处理业务,如果此时又并发请求创建了5个线程,就会造成线程池溢出,但是这个不能算是线程泄漏造成的,只能算是高并发业务场景下产生的线程溢出。

        弄明白线程泄漏的含义后,我们就明白了线程泄漏的原因:线程使用完后没有正常关闭导致。

        再说说实际应用中的问题:在生产环境,发生了数据修改后不更新的问题。业务逻辑是修改组织数据后,会将修改信息通过消息中间件通知订阅的服务,订阅的服务收到通知后,根据修改的信息更新缓存中的数据。由于缓存中的数据没有更新,所以刚开始怀疑是消息中间件没有传输成功。

2. 线程泄漏排查

        有了排查目标后,就跟踪日志进行排查,发现消息能到应用服务接收方,说明消息传输成功,是应用收到消息后没有更新导致。那么就通过VisualVM远程监控JVM的运行状态,首先发现内存异常,Old区内存满了,说明有资源没有释放,而监视页面显示实时线程接近5000个,而一般应用的线程基本在100以下,说明线程运行不正常。将程序放到本机进行运行,查看线程标签,显示出具体业务线程运行后,一直处于运行和休眠状态,排查具体业务线程的逻辑,发现是在调用线程的逻辑中,每次都新建了一个业务线程,调用的任务又是通过定时器每隔几分钟运行一次,而业务线程只需要启动一次就行了,重复调用就会导致业务线程不断创建,最终导致线程资源泄漏而产生溢出,影响其他业务正常运行。

        

 

        

 

3. 线程泄漏处理

        发现线程泄漏后,根据业务逻辑,将对应的代码进行重构,将定时调用的业务线程,做成静态方法进行调用,或者在调用任务类中,业务线程作为参数进行引用,避免重复创建。

 

 

 

转载于:https://www.cnblogs.com/abcd19880817/p/7194889.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值