ByteBuf接口提供了一套簡單易用的API，并實現(xiàn)了對NIO ByteBuffer的兼容，其實現(xiàn)有“非池化的堆內存Buffer”，“非池化的直接內存Buffer”，“池化的堆內存Buffer”，“池化的直接內存Buffer”，另外ByteBuf的實現(xiàn)提供了對內存泄漏不同級別的監(jiān)控。

ByteBuf的內存池實現(xiàn)，ByteBuf對內存泄漏的監(jiān)控，是我比較感興趣的兩個地方。

1.ByteBuf的內存池實現(xiàn)

  這里是最繁雜、最難的部分，這里后面補上。

2.ByteBuf對內存泄露的監(jiān)控
Netty的內存監(jiān)控是針對內存池和直接內存而言的，對于HeapByteBuf自有虛擬機完成GC。

對于內存池而言，內存泄漏產生在Buffer已經使用完，但是這塊內存還沒有歸還給內存池，對于直接內存的內存泄漏，是Buffer使用完，直接內存沒有被回收（虛擬機不會自動回收直接內存）。

ByteBuf有release和retain兩個接口，由AbstractReferenceCountedByteBuf實現(xiàn)，分別表示對Buffer引用數(shù)目的減少和增加，當release后引用數(shù)目為0時，會對Buffer進行回收。對于內存池內的Buffer以及直接內存Buffer需要我們顯式調用release進行回收。忘記調用release方法就會發(fā)生內存泄漏，特別是對于內存池而言，內存池會不斷變大占用大量內存。

對于內存泄漏的監(jiān)控，Netty有四個級別：Disabled，Simple，Advanced，Paranoid；分別對應不同的監(jiān)控頻率和性能損耗。那么Netty是如何實現(xiàn)內存監(jiān)控的呢？

可以查看AbstractByteBufAllocator類的toLeakAwareBuffer方法，這里實際上利用了裝飾器模式，以SimpleLeakAwareByteBuf為例，它持有實際起作用的ByteBuf實例，以及一個ResourceLeakTracker，ResourceLeakTracker的實現(xiàn)類DefaultResourceLeak繼承了PhantomReference，ResourceLeakDetector將一個ReferenceQueue傳入ResourceLeakTracker，這樣在SimpleLeakAwareByteBuf引用被回收后，ReferenceQueue就被插入對應的refernce，我們就可以知道某個ByteBuf不再被使用了。

但是我們如何得知這個ByteBuf是否被釋放了呢？

這是由一個ConcurrentHashMap來決定的，它存儲的key就是DefaultResourceLeak（value應該是內存泄露的相關信息），當調用release并確定可以回收時，會把map中對應的key清除掉，這樣ResourceLeakDetector會定期檢查ReferenceQueue，當其中存在reference時，會查看map中是否也存在，如果也存在，那么就可以確認發(fā)生內存泄露了。
（ReferenceQueue和ConcurrentHashMap都在ResourceLeakDetector中）

簡而言之，這種ByteBuf持有了一個繼承PhantomReference的ResourceLeakTracker，當ByteBuf被回收時，會向ReferenceQueue傳入一個對象ResourceLeakTracker；而這種ByteBuf創(chuàng)建（retain）時，會向一個ConcurrentHashMap存入，key為ResourceLeakTracker，value為其他信息；當ByteBuf回收（release）時，會將map中對應的記錄刪除。這樣當ReferenceQueue中存在，而map中也存在時，就發(fā)生了內存泄漏。

關于內存泄露監(jiān)控機制的不同級別，以Simple為例，我們查看AbstractByteBufAllocator的toLeakAwareBuffer方法，一路查到ResourceLeakDetector的track0方法，該方法內可以看到實際上是使用線程安全的隨機數(shù)對設定的參數(shù)（默認應該是100）取余為0時，返回DefaultResourceLeak，并檢查是否發(fā)生內存泄漏，否則返回null，當級別為Disable時，直接返回null，并不做檢查，這樣就沒有性能損耗了。