主要观点总结
本文主要描述了一个Java应用OOM问题的排查过程，涉及到Java堆外内存的监控、分析和定位。应用中存在多个ClassLoader加载了netty的PooledByteBufAllocator，导致实际使用的堆外内存超出限制。排查过程中使用了多种工具和技术手段，包括NativeMemoryTracking、jemalloc参数调整、perf监控等。最终通过静态变量分析确定了netty占用的内存大小，并指出了问题的根本原因。
关键观点总结
关键观点1: 问题描述
Java应用出现OOM问题，初步分析发现堆外内存使用异常，实际使用量超过预期。
关键观点2: 排查过程
使用NativeMemoryTracking监控内存分类占用信息，发现Other部分内存可疑增长；通过静态变量分析确定netty占用的内存大小。
关键观点3: 问题分析
中间件中多个不同的ClassLoader加载了多个netty的PooledByteBufAllocator，每个Allocator都有自己的内存配额，导致实际使用的堆外内存超出限制。
关键观点4: 解决方案
短期内通过调整Java堆大小以适应现状；长期内考虑优化rocketmq-client的内存占用，并与中间件同学沟通解决问题。
文章预览
阿里妹导读 本文记录最近一例Java应用OOM问题的排查过程，希望可以给遇到类似问题的同学提供参考。 前言：此文记录最近一例Java应用OOM问题的排查过程，希望可以给遇到类似问题的同学提供参考。在本地集团，大多数情况下Java堆的大小会设置为容器规格的50%～70%，但如果你设置为50%时还是遇到了OS OOM的问题，会不会无法忍受进而想要知道这是为什么？没错，我也有一样的好奇。 背景 某核心应用的负责同学反馈应用存在少量机器OOM被OS kill的问题。看sunfire监控信息，的确如此。 初步收集到的信息： 容器内存=8G，Java 11，G1 GC=4G，MaxDirectMemorySize=1G。详见下图： 业务同学已经做过Java dump，可以看到堆外对象几乎没有，堆内的使用量也不大， < 3G。上机器查看Java进程的内存使用量的确很大： 通过目前掌握到的信息来看，4G（Java
………………………………
