Netty 的引用计数如何工作？如何排查 ByteBuf 内存泄漏？

简化版

Netty 的池化 ByteBuf 用引用计数（reference count） 管理生命周期：retain() 让计数 +1（多一个持有者），release() 让计数 -1（一个持有者用完了），计数归零时内存被回收/归还内存池。原则是**「谁持有，谁负责释放」，传下去就是把释放责任一起交出去**。泄漏几乎都来自三处：① 异常路径漏 release、② 异步/跨线程传递后未 retain、③ slice/duplicate 共享内存后没理清持有关系。Netty 的 ResourceLeakDetector 能帮定位泄漏，但根治靠代码规范——内存泄漏多数不是算法错，而是所有权没交代清楚。

详细版

引用计数的规则：

ByteBuf buf = ...;        // 初始 refCnt = 1
buf.retain();             // refCnt = 2（多一个持有者）
buf.release();            // refCnt = 1
buf.release();            // refCnt = 0 → 内存回收/归还池

// release 后再访问 → IllegalReferenceCountException
// 忘记 release → 内存泄漏

责任转移规则：

场景	释放责任
`ctx.fireChannelRead(msg)` 传给下一个 handler	责任转移给后续节点
当前 handler 消费掉、不再传播	当前 handler 必须 release（finally）
跨异步线程/存进集合	先 `retain`，用完 `release`
slice/duplicate 共享内存	理清谁 retain/release，否则悬空

泄漏三大来源： 异常路径漏 release、异步跨线程忘 retain、slice/duplicate 共享后所有权不清。

完整版教学

一、为什么需要引用计数

Netty 用池化内存和堆外内存（见「ByteBuf」专题）——这两种不能完全依赖 JVM 的 GC 及时回收：

池化内存：ByteBuf 用完要归还到内存池复用，GC 不知道什么时候该归还。
堆外内存：不在 JVM 堆里，GC 管不到（或回收不及时）。

所以 Netty 用引用计数来明确地知道「一块内存什么时候不再被任何人使用」——计数归零就立即归还池/释放，不等 GC。这是高性能的代价：生命周期管理更严格、要手动维护引用计数。

二、retain 和 release

引用计数的两个基本操作：

retain()：表示「又多了一个持有者」，计数 +1。
release()：表示「当前这个持有者用完了」，计数 -1。release() 返回 true 通常表示计数归零（内存被真正回收）。

两个红线：

release 后再访问 → 抛 IllegalReferenceCountException（内存可能已被回收/复用，访问是非法的）。
忘记 release → 内存泄漏（计数永远不归零，内存永不归还）。

初始分配的 ByteBuf 引用计数是 1，用完 release 一次归零即可。

ByteBuf buf = ctx.alloc().buffer();
try {
    // 当前 Handler 自己消费 buf，不再向后传播
    handle(buf);
} finally {
    ReferenceCountUtil.release(buf);
}

三、责任如何转移（核心规则）

引用计数的核心是「所有权/责任」的传递，规则是「谁持有，谁负责释放；传下去就是转移责任」：

如果一个 Handler 调用 ctx.fireChannelRead(msg) 把 ByteBuf 传给后续节点——释放责任通常也转移给了后续节点（后面的 Handler 负责 release）。
如果当前 Handler 消费掉这个消息、不再往后传播——那么当前 Handler 就必须自己 release（通常在 finally 里，确保异常路径也释放）。

理解这条规则，就能判断「我这个 Handler 要不要 release」：看你有没有把消息传下去。传了，责任转移；没传（自己消费了），你负责。

场景	是否需要当前 Handler 释放	原因
`ctx.fireChannelRead(msg)` 继续传播	通常不需要	所有权交给后续 Handler
当前 Handler 消费并终止传播	需要	消息生命周期到当前节点结束
放入异步任务或集合	先 `retain()`，用完释放	新持有者需要独立生命周期
`SimpleChannelInboundHandler#channelRead0` 内异步使用	先 `retain()`	方法返回后框架会自动释放入站消息

引用计数题不要背 API，要讲“所有权”：谁最后持有这块 ByteBuf，谁就必须让它最终 release 到 0。

四、解码器与 SimpleChannelInboundHandler 的特殊情况

Netty 的一些基类会帮你自动管理释放，要知道它们的行为，避免误伤：

