内存泄露排查之线程泄露

基础

内存泄露(Memory Leak)

  1. java中内存都是由jvm管理,垃圾回收由gc负责,所以一般情况下不会出现内存泄露问题,所以容易被大家忽略。
  2. 内存泄漏是指无用对象(不再使用的对象)持续占有内存或无用对象的内存得不到及时释放,从而造成内存空间的浪费称为内存泄漏。
  3. 内存泄露有时不严重且不易察觉,这样开发者就不知道存在内存泄露,需要自主观察,比较严重的时候,没有内存可以分配,直接oom。
  4. 主要和溢出做区分。

内存泄露现象

  • heap或者perm/metaspace区不断增长, 没有下降趋势, 最后不断触发FullGC, 甚至crash.
  • 如果低频应用,可能不易发现,但是最终情况还是和上述描述一致,内存一致增长

perm/metaspace泄露

  • 这里存放class,method相关对象,以及运行时常量对象. 如果一个应用加载了大量的class, 那么Perm区存储的信息一般会比较大.另外大量的intern String对象也会导致该区不断增长。
  • 比较常见的一个是Groovy动态编译class造成泄露。
  • 这里就不展开了

heap泄露

比较常见的内存泄露

  1. 静态集合类引起内存泄露
  2. 监听器:
  3. 但往往在释放对象的时候却没有记住去删除这些监听器,从而增加了内存泄漏的机会。
  4. 各种连接,数据库、网络、IO等
  5. 内部类和外部模块等的引用:
  6. 内部类的引用是比较容易遗忘的一种,而且一旦没释放可能导致一系列的后继类对象没有释放。
  7. 非静态内部类的对象会隐式强引用其外围对象,所以在内部类未释放时,外围对象也不会被释放,从而造成内存泄漏
  8. 单例模式:
  9. 不正确使用单例模式是引起内存泄露的一个常见问题,单例对象在被初始化后将在JVM的整个生命周期中存在(以静态变量的方式),如果单例对象持有外部对象的引用,那么这个外部对象将不能被jvm正常回收,导致内存泄露
  10. 其它第三方类

本例(线程泄露)

本例现象

  1. 内存占用率达80%+左右,并且持续上涨,最高点到94%
内存泄露排查之线程泄露
  1. yongGC比较频繁,在内存比较高的时候,伴有FullGC
内存泄露排查之线程泄露
  1. 线程个个数比较多,最高点达到2w+(这个比较重要,可惜是后面才去关注这点)
内存泄露排查之线程泄露
  1. 日志伴有大量异常,主要是三类
  2. fastJosn error
内存泄露排查之线程泄露
  1. 调用翻译接口识别语种服务错误
内存泄露排查之线程泄露
  1. 对接算法提供的二方包请求错误
内存泄露排查之线程泄露
内存泄露排查之线程泄露

刚开始走的错误弯路

  1. 刚开始发现机器内存占用比较多,超过80%+,这个时候思考和内存相关的逻辑
  2. 这个时候并没有去观察线程数量,根据现象 1、2、4,、这个过程没有发现现象3,排查无果后,重新定位问题发现现象3
  3. 由于现象4中的错误日志比较多,加上内存占用高,产生了如下想法(由于本例中很多服务通过mq消费开始)
  • 现象4中的错误导致mq重试队列任务增加,积压的消息导致mq消费队列任务增加,最终导致内存上升
  • 由于异常,逻辑代码中的异常重试线程池中的任务增加,最终导致任务队列的长度一直增加,导致内存上升

解决弯路中的疑惑

  • 定位异常
  • fastJson解析异常,光看错误会觉得踩到了fastJson的bug(fastJson在之前的版本中,写入Long类型到Map中,在解析的时候默认是用Int解析器解析,导致溢出错误。
  • 但是这个bug在后面的版本修复了,目前即使是放入Long类型,如果小于int极限值,默认是int解析,超过int极限,默认long。
  • 类中的变量为Long。
  • 直接parse,直接为Long类型),但是业务代码中使用的是类直接parse,发现二方包中的类使用了int,但是消息值有的超过int值
  • eas算法链路调用错误,之前就有(404),但是没有定位到具体原因,有知道的望指点下,这里用try catch做了处理
  • 翻译服务异常,这里没定位到具体原因,重启应用后恢复,这里忘记了做try catch,看来依赖外部服务需要全部try下
  • 确认是否是业务逻辑中错误重试队列问题
  • 否,和业务相关才会走入重试流程,还在后面
  • 确认是否是Mq消息队列本以及Mq重试队列 消息积压导致
  • 否,Mq做了消费队列安全保护
  • consumer异步拉取broker中的消息,processQueue中消息过多就会控制拉取的速率。
  • 对于并发的处理场景, 存在三种控制的策略:
  • 1. queue中的个数是否超过1000
  • 2. 估算msg占用的内存大小是否超过100MB
  • 3. queue中仍然存在的msg(多半是消费失败的,且回馈broker失败的)的offset的间隔,过大可能表示会有更多的重复,默认最大间隔是2000。
  • 流控源码类:
  • com.alibaba.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl#pullMessage,圈中的变量在默认的类中都有初始值
