在使用netty 的時候，發現讓單機的支援量加大的時候，記憶體也隨著程式的執行一直增長，原因就是因為ByteBuf物件的建立方式不夠合理。現做簡單的分析和整理：

ByteBuf是netty中提供的一種資料結構，經過檢視原始碼發現，建立ByteBuf物件主要有兩種方式：

UnpooledByteBufAllocator：預設的建立方式

PooledByteBufAllocator：不是預設的，可以重複利用之前分配的記憶體空間。

這兩個類，都是AbstractByteBufAllocator的子類，

AbstractByteBufAllocator實現了一個介面，叫做ByteBufAllocator。

在使用預設的UnpooledByteBufAllocator的方式建立ByteBuf的時候，單臺24核CPU的伺服器，16G記憶體，剛啟動時候，10000個長連線，每隔幾秒就發一條群組訊息，記憶體佔到10G多點，但隨著系統的執行，記憶體不斷增長，直到整個系統記憶體溢位掛掉。

把UnpooledByteBufAllocator換成PooledByteBufAllocator，記憶體使用量機器能維持在一個連線佔用0.9-1M之間，經常長期的執行測試，發現都能維持在這個數量。

使用方法如下：

另外ChannelOption中的引數也有很多可以優化的。

另外發現了一片類似問題的部落格。

Netty5.0的功能也是越來越強大，所以直接就把原來的3.6的版本系統直接升級到了5.0的，需要說明的是Netty5.0一定要配合JDK7 64位才能表現良好。在學習和使用Netty5.0中發現使用的Reactor執行緒模型，能使得對CPU的利用達到飽和狀態，是併發程式設計的首選。

關於Netty5的一些新特性，也看到有人整理的資料，轉載一下：