隨著JVM虛擬機器和JIT即時編譯技術的發展，物件的分配和回收是個非常輕量級的工作。但是對於緩衝區Buffer，情況卻稍有不同，特別是對於堆外直接記憶體的分配和回收，是一件耗時的操作。為了儘量重用緩衝區，Netty提供了基於記憶體池的緩衝區重用機制。效能測試表明，採用記憶體池的ByteBuf相比於朝生夕滅的ByteBuf，效能高23倍左右（效能資料與使用場景強相關）。

在4.x版本中，UnpooledByteBufAllocator是預設的allocator，儘管其存在某些限制。現在PooledByteBufAllocator已經廣泛使用一段時間，並且我們有了增強的緩衝區洩漏追蹤機制，所以是時候讓PooledByteBufAllocator成為默認了。

優化前:

在玩家達到1100左右時直接記憶體迅速升高，CPU佔用也飆高,

在最高峰時，伺服器堆記憶體總共 3993 M,佔用堆記憶體 3476 M,直接記憶體總共 2048 M,佔用直接記憶體 715.8125 M。

發現netty底層的物件佔用了很多

優化，猜測是因為直接記憶體不夠用，在反覆申請空間，導致CPU佔用，並且直接記憶體一直回收不掉！使用物件池後，1380人，CPU佔用大概為100/1200,表現很穩定，FULLGC 次數為0

伺服器堆記憶體總共 3993 M,佔用堆記憶體 2150 M,直接記憶體總共 2048 M,佔用直接記憶體 400.00098 M

 S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT      0.00   0.71   8.87  15.05  71.87    175    2.638     0    0.000    2.638

主要是加了以下兩句:

bootstrap.option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT); bootstrap.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT);//關鍵是這句

總結：這次優化，記憶體省下1.7G，直接記憶體剩下300M，並且表現穩定，線上人數提升了300人（可能受頻寬的限制，否則表現應該會更好），CPU從佔用100%降到10%。

--------------------- 本文來自 流子 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/jiangguilong2000/article/details/39501541?utm_source=copy