内存泄露排查之线程泄露
  • metaq也会自己做动态线程调整,理论上当线程不够用时,增加线程,adjustThreadPoolNumsThreshold默认10w,当线程比较多时,减少线程,但是代码被注释了,理论上应该没有自动调整过程,所以这里也不会因为任务过多增加过多线程数
  • 在start启动的时候,启动了一批定时任务
内存泄露排查之线程泄露
  • 定时任务中启动了调整线程的定时任务
内存泄露排查之线程泄露
  • 启动调整任务
内存泄露排查之线程泄露
内存泄露排查之线程泄露

回归正途的处理逻辑

  • 经过上述分析,发现并不是因为异常导致的任务队列增加过大导致,这个时候,发现了现象3,活动线程数明显过多,肯定是线程泄露,gc不能回收,导致内存一直在增长,所以到这里,基本上就已经确认是问题由什么导致,接下来要做的就是确认是这个原因导致,以及定位到具体的代码块
  • 如果没有具体的监控,一般就是看内存,cpu,heap状况,gc状况等,最终依然无法定位到代码块的可以dump

登录涉事机器

top,观察内存占用率(这里图是重启之后一段时间的)但是cpu占用率比较高,很快就降下去了,这里耽误了一下时间,top -Hp pid,确认那个线程占用率高,jstack看了下对应的线程在作甚

确认线程是否指定大小,未发现指定,使用的默认值

内存泄露排查之线程泄露

查看heap,gc状况

查看线程状况,可jstack线程,发现线程较多,也能定位到,但是为了方便,遂dump一份数据详细观察堆栈

cat /proc/{pid}/status (线程数竟然这么多)

内存泄露排查之线程泄露

由于线程数比较多,而依然可以创建,查看Linux普通用户所允许创建的进程数,使用命令:cat /etc/security/limits。d/90-nproc。conf ,值比较到,远超当前的个数。

线程信息

内存泄露排查之线程泄露

线程状态

内存泄露排查之线程泄露

定位到问题线程

AbstractMultiworkerIOReactor ==》 httpAsycClient ==》如图所示不能直接定位到代码块,所以maven定位引用jar的服务 ==> 具体二方包。如果每次都new线程而不结束,gc中线程是root节点,如果线程没有结束,不会被回收,所以如果创建大量运行的线程,会导致内存占用量上升,但是线上到底能创建多少线程呢?

问题代码块

方法开始(每次都初始化一个新的客户端,底层封装使用httpAsyncClient,httpAsyncClient使用NIO模型,初始化包含一个boss,10个work线程)

内存泄露排查之线程泄露

方法结束(方法结束都调用了shutdow)

内存泄露排查之线程泄露

根据现象和对应线程堆栈信息,能确定线程就是在这边溢出,客户端的shutDown方法关闭线程池失效,导致由于初始的线程都是NIO模式,没有被结束,所以线程一直积压增加,可修改为单例模式,限制系统使用一个线程池。

httpAsyncClient部分源码

启动

内存泄露排查之线程泄露

线程池命名,也就是上面出现pool--thread-的线程

内存泄露排查之线程泄露

ioEventDispatch 线程

启动

worker线程

内存泄露排查之线程泄露

worker线程名称

内存泄露排查之线程泄露

IO worker运行详细

内存泄露排查之线程泄露

worker线程实现

内存泄露排查之线程泄露
内存泄露排查之线程泄露
内存泄露排查之线程泄露

shutdown 这里就不做分析了,调用后,线程都会跳出死循环,结束线程,关闭链接等好多清理动作

疑问

  • 虽然每次方法调用都是new新的客户端,但是结束finally中都调用了shutDown,为何会关闭失败,上面使用单例模式,只是掩盖了为什么每次new客户端然后shutdown失效的原因
  • httpAsyncClient客户端在请求失败的情况下,httpclient.close()此处会导致主线程阻塞;
  • 经源码发现close 方法内部,在线程连接池关闭以后, httpclient对应线程还处于运行之中,一直阻塞在epollWait,详见上面的线程状态,这里目前没有确定下为什么调用shutdown之后线程关闭失败,也没有任何异常日志,但是这是导致线程泄露的主要原因
  • 在本地测试shutdown方法可正常关闭,很是奇怪。
  • 如果各位有知道具体的原因的,望指教

未经允许不得转载:凤凰棋牌PHP100中文网 - 中国第一档PHP资源分享门户 » 内存泄露排查之线程泄露

赞 (0) 打赏

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏

众博棋牌 凤凰棋牌 凤凰棋牌 众博棋牌 众鑫棋牌 众鑫棋牌 凤凰棋牌 六合宝典 众博棋牌 凤凰棋牌手机版