自從Netty 4開始，物件的生命週期由它們的引用計數（reference counts）管理，而不是由垃圾收集器（garbage collector）管理了。ByteBuf是最值得注意的，它使用了引用計數來改進分配記憶體和釋放記憶體的效能。

基本的引用計數

每個物件的初始計數為1：

Java程式碼  

1. ByteBuf buf = ctx.alloc().directBuffer();  
2. assert buf.refCnt() == 1;  

當你釋放（release）引用計數物件時，它的引用計數減1.如果引用計數為0，這個引用計數物件會被釋放（deallocate），並返回物件池。

Java程式碼  

1. assert buf.refCnt() == 1;  
2. // release() returns true only if the reference count becomes 0.
3. boolean destroyed = buf.release();  
4. assert destroyed;  
5. assert buf.refCnt() == 0;  

 懸垂（dangling）引用

嘗試訪問引用計數為0的引用計數物件會丟擲IllegalReferenceCountException異常：

Java程式碼  

1. assert buf.refCnt() == 0;  
2. try
    {  
3.   buf.writeLong(0xdeadbeef);  
4.   thrownew Error("should not reach here");  
5. } catch (IllegalReferenceCountExeception e) {  
6.   // Expected
7. }  

增加引用計數

可通過retain()操作來增加引用計數，前提是此引用計數物件未被銷燬：

（譯者注：跟未使用ARC的objective-c好像）

Java程式碼  

1. ByteBuf buf = ctx.alloc().directBuffer();  
2. assert buf.refCnt() == 1;  
3. buf.retain();  
4. assert buf.refCnt() == 2;  
5. boolean destroyed = buf.release();  
6. assert !destroyed;  
7. assert buf.refCnt() == 1;  

誰來銷燬（destroy）

通常的經驗法則是誰最後訪問（access）了引用計數物件，誰就負責銷燬（destruction）它。具體來說是以下兩點：

• 如果元件（component）A把一個引用計數物件傳給另一個元件B，那麼元件A通常不需要銷燬物件，而是把決定權交給元件B。
• 如果一個元件不再訪問一個引用計數物件了，那麼這個元件負責銷燬它。

下面是一個簡單的例子：

Java程式碼  

1. public ByteBuf a(ByteBuf input) {  
2.     input.writeByte(42);  
3.     return input;  
4. }  
5. public ByteBuf b(ByteBuf input) {  
6.     try {  
7.         output = input.alloc().directBuffer(input.readableBytes() + 1);  
8.         output.writeBytes(input);  
9.         output.writeByte(42);  
10.         return output;  
11.     } finally {  
12.         input.release();  
13.     }  
14. }  
15. publicvoid c(ByteBuf input) {  
16.     System.out.println(input);  
17.     input.release();  
18. }  
19. publicvoid main() {  
20.     ...  
21.     ByteBuf buf = ...;  
22.     // This will print buf to System.out and destroy it.
23.     c(b(a(buf)));  
24.     assert buf.refCnt() == 0;  
25. }  

行為（Action）                          誰來釋放（Who should release）?   誰釋放了（Who released）?

1. main()建立了buf                    buf→main()

2. buf由main()傳給了a()            buf→a()

3. a()僅僅返回了buf                   buf→main()

4. buf由main()傳給了b()            buf→b()

5. b()返回了buf的拷貝               buf→b(), copy→main()                       b()釋放了buf

6. 拷貝由main()傳給了c()          copy→c()

7. c()消耗（swallow）了拷貝     copy→c()                                           c()釋放了拷貝 

子緩衝（Derived buffers）

ByteBuf.duplicate(), ByteBuf.slice()和ByteBuf.order(ByteOrder)建立了子緩衝，這些快取共享了它們的父緩衝（parent buffer）的一部分記憶體。子緩衝沒有自己的引用計數，而是共享父緩衝的引用計數。

Java程式碼  

1. ByteBuf parent = ctx.alloc().directBuffer();  
2. ByteBuf derived = parent.duplicate();  
3. // Creating a derived buffer does not increase the reference count.
4. assert parent.refCnt() == 1;  
5. assert derived.refCnt() == 1;  

注意父緩衝和它的子緩衝共享同樣的引用計數，當建立子緩衝時並不會增加物件的引用計數。因此，如果你要傳遞（pass）一個子緩衝給你的程式中的其他元件的話，你得先呼叫retain()。

Java程式碼  

1. ByteBuf parent = ctx.alloc().directBuffer(512);  
2. parent.writeBytes(...);  
3. try {  
4.     while (parent.isReadable(16)) {  
5.         ByteBuf derived = parent.readSlice(16);  
6.         derived.retain();  
7.         process(derived);  
8.     }  
9. } finally {  
10.     parent.release();  
11. }  
12. ...  
13. publicvoid process(ByteBuf buf) {  
14.     ...  
15.     buf.release();  
16. }  

ByteBufHolder介面

有時候，一個ByteBuf被一個buffer holder持有，諸如DatagramPacket, HttpContent,和WebSocketframe。它們都擴充套件了一個公共介面，ByteBufHolder。

