8G的容器Java堆才4G怎么就OOM了？

主要观点总结

本文主要描述了一个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的内存占用，并与中间件同学沟通解决问题。