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

Question

我一直在尝试编写一个 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，并且我会得到各种虚假错误。

Answer 1

HttpContent 扩展 ReferenceCounted 以跟踪它所持有的缓冲区的生命周期。当 ReferenceCounted 被实例化时，它的生命周期以 refCnt 或 1 开始。如果您在其上调用retain()，则增加refCnt。 refCnt 在release() 上减少，并且一旦refCnt 变为0，底层资源（在这种情况下为ByteBuf）就会被销毁。

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

为避免难以追踪的泄漏，请扩展 SimpleChannelInboundHandler，它会在处理完消息后自动调用 release()。

有关 Netty 中引用计数的更多信息，请阅读this wiki page。它还为您提供了有关如何利用 Netty 的缓冲区泄漏检测机制排除缓冲区泄漏的详细信息。