一個buffer holder共享它所持有的引用計數，如同子緩衝一樣。

ChannelHandler中的引用計數

Inbound訊息（messages）

當一個事件迴圈（event loop）讀入了資料，用讀入的資料建立了ByteBuf，並用這個ByteBuf觸發了一個channelRead()事件時，那麼管道（pipeline）中相應的ChannelHandler就負責釋放這個buffer。因此，處理接收到的資料的handler應該在它的channelRead()中呼叫buffer的release()。

Java程式碼  

1. publicvoid channelRead(ChannelHandlerContext ctx, Object msg) {  
2.     ByteBuf buf = (ByteBuf) msg;  
3.     try {  
4.         ...  
5.     } finally {  
6.         buf.release();  
7.     }  
8. }  

如同在本文件中的“誰來銷燬”一節所解釋的那樣，如果你的handler傳遞了快取（或任何引用計數物件）到下一個handler，你就不需要釋放它：

Java程式碼  

1. publicvoid channelRead(ChannelHandlerContext ctx, Object msg) {  
2.     ByteBuf buf = (ByteBuf) msg;  
3.     ...  
4.     ctx.fireChannelRead(buf);  
5. }  

注意ByteBuf不是Netty中唯一一種引用計數物件。由解碼器（decoder）生成的訊息（messages）物件，這些物件很可能也是引用計數物件：

Java程式碼  

1. // Assuming your handler is placed next to `HttpRequestDecoder`
2. publicvoid channelRead(ChannelHandlerContext ctx, Object msg) {  
3.     if (msg instanceof HttpRequest) {  
4.         HttpRequest req = (HttpRequest) msg;  
5.         ...  
6.     }  
7.     if (msg instanceof HttpContent) {  
8.         HttpContent content = (HttpContent) msg;  
9.         try {  
10.             ...  
11.         } finally {  
12.             content.release();  
13.         }  
14.     }  
15. }  

如果你抱有疑問，或者你想簡化這些釋放訊息的工作，你可以使用ReferenceCountUtil.release()：

Java程式碼  

1. publicvoid channelRead(ChannelHandlerContext ctx, Object msg) {  
2.     try {  
3.         ...  
4.     } finally {  
5.         ReferenceCountUtil.release(msg);  
6.     }  
7. }  

還有一種選擇，你可以考慮繼承SimpleChannelHandler，它在所有接收訊息的地方都呼叫了ReferenceCountUtil.release(msg)。

Outbound訊息（messages）

與inbound訊息不同，你的程式所建立的訊息物件，由Netty負責釋放，釋放的時機是在這些訊息被髮送到網路之後。但是，在傳送訊息的過程中，如果有handler截獲（intercept）了你的傳送請求，並建立了一些中間物件，則這些handler要確保正確釋放這些中間物件。比如編碼器（encoder）。

Java程式碼  

1. // Simple-pass through
2. publicvoid write(ChannelHandlerContext ctx, Object message, ChannelPromise promise) {  
3.     System.err.println("Writing: " + message);  
4.     ctx.write(message, promise);  
5. }  
6. // Transformation
7. publicvoid write(ChannelHandlerContext ctx, Object message, ChannelPromise promise) {  
8.     if (message instanceof HttpContent) {  
9.         // Transform HttpContent to ByteBuf.
10.         HttpContent content = (HttpContent) message;  
11.         try {  
12.             ByteBuf transformed = ctx.alloc().buffer();  
13.             ....  
14.             ctx.write(transformed, promise);  
15.         } finally {  
16.             content.release();  
17.         }  
18.     } else {  
19.         // Pass non-HttpContent through.
20.         ctx.write(message, promise);  
21.     }  
22. }  

解決（troubleshooting）buffer洩露

引用計數的缺點是容易發生洩露。因為JVM並不知道Netty實現的引用計數的存在，一旦某些物件不可達（unreachable）就會被自動GC掉，即使這些物件的引用計數不為0。被GC掉的物件就不可用了，因此這些物件也就不能回到物件池中，或者產生記憶體洩露。

幸運的是，儘管要找到洩露很困難，但Netty提供了一種方案來幫助發現洩露，此方案預設在你的程式中的已分配的緩衝中取樣（sample）大約1%的快取，來檢查是否存在洩露。如果存在洩露，你會發現如下日誌：

Plain text程式碼  

1. LEAK: ByteBuf.release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, specify the JVM option '-Dio.netty.leakDetectionLevel=advanced' or call ResourceLeakDetector.setLevel()  

上述日誌中提到的JVM選項（option）重新啟動你的程式，你可以看到在你的程式中最近訪問已洩露的記憶體的位置（location）。下列輸出展示了來自單元測試的一個洩露問題(XmlFrameDecoderTest.testDecodeWithXml())：

Java程式碼  