ByteToMessageDecoder（解码器基类）：框架会自动管理累积缓冲区（cumulation buffer）的释放。但你解码产出的对象如果仍是 ByteBuf 或它的派生视图，就要明确后续谁来释放。
SimpleChannelInboundHandler：它的 channelRead0 方法执行完后，框架会自动 release 入站消息。方便，但有坑——如果你在 channelRead0 里把消息交给了异步任务（异步任务稍后才用），而方法一返回框架就把消息 release 了，异步任务再用时消息已被释放！这种情况要在传给异步任务前 retain()。

五、slice 和 duplicate 的坑

slice() 和 duplicate() 共享底层内存，但不一定增加引用计数（它们和原 buffer 共用同一个引用计数）。所以：

如果你把一个 slice/duplicate 交给异步任务，或存进集合长期持有，而原 buffer 可能先被 release——那么原 buffer 释放后，这个切片就悬空了（指向已回收的内存）。
正确做法：把切片交给异步/长期持有前，retain() 增加引用计数，用完再 release()。

核心判断：共享视图省内存，但要把 retain/release 的关系想清楚，否则原 buffer 释放后视图悬空。

六、泄漏检测工具（ResourceLeakDetector）

Netty 提供 ResourceLeakDetector 帮助定位泄漏，有几个级别：

DISABLED：关闭。
SIMPLE（默认）：抽样检测（约 1% 的 ByteBuf），开销小，只报「有泄漏」。
ADVANCED：抽样 + 记录最近的访问位置（能看到泄漏的 ByteBuf 最后在哪被访问）。
PARANOID：每个 ByteBuf 都检测 + 记录访问，开销大，只用于测试/压测。

开发和压测阶段提高到 ADVANCED/PARANOID，能拿到「泄漏对象最后的访问栈」，直接定位「哪个 Handler 忘了 release」。生产环境用 SIMPLE（权衡开销）。

七、排查方法

排查 ByteBuf 内存泄漏的信号和步骤：

看 direct memory（堆外内存）增长——泄漏的堆外内存不受 GC 管理，会持续上涨。
GC 正常但进程内存持续上涨——典型的堆外内存泄漏特征（堆内正常，进程 RSS 涨）。
看 ResourceLeakDetector 的泄漏日志——尤其 ADVANCED 级别的「最近访问位置」。
重点检查：Handler 的异常路径（有没有在 finally release）、跨线程传递（有没有 retain）。

修复：用 try/finally 包住消费逻辑，在 finally 里 release；明确每条分支的引用所有权（每个分支都要么传下去、要么 release）。

八、常见误区与追问

误区：ByteBuf 泄漏主要靠 GC 调优解决。 泄漏来自引用计数没有归零，GC 无法替你把池化/堆外内存按业务所有权归还。
误区：调用 fireChannelRead 后还应该继续 release。 通常传播就意味着所有权交给后续 Handler，当前节点再释放可能导致后续访问已释放内存。
误区：SimpleChannelInboundHandler 里异步使用消息不需要额外处理。 channelRead0 返回后框架会自动释放消息，异步任务使用前必须 retain()。
追问：retain() 的语义是什么？ 表示多了一个持有者，引用计数加一；这个持有者用完后也必须 release()。
追问：泄漏检测为什么开发环境可以开 PARANOID？ 它会检测每个 ByteBuf 并记录访问路径，定位更准，但开销大，不适合长期生产开启。
追问：slice() 为什么容易和泄漏或悬空访问相关？ 它共享底层内存和引用计数关系，长期持有或跨线程传递时必须明确 retain/release，否则可能提前释放或永不释放。

九、加强记忆

Netty 池化/堆外 ByteBuf 用引用计数管生命周期（不能靠 GC 及时回收）：retain() +1（多个持有者）、release() -1（用完），归零则回收/归还池；release 后访问抛 IllegalReferenceCountException、忘 release 则泄漏。核心规则「谁持有谁释放，传下去（fireChannelRead）就转移责任；自己消费不传播就必须自己 release（finally）」。泄漏三来源：① 异常路径漏 release、② 异步/跨线程传递忘 retain（SimpleChannelInboundHandler 方法返回就自动 release，异步用要先 retain）、③ slice/duplicate 共享内存后原 buffer 释放导致视图悬空（长期/异步持有要 retain）。排查：direct memory 涨 + GC 正常但进程内存涨 + ResourceLeakDetector（开发用 ADVANCED/PARANOID 看访问栈、生产用 SIMPLE）。修复用 try/finally + 理清每分支所有权。核心：泄漏多数不是算法错，是所有权没交代清楚。

简化版

详细版