Netty 4 中的缓冲区所有权：如何管理缓冲区生命周期？

我一直在尝试编写一个 HTTP 客户端来同时获取多个提要（最多 1k），同时也是学习 Netty 4 的练习。

我的问题是，是否有关于新 ByteBuf 基础设施如何工作的很好的解释？谁“拥有”它们，它们如何共享（是吗？）？ ChannelPipeline 中的每个 ChannelHandler 是否都有自己的 ByteBuf？

这是一个让我困惑的例子：

我将以下类的实例添加到 HTTP 客户端管道：

public class MyFilter extends MessageToMessageDecoder<HttpObject> {

    @Override
    protected Object decode(ChannelHandlerContext ctx, HttpObject msg) throws Exception {
        // do some work, but leave msg unchanged
        BufUtil.retain(msg); // Why do I need to call BufUtil.retain(msg) ???
        return msg;
}

如果我不在 msg 上调用 BufUtil.retain，它似乎会收到 GCd，并且会收到各种虚假错误。

HttpContent延伸ReferenceCounted跟踪它所持有的缓冲区的生命周期。当一个ReferenceCounted被实例化，它的生命开始于refCnt of 1。如果你打电话retain() on it, refCnt增加了。refCnt减少于release()，以及底层资源（ByteBuf在这种情况下）被销毁一次refCnt变成0.

通常，处理程序不需要保留对其完成处理的消息的引用，因为消息一旦处理后通常会被丢弃或转换为其他内容。所以，release()一旦处理程序完成处理消息，就必须对消息调用方法。这通常很容易出错，并且很容易导致资源泄漏。

为了避免很难追踪的泄漏，请延长SimpleChannelInboundHandler哪个调用release()处理消息后自动显示消息。

有关 Netty 中引用计数的更多信息，请阅读这个维基页面。它还为您提供了有关如何利用 Netty 的缓冲区泄漏检测机制来解决缓冲区泄漏问题的详细信息。