1. Running io.netty.handler.codec.xml.XmlFrameDecoderTest  
2. 15:03:36.886 [main] ERROR io.netty.util.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected.  
3. Recent access records: 1
4. #1:  
5.     io.netty.buffer.AdvancedLeakAwareByteBuf.toString(AdvancedLeakAwareByteBuf.java:697)  
6.     io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithXml(XmlFrameDecoderTest.java:157)  
7.     io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithTwoMessages(XmlFrameDecoderTest.java:133)  
8.     ...  
9. Created at:  
10.     io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:55)  
11.     io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:155)  
12.     io.netty.buffer.UnpooledUnsafeDirectByteBuf.copy(UnpooledUnsafeDirectByteBuf.java:465)  
13.     io.netty.buffer.WrappedByteBuf.copy(WrappedByteBuf.java:697)  
14.     io.netty.buffer.AdvancedLeakAwareByteBuf.copy(AdvancedLeakAwareByteBuf.java:656)  
15.     io.netty.handler.codec.xml.XmlFrameDecoder.extractFrame(XmlFrameDecoder.java:198)  
16.     io.netty.handler.codec.xml.XmlFrameDecoder.decode(XmlFrameDecoder.java:174)  
17.     io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:227)  
18.     io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:140)  
19.     io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:74)  
20.     io.netty.channel.embedded.EmbeddedEventLoop.invokeChannelRead(EmbeddedEventLoop.java:142)  
21.     io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:317)  
22.     io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)  
23.     io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:176)  
24.     io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithXml(XmlFrameDecoderTest.java:147)  
25.     io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithTwoMessages(XmlFrameDecoderTest.java:133)  
26.     ...  

如果你使用Netty 5或以上的版本，還提供了一個額外的資訊，幫助我們找到最後操作了（handle）洩露緩衝的handler。下面的例子展示了名為EchoServerHandler#0的handler操作了已洩露的緩衝，並且緩衝已被GC了，這意味著EchoServerHandler#0忘記釋放了這個buffer：

Java程式碼  

1. 12:05:24.374 [nioEventLoop-1-1] ERROR io.netty.util.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected.  
2. Recent access records: 2
3. #2:  
4.     Hint: 'EchoServerHandler#0' will handle the message from this point.  
5.     io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:329)  
6.     io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)  
7.     io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:133)  
8.     io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:485)  
9.     io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:452)  
10.     io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:346)  
11.     io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:794)  
12.     java.lang.Thread.run(Thread.java:744)  
13. #1:  
14.     io.netty.buffer.AdvancedLeakAwareByteBuf.writeBytes(AdvancedLeakAwareByteBuf.java:589)  
15.     io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:208)  
16.     io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)  
17.     io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:485)  
18.     io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:452)  
19.     io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:346)  
20.     io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:794)  
21.     java.lang.Thread.run(Thread.java:744)  
22. Created at:  
23.     io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:55)  
24.     io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:155)  
25.     io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:146)  
26.     io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:107)  
27.     io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:123)  
28.     io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:485)  
29.     io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:452)  
30.     io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:346)  
31.     io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:794)  
32.     java.lang.Thread.run(Thread.java:744)  

洩露檢測級別

當前有4個洩露檢測級別：

• 禁用（DISABLED）   - 完全禁止洩露檢測。不推薦。
• 簡單（SIMPLE）       - 告訴我們取樣的1%的緩衝是否發生了洩露。預設。
• 高階（ADVANCED） - 告訴我們取樣的1%的緩衝發生洩露的地方
• 偏執（PARANOID）  - 跟高階選項類似，但此選項檢測所有緩衝，而不僅僅是取樣的那1%。此選項在自動測試階段很有用。如果構建（build）輸出包含了LEAK，可認為構建失敗。

你可以使用JVM的-Dio.netty.leakDetectionLevel選項來指定洩漏檢測級別。

Bash程式碼  

1. java -Dio.netty.leakDetectionLevel=advanced ...  

避免洩露的最佳實踐

• 在簡單級別和偏執級別上執行你的單元測試和整合測試（integration tests）。
• 在rolling out到整個叢集之前，使用簡單級別，以一個合理的、足夠長的時間canary（金絲雀？不明所以。。）你的程式，來發現是否存在洩露。
• 如果存在洩露，再用高階級別來canary以獲得一些關於洩露的提示。
• 不要部署存在洩露的程式到整個叢集。

在單元測試中修復洩露問題

在單元測試中很容易忘記釋放緩衝。這會產生一個洩露的警告，但並不是說就肯定存在洩露。你可以使用ReferenceCountUtil.releaseLater()工具方法，放棄用try-finally來包裹你的單元測試程式碼以釋放所有的緩衝：

Java程式碼  

1. importstatic io.netty.util.ReferenceCountUtil.*;  
2. @Test
3. publicvoid testSomething() throws Exception {  
4.     // ReferenceCountUtil.releaseLater() will keep the reference of buf,
5.     // and then release it when the test thread is terminated.
6.     ByteBuf buf = releaseLater(Unpooled.directBuffer(512));  
7.     ...  
8. }