标签：#Netty #内存泄露 #JVM调优 #DirectByteBuffer #Linux #故障排查
🚨 一、 案发现场：诡异的 OOM
时间：凌晨 03:00
报警：生产环境某 API 网关节点（配置 4C 16G）内存使用率超过 95%，随后服务不可用。
现场：
重启服务后，观察监控，发现内存呈现“线性增长”的趋势，每小时增长约 500MB，直到撑爆物理内存。
JVM 配置：
-Xmx4g -Xms4g -XX:MaxDirectMemorySize=8g怪象：
- 使用
jstat -gcutil <pid> 1000观察，堆内存 (Heap)使用率非常健康，Old 区长期稳定在 30%。 - 使用
top命令查看，进程的RES (物理内存)却高达 12GB。 - 计算题：12GB (RES) - 4GB (Heap) - 256MB (Metaspace) ≈7.7GB 的黑洞！
这 7.7GB 到底是啥？直觉告诉我们：Netty 的堆外内存漏了。
🧬 二、 嫌疑人画像：JVM 内存布局
在排查前，必须搞清楚 Java 进程的内存由哪几部分组成。
内存分布图 (Mermaid):
显然，我们的嫌疑人锁定在Direct Memory区域。
🔍 三、 第一轮排查：NMT 与 Netty 自检
1. 使用 NMT (Native Memory Tracking)
JVM 自带的 NMT 是排查堆外内存的第一把手术刀。
(注意：需在启动参数添加-XX:NativeMemoryTracking=detail)
jcmd<pid>VM.native_memory summary输出结果（截取）：
Total: reserved=14GB, committed=13GB - Java Heap (reserved=4GB, committed=4GB) - Internal (reserved=8.5GB, committed=8.5GB) <--- 异常点！NMT 经常把 DirectBuffer 归类为Internal或Other，这确认了是堆外问题，但不知道具体是哪行代码漏的。
2. 祭出 Netty 的核武器：ResourceLeakDetector
Netty 内置了一个极其强大的内存泄露检测器。它利用PhantomReference（虚引用）来追踪ByteBuf是否被垃圾回收，但在回收前没有调用release()。
操作步骤：
修改启动参数，将检测级别调至最高（生产环境慎用，有性能损耗，但为了查 Bug 值得）：
-Dio.netty.leakDetection.level=PARANOID重启并压测后，日志里出现了令人兴奋的红字：
LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information. Recent access records: ... Created at: io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:331) ... com.company.gateway.filter.AuthFilter.channelRead(AuthFilter.java:45) <--- 凶手！🕵️♂️ 四、 抓捕凶手：代码审计
日志明确指向了AuthFilter.java的第 45 行。我们来看代码。
Bug 代码示例：
publicclassAuthFilterextendsChannelInboundHandlerAdapter{@OverridepublicvoidchannelRead(ChannelHandlerContextctx,Objectmsg){ByteBufbuf=(ByteBuf)msg;if(checkToken(buf)){// 校验通过，传给下一个 Handlerctx.fireChannelRead(msg);}else{// ❌ 校验失败，打印日志，直接返回// 致命错误：这里中断了传递，但没有释放 buf！log.warn("Auth failed");// 应该在这里调用 ReferenceCountUtil.release(msg);}}}原理解析：
在 Netty 中，ByteBuf是引用计数的。
- 如果是
SimpleChannelInboundHandler，它会自动帮你release。 - 如果是
ChannelInboundHandlerAdapter（如上例），你必须手动负责释放。 - 如果你既不
ctx.fireChannelRead(msg)往下传（下游会释放），也不手动release()，这个 DirectByteBuffer 对应的堆外内存就永远不会被归还给操作系统。
修复后的代码：
}else{try{log.warn("Auth failed");}finally{// ✅ 必须手动释放！ReferenceCountUtil.release(msg);}}🔬 五、 深度追问：为什么 GC 没回收它？
很多同学有疑问：“Java 对象回收了，它引用的堆外内存不就自动释放了吗？”
这是一个经典的误区。
- DirectByteBuffer 的结构：
它在 Java 堆里只是一个很小的“壳”（Wrapper Object），可能只有几十字节。但它底层引用的 Native Memory 可能高达几 MB。 - GC 的惰性：
由于 Java 堆里的这个“壳”太小了，根本触发不了 Young GC，更别提 Full GC。 - 结果：
JVM 觉得：“堆内存还很空啊，我不急着 GC。”
OS 怒吼：“物理内存都快爆了，你还在睡！”
这就是为什么我们不仅要依赖 GC，更要依赖 Netty 的Reference Counting（引用计数）机制来显式归还内存。
🚀 六、 避坑指南与总结
这次 8GB 内存找回之旅，给我们留下了宝贵的经验：
- Handler 选择：能用
SimpleChannelInboundHandler就别用ChannelInboundHandlerAdapter，除非你非常清楚自己在做什么。 - 异常路径：90% 的内存泄露都发生在
if-else的异常分支或try-catch块中，一定要检查所有路径是否都释放了资源。 - 监控常驻：
- 生产环境建议开启
-Dio.netty.leakDetection.level=SIMPLE（采样检测）。 - 关注
DirectMemory指标（可通过 Micrometer/Prometheus 监控）。
- 工具链：
- jstat：看堆。
- NMT：看 JVM 内部。
- Netty Leak Detector：看 ByteBuf。
- pmap/gdb：看 Linux 物理内存段（终极手段）。
Next Step:
去检查你项目中所有的 Netty Handler，搜索ChannelInboundHandlerAdapter，看看有没有被吞掉的msg。这可能就是你服务器莫名 OOM 的元凶。
