系统因堆内存使用率过高触发警报，排查发现并非内存不足，而是存在内存泄漏。通过MAT工具分析堆内存日志，发现ByteBuf未被正确释放，怀疑与Netty的读事件处理有关。进一步研究发现，尽管Netty示例中未强调释放，但必须手动释放以避免内存泄漏。同时，JVisualVM显示int[]数组占用大量内存，而非预期的byte[]，指向Netty的IntObjectHashMap，可能与编解码过程相关。最后，通过修改代码，确保在读事件中释放ByteBuf，解决了问题。
某某某系统堆内存使用率连续3次超过设定阈值98%。
问题背景：
13号晚上，系统突然发了一条上述短信，说是堆内存超过阈值了，我们之前出现过这样的问题，当时我们将堆内存扩大了一倍，在运行一段时间之后，又出现了这样的问题，说明并不是堆内存不够用，而是系统存在堆内存泄漏问题。次日，我们排查了一下这个问题，先将我个人的排查过程记录下来。
排查过程：
首先我们查看了一下监控图表，上面显示的信息是：在很短的一段时间内，系统进行了多次full GC，每次full Gc都是在系统到达阈值，并且报警之后才去执行，但是奇怪的是young GC 也还算正常，并不是特别频繁，那么问题就可以转化为，为什么有很多对象Gc年龄都超过了15进入到了年老代？或者是因为有很多大对象直接进入了年老代（我们的jvm配置中并没有配置直接到年老代的对象大小阈值，因此应该是超过伊甸园区大小的对象会直接到达老年代，我们的年轻代大小为1.3G，eden:survivor 默认8:1 因此对象达到了1.1G以上才会直接到老年代）？
那么我们就要找找为什么那么多对象在年轻代没有回收，一直混到了老年代，我们将堆内存日志在MAT中分析了一下，MAT中显示如下所示：
上图表示在堆内存中，byte数组占用堆大小达到了93M，也是占用最多的对象，然后再看了一下这个对象的引用，看是什么东西不让byte数组释放，如下图所示：
从上图我们可以看出引用这个数组对象的几个大的对象都是属于netty的，并且netty对消息的编解码也会耗费很多的堆内存，这个不能说是异常情况，为了更好的定位问题，我将现在线上正常运行机器的堆内存
最低0.47元/天 解锁文章
扫一扫
1304
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
