公開リソースを理解する

Question

私はHTTPリクエスト/レスポンスを処理するためにNettyを使用しています。そして、パイプラインにダウンし、次のByteBuf書き込み：ログで

public class MyBusinessLogic 
extends ChannelInboundHandlerAdapter{ 
    public void channelRead(ChannelHandlerContext ctx, Object msg){ 
     ByteBuf bb = ctx.alloc().buffer().writeBytes(//some bytes) 
     ctx.writeAndFlush(bb, ctx.newPromise()) 
     //I did not release bb here 
    } 
} 

を私は持って警告いくつかの類似したに「ByteBuf was garbage collected before it was released」...それに似たもの。

なぜ私たちは自分でByteBufをリリースする必要がありますか？彼らはとにかくゴミ収集されています。 bbをここに公開しないと、私はどのような悪いトラブルに遭遇できますか？

チャンネルの将来のリスナーとしてリリースするバッファを追加するだけですか？

ByteBuf bb = // 
ctx.writeAndFlush(response, ctx.newPromise()) 
.addListener(new ChannelFutureListener(){ 
    public void operationComplete(ChannelFuture f){ 
     buf.release() 
    } 
}); 

Answer 1

http://netty.io/wiki/reference-counted-objects.htmlによれば、網状オブジェクトにそれら（又はそれらの共有リソース）を返すことができるように

網状バージョン4は、特定のオブジェクトのライフサイクルは、その参照カウントで管理されていますプール（またはオブジェクト・アロケータ）を使用しなくなったらすぐに使用できます。ガベージコレクションおよび参照キューは、到達不能のようなリアルタイムの効率的な保証を提供しませんが、参照カウントはわずかな不便を犠牲にして代替メカニズムを提供します。

しかしこれは完全な説明ではありません。 Netty ByteBufは、直接HEAPメモリにアクセスすることもできます。このメモリは、ガベージコレクタがいっぱいになったときに実行されない代わりに例外をスローするような特殊なメモリです。

Nettyがヒープメモリにアクセスしようとする理由は基本的には、ファイルからソケットに、またはソケット1からソケット2にコピーするような "チャンネル"で動作するものであれば、これは、配列を使って同じことをするよりもはるかに優れた性能を持っています。下位レベルは最初にそれをJava配列に変換してから、パケットを送信するときに再び戻す必要があります。

ヒープ（直接）メモリがガベージコレクタと連動するため、作成されるオブジェクトがNetty ByteBufsである特定のケースでは、ヒープメモリがガベージコレクタの呼び出し間でいっぱいになり、ガベージコレクタからの視点からは、メモリは最初は一杯ではなかったからです。ガベージコレクターのこのクォークのおかげで、Nettyは基本的にリリースメソッドを作成して、もはやメモリが不要になったときに直接リリースする必要がありました。