• 微信公众号:美女很有趣。 工作之余,放松一下,关注即送10G+美女照片!

JVM堆内存泄露分析

开发技术 开发技术 4小时前 2次浏览
 

一、背景

公司有一个中间的系统A可以对接多个后端业务系统B,一个业务系统以一个Namespace代表, Namespace中包含多个FrameChannel(用holder保存),表示A连接到业务系统B各服务实例的连接;A与B通过GRPC通信。
 

二、现象

测试使用一台服务实例A,对应后端的一个业务系统B,该业务系统有两台服务实例,正常情况NameSpace中包含两个FrameChannel

 
当后端业务系统升级上线重启时,会重新创建FrameChannel,但旧的FrameChannel在GC(自己创建大量client,发送埋点消息,并使用jstat观察gc数量,过程不详述了)时却没有被释放,正常情况下,FrameChannel数量为2,当pp重启后,FrameChannel的数量变成4,并在gc时,没有被释放。
JVM堆内存泄露分析

 

 

 
正常情况Framechannel有2个,即两条线,当重启pp时,会变成4条线,查看堆内存FrameChannel对象,也是4个
JVM堆内存泄露分析

 

 

 

既然仍能监控旧的FrameChannel,于是想到将旧的FrameChannel注销监控
JVM堆内存泄露分析

 

 

 
再重新将A部署测试,发现当重启pp时,另外两个FrameChannel确实没有数据了,但堆内存中却仍然有4个FrameChannel对象(原因分析见下面的分析部分)
JVM堆内存泄露分析

 

 

 
JVM堆内存泄露分析

 

 

 
最后分析堆内存后,发现注销指标时少注销了一部分,重新开发,编译,打包,部署,并测试
JVM堆内存泄露分析

 

 

JVM堆内存泄露分析

 

 

 
发现FrameChannel对象仍然为4个,再分析堆内存,发现被Session引用,于是关闭所有client,再观察一会,FrameChannel数量终于变成了2个
JVM堆内存泄露分析

 

 

 

三、分析

dump内存对象,并使用MAT分析, 查看哪些对象在使用FrameChannel
JVM堆内存泄露分析

 

 

 
可以看见,一共4个FrameChannel对象,经过查看引用,发现3、4对象被Namespace中Holder引用,说明3、4是正常的连接;1、2没有被Hoder引用,是已经关闭的连接。选择第1个对象,查看谁引用它
JVM堆内存泄露分析

 

 

 
共有3个对象引用它,
  1. 第一个this$0是FrameChannel的内部类DownstreamObserver,此内部类对象被grpc使用,经过代码分析,入口是FrameChannelStub,而此类只被Framechannel本身使用。
  2. 第二个arg$1是一个Lambda表达式生成的对象,此对象又被3个对象引用
JVM堆内存泄露分析

 

 

 
查看这3个对象,再结果FrameChannel中设置指标监控的代码,可以知道是监控channelRoom所使用的Lambda表达式
JVM堆内存泄露分析

 

 

进入guage方法
JVM堆内存泄露分析

 

 

gauges即是上面第2个引用Lambda表达式的对象
 
再查看registry.register方法
JVM堆内存泄露分析

 

 

metrics即是上面第1个引用Lambda表达式的对象
 
进入OnMetricAdded, 往下点几层,可看见
JVM堆内存泄露分析

 

 

可见将gauge包装成JmxGuage,通过JMX暴露出来.
 
归纳一下,这三个引用对象所在的类分别是
  • 公司自己封装的Metrics指标类
  • com.codahale.metrics.MetricRegistry
  • com.codahale.metrics.jmx.JmxReporter
 
看一下,这三个类实例是什么时候被创建的
  • Metrics 是在最开始就会被创建
JVM堆内存泄露分析

 

 

  • com.codahale.metrics.MetricRegistry和 com.codahale.metrics.jmx.JmxReporter 在 MetricsFactory 类被加载的时候就会被创建
 
MetricsFactory是一个监控指标的工具类,可以说是全局的,不会被JVM卸载,导致其引用的对象不会被释放。
 
  1. 引用FrameChannel的第三个对象是Session中的channels
JVM堆内存泄露分析

 

 

 
channels是一个Map类型,其作用是存储namespace对应的frameChannel,在session第一次向后端业务系统发起事件时,会从Namespace中的Holder选择一个FrameChannel,放入自身channel的Map中缓存起来,下一次使用时直接从channels map中查询,不用从namespace holder中获取。
 
一个 session 对象代表一个客户端到长连接网关的连接,其是在客户端连接长连接网关时被创建的。
而session被3个对象引用,下面标的是4个,因为SessionRoom同时会被Namespace中的rooms和FrameChannel中的channelRooms引用
JVM堆内存泄露分析

 

 

 

我们先看下SessionRoom,它会不会不被释放?

不会,因为NamespaceManager会定时(每30s)检查Namespace和FrameChannel中的SessionRoom是否为空,如果为空,则将其从rooms和channelRooms Map中删除,JVM就可以回收SessionRoom。
 

再看下SessionPool, 它会不会不释放Session?

不会,因为SessionPool也会定时检查已经关闭的Session,并将其删除
 

再看下ClientHead, 它会不会不被释放?

不会,ClientHead是Netty-SocketIO框架创建的对象,当客户端连接长连接网关时,会创建ClientHead对象,放入到ClientBox中,当连接关闭时,会将其中ClientBox中删除,具体请见类:com.corundumstudio.socketio.handler.ClientsBox
 
经过以上分析,发现使用 MetricsFactory 创建出的Metrics,在使用gauga等包含Lambda表达式的方法时,会使被引用的对象无法被GC回收,从而造成内存泄露。
 

四、总结

使用全局的对象时,最好不要直接引用生命周期变化的对象,如果非要引用其它对象,则保证被引用的对象也是全局的,不会被销毁重建,如果被引用对象会被销毁重建,则在销毁时,从全局对象中删除对其的引用,以免造成内存泄露。

程序员灯塔
转载请注明原文链接:JVM堆内存泄露分析
喜欢 (0)