Netty 4におけるバッファの所有権：バッファのライフサイクルはどのように管理されますか？

Question

私はNetty 4を習得するための練習として複数のフィードを同時に（1kまで）取り出すためにHTTPクライアントを作成しようとしてきました。

私の質問はどこか新しいByteBufインフラストラクチャは機能しますか？誰が彼らを「所有しているか」、彼らはどのように共有されていますか？ ChannelPipeline内のすべてのChannelHandlerには独自のByteBufがありますか？困惑ここ

は私を残し例である：私はMSGでBufUtil.retainを呼び出さない場合

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; 
} 

、：

を私は、HTTPクライアントのパイプラインに次のクラスのインスタンスを追加しましたそれはGCdを取得するようだと私はあらゆる種類の偽のエラーを取得します。

Answer 1

HttpContentReferenceCountedは、保持するバッファのライフサイクルを追跡するために使用します。 ReferenceCountedがインスタンス化されると、refCntが1で始まります。 retain()を呼び出すと、refCntが増加します。 refCntはrelease()で減少し、refCntが0になると、基礎リソース（この場合はByteBuf）が破棄されます。

通常、ハンドラは処理が完了したメッセージへの参照を保持する必要はありません。通常、メッセージは処理されたときに別のものにスローされたり変形されたりするためです。したがって、ハンドラを使用してメッセージを処理した後は、release()メソッドを呼び出す必要があります。これはしばしばエラーを起こしやすく、リソースリークを非常に容易にします。

追跡が非常に困難なリークを回避するには、SimpleChannelInboundHandlerを拡張して、処理後にメッセージに自動的にrelease()を呼び出します。

Nettyの参照カウントの詳細については、this wiki pageを参照してください。また、Nettyのバッファーリーク検出メカニズムを使用してバッファーリークのトラブルシューティングを行う方法についての詳細情報も提供します。