1. 背景

1.1. 話題來源

最近很多從事移動(dòng)互聯(lián)網(wǎng)和物聯(lián)網(wǎng)開發(fā)的同學(xué)給我發(fā)郵件或者微博私信我，咨詢推送服務(wù)相關(guān)的問題。問題五花八門，在幫助大家答疑解惑的過程中，我也對(duì)問題進(jìn)行了總結(jié)，大概可以歸納為如下幾類：

1，Netty是否可以做推送服務(wù)器？

2，如果使用Netty開發(fā)推送服務(wù)，一個(gè)服務(wù)器最多可以支撐多少個(gè)客戶端？

3，使用Netty開發(fā)推送服務(wù)遇到的各種技術(shù)問題。

由于咨詢者眾多，關(guān)注點(diǎn)也比較集中，我希望通過本文的案例分析和對(duì)推送服務(wù)設(shè)計(jì)要點(diǎn)的總結(jié)，幫助大家在實(shí)際工作中少走彎路。

1.2. 推送服務(wù)

移動(dòng)互聯(lián)網(wǎng)時(shí)代，推送(Push)服務(wù)成為App應(yīng)用不可或缺的重要組成部分，推送服務(wù)可以提升用戶的活躍度和留存率。我們的手機(jī)每天接收到各種各樣的廣告和提示消息等大多數(shù)都是通過推送服務(wù)實(shí)現(xiàn)的。

隨著物聯(lián)網(wǎng)的發(fā)展，大多數(shù)的智能家居都支持移動(dòng)推送服務(wù)，未來所有接入物聯(lián)網(wǎng)的智能設(shè)備都將是推送服務(wù)的客戶端，這就意味著推送服務(wù)未來會(huì)面臨海量的設(shè)備和終端接入。

1.3. 推送服務(wù)的特點(diǎn)

移動(dòng)推送服務(wù)的主要特點(diǎn)如下：

1，使用的網(wǎng)絡(luò)主要是運(yùn)營(yíng)商的無線移動(dòng)網(wǎng)絡(luò)，網(wǎng)絡(luò)質(zhì)量不穩(wěn)定，例如在地鐵上信號(hào)就很差，容易發(fā)生網(wǎng)絡(luò)閃斷；

2，海量的客戶端接入，而且通常使用長(zhǎng)連接，無論是客戶端還是服務(wù)端，資源消耗都非常大；

3，由于谷歌的推送框架無法在國(guó)內(nèi)使用，Android的長(zhǎng)連接是由每個(gè)應(yīng)用各自維護(hù)的，這就意味著每臺(tái)安卓設(shè)備上會(huì)存在多個(gè)長(zhǎng)連接。即便沒有消息需要推送，長(zhǎng)連接本身的心跳消息量也是非常巨大的，這就會(huì)導(dǎo)致流量和耗電量的增加；

4，不穩(wěn)定：消息丟失、重復(fù)推送、延遲送達(dá)、過期推送時(shí)有發(fā)生；

5，垃圾消息滿天飛，缺乏統(tǒng)一的服務(wù)治理能力。

為了解決上述弊端，一些企業(yè)也給出了自己的解決方案，例如京東云推出的推送服務(wù)，可以實(shí)現(xiàn)多應(yīng)用單服務(wù)單連接模式，使用AlarmManager定時(shí)心跳節(jié)省電量和流量。

2. 智能家居領(lǐng)域一個(gè)真實(shí)案例

2.1. 問題描述

智能家居MQTT消息服務(wù)中間件，保持10萬用戶在線長(zhǎng)連接，2萬用戶并發(fā)做消息請(qǐng)求。程序運(yùn)行一段時(shí)間之后，發(fā)現(xiàn)內(nèi)存泄露，懷疑是Netty的Bug。其它相關(guān)信息如下：

1，MQTT消息服務(wù)中間件服務(wù)器內(nèi)存16G，8個(gè)核心CPU；

2，Netty中boss線程池大小為1，worker線程池大小為6，其余線程分配給業(yè)務(wù)使用。該分配方式后來調(diào)整為worker線程池大小為11，問題依舊；

3，Netty版本為4.0.8.Final。

2.2. 問題定位

首先需要dump內(nèi)存堆棧，對(duì)疑似內(nèi)存泄露的對(duì)象和引用關(guān)系進(jìn)行分析，如下所示：

我們發(fā)現(xiàn)Netty的ScheduledFutureTask增加了9076%，達(dá)到110W個(gè)左右的實(shí)例，通過對(duì)業(yè)務(wù)代碼的分析發(fā)現(xiàn)用戶使用IdleStateHandler用于在鏈路空閑時(shí)進(jìn)行業(yè)務(wù)邏輯處理，但是空閑時(shí)間設(shè)置的比較大，為15分鐘。

Netty的IdleStateHandler會(huì)根據(jù)用戶的使用場(chǎng)景，啟動(dòng)三類定時(shí)任務(wù)，分別是：ReaderIdleTimeoutTask、WriterIdleTimeoutTask和AllIdleTimeoutTask，它們都會(huì)被加入到NioEventLoop的Task隊(duì)列中被調(diào)度和執(zhí)行。

由于超時(shí)時(shí)間過長(zhǎng)，10W個(gè)長(zhǎng)鏈接鏈路會(huì)創(chuàng)建10W個(gè)ScheduledFutureTask對(duì)象，每個(gè)對(duì)象還保存有業(yè)務(wù)的成員變量，非常消耗內(nèi)存。用戶的持久代設(shè)置的比較大，一些定時(shí)任務(wù)被老化到持久代中，沒有被JVM垃圾回收掉，內(nèi)存一直在增長(zhǎng)，用戶誤認(rèn)為存在內(nèi)存泄露。

事實(shí)上，我們進(jìn)一步分析發(fā)現(xiàn)，用戶的超時(shí)時(shí)間設(shè)置的非常不合理，15分鐘的超時(shí)達(dá)不到設(shè)計(jì)目標(biāo)，重新設(shè)計(jì)之后將超時(shí)時(shí)間設(shè)置為45秒，內(nèi)存可以正常回收，問題解決。

2.3. 問題總結(jié)

如果是100個(gè)長(zhǎng)連接，即便是長(zhǎng)周期的定時(shí)任務(wù)，也不存在內(nèi)存泄露問題，在新生代通過minor GC就可以實(shí)現(xiàn)內(nèi)存回收。正是因?yàn)槭f級(jí)的長(zhǎng)連接，導(dǎo)致小問題被放大，引出了后續(xù)的各種問題。

事實(shí)上，如果用戶確實(shí)有長(zhǎng)周期運(yùn)行的定時(shí)任務(wù)，該如何處理？對(duì)于海量長(zhǎng)連接的推送服務(wù)，代碼處理稍有不慎，就滿盤皆輸，下面我們針對(duì)Netty的架構(gòu)特點(diǎn)，介紹下如何使用Netty實(shí)現(xiàn)百萬級(jí)客戶端的推送服務(wù)。

3. Netty海量推送服務(wù)設(shè)計(jì)要點(diǎn)

作為高性能的NIO框架，利用Netty開發(fā)高效的推送服務(wù)技術(shù)上是可行的，但是由于推送服務(wù)自身的復(fù)雜性，想要開發(fā)出穩(wěn)定、高性能的推送服務(wù)并非易事，需要在設(shè)計(jì)階段針對(duì)推送服務(wù)的特點(diǎn)進(jìn)行合理設(shè)計(jì)。

3.1. 最大句柄數(shù)修改

百萬長(zhǎng)連接接入，首先需要優(yōu)化的就是Linux內(nèi)核參數(shù)，其中Linux最大文件句柄數(shù)是最重要的調(diào)優(yōu)參數(shù)之一，默認(rèn)單進(jìn)程打開的最大句柄數(shù)是1024，通過ulimit -a可以查看相關(guān)參數(shù)，示例如下：

[root@lilinfeng ~]# ulimit -a

core file size ? ? ? ? ?(blocks, -c) 0

data seg size ? ? ? ? ? (kbytes, -d) unlimited

scheduling priority ? ? ? ? ? ? (-e) 0

file size ? ? ? ? ? ? ? (blocks, -f) unlimited

pending signals ? ? ? ? ? ? ? ? (-i) 256324

max locked memory ? ? ? (kbytes, -l) 64

max memory size ? ? ? ? (kbytes, -m) unlimited

open files ? ? ? ? ? ? ? ? ? ? ?(-n) 1024

......后續(xù)輸出省略

當(dāng)單個(gè)推送服務(wù)接收到的鏈接超過上限后，就會(huì)報(bào)“too many open files”，所有新的客戶端接入將失敗。

通過vi /etc/security/limits.conf 添加如下配置參數(shù)：修改之后保存，注銷當(dāng)前用戶，重新登錄，通過ulimit -a 查看修改的狀態(tài)是否生效。

* ?soft　　nofile　　1000000

* ?hard　　nofile　　1000000

需要指出的是，盡管我們可以將單個(gè)進(jìn)程打開的最大句柄數(shù)修改的非常大，但是當(dāng)句柄數(shù)達(dá)到一定數(shù)量級(jí)之后，處理效率將出現(xiàn)明顯下降，因此，需要根據(jù)服務(wù)器的硬件配置和處理能力進(jìn)行合理設(shè)置。如果單個(gè)服務(wù)器性能不行也可以通過集群的方式實(shí)現(xiàn)。

3.2. 當(dāng)心CLOSE_WAIT

從事移動(dòng)推送服務(wù)開發(fā)的同學(xué)可能都有體會(huì)，移動(dòng)無線網(wǎng)絡(luò)可靠性非常差，經(jīng)常存在客戶端重置連接，網(wǎng)絡(luò)閃斷等。

在百萬長(zhǎng)連接的推送系統(tǒng)中，服務(wù)端需要能夠正確處理這些網(wǎng)絡(luò)異常，設(shè)計(jì)要點(diǎn)如下：

1，客戶端的重連間隔需要合理設(shè)置，防止連接過于頻繁導(dǎo)致的連接失敗（例如端口還沒有被釋放）；

2，客戶端重復(fù)登陸拒絕機(jī)制；

3，服務(wù)端正確處理I/O異常和解碼異常等，防止句柄泄露。

最后特別需要注意的一點(diǎn)就是close_wait 過多問題，由于網(wǎng)絡(luò)不穩(wěn)定經(jīng)常會(huì)導(dǎo)致客戶端斷連，如果服務(wù)端沒有能夠及時(shí)關(guān)閉socket，就會(huì)導(dǎo)致處于close_wait狀態(tài)的鏈路過多。close_wait狀態(tài)的鏈路并不釋放句柄和內(nèi)存等資源，如果積壓過多可能會(huì)導(dǎo)致系統(tǒng)句柄耗盡，發(fā)生“Too many open files”異常，新的客戶端無法接入，涉及創(chuàng)建或者打開句柄的操作都將失敗。

下面對(duì)close_wait狀態(tài)進(jìn)行下簡(jiǎn)單介紹，被動(dòng)關(guān)閉TCP連接狀態(tài)遷移圖如下所示：

圖3-1 被動(dòng)關(guān)閉TCP連接狀態(tài)遷移圖

close_wait是被動(dòng)關(guān)閉連接是形成的，根據(jù)TCP狀態(tài)機(jī)，服務(wù)器端收到客戶端發(fā)送的FIN，TCP協(xié)議棧會(huì)自動(dòng)發(fā)送ACK，鏈接進(jìn)入close_wait狀態(tài)。但如果服務(wù)器端不執(zhí)行socket的close()操作，狀態(tài)就不能由close_wait遷移到last_ack，則系統(tǒng)中會(huì)存在很多close_wait狀態(tài)的連接。通常來說，一個(gè)close_wait會(huì)維持至少2個(gè)小時(shí)的時(shí)間（系統(tǒng)默認(rèn)超時(shí)時(shí)間的是7200秒，也就是2小時(shí)）。如果服務(wù)端程序因某個(gè)原因?qū)е孪到y(tǒng)造成一堆close_wait消耗資源，那么通常是等不到釋放那一刻，系統(tǒng)就已崩潰。

導(dǎo)致close_wait過多的可能原因如下：

1，程序處理Bug，導(dǎo)致接收到對(duì)方的fin之后沒有及時(shí)關(guān)閉socket，這可能是Netty的Bug，也可能是業(yè)務(wù)層Bug，需要具體問題具體分析；

2，關(guān)閉socket不及時(shí)：例如I/O線程被意外阻塞，或者I/O線程執(zhí)行的用戶自定義Task比例過高，導(dǎo)致I/O操作處理不及時(shí)，鏈路不能被及時(shí)釋放。

下面我們結(jié)合Netty的原理，對(duì)潛在的故障點(diǎn)進(jìn)行分析。

設(shè)計(jì)要點(diǎn)1：不要在Netty的I/O線程上處理業(yè)務(wù)（心跳發(fā)送和檢測(cè)除外）。

Why? 對(duì)于Java進(jìn)程，線程不能無限增長(zhǎng)，這就意味著Netty的Reactor線程數(shù)必須收斂。Netty的默認(rèn)值是CPU核數(shù) * 2，通常情況下，I/O密集型應(yīng)用建議線程數(shù)盡量設(shè)置大些，但這主要是針對(duì)傳統(tǒng)同步I/O而言，對(duì)于非阻塞I/O，線程數(shù)并不建議設(shè)置太大，盡管沒有最優(yōu)值，但是I/O線程數(shù)經(jīng)驗(yàn)值是[CPU核數(shù) + 1，CPU核數(shù)*2 ]之間。

假如單個(gè)服務(wù)器支撐100萬個(gè)長(zhǎng)連接，服務(wù)器內(nèi)核數(shù)為32，則單個(gè)I/O線程處理的鏈接數(shù)L = 100/(32 * 2) = 15625。 假如每5S有一次消息交互（新消息推送、心跳消息和其它管理消息），則平均CAPS = 15625 / 5 = 3125條/秒。這個(gè)數(shù)值相比于Netty的處理性能而言壓力并不大，但是在實(shí)際業(yè)務(wù)處理中，經(jīng)常會(huì)有一些額外的復(fù)雜邏輯處理，例如性能統(tǒng)計(jì)、記錄接口日志等，這些業(yè)務(wù)操作性能開銷也比較大，如果在I/O線程上直接做業(yè)務(wù)邏輯處理，可能會(huì)阻塞I/O線程，影響對(duì)其它鏈路的讀寫操作，這就會(huì)導(dǎo)致被動(dòng)關(guān)閉的鏈路不能及時(shí)關(guān)閉，造成close_wait堆積。

設(shè)計(jì)要點(diǎn)2：在I/O線程上執(zhí)行自定義Task要當(dāng)心。Netty的I/O處理線程N(yùn)ioEventLoop支持兩種自定義Task的執(zhí)行：

1，普通的Runnable: 通過調(diào)用NioEventLoop的execute(Runnable task)方法執(zhí)行；

2，定時(shí)任務(wù)ScheduledFutureTask:通過調(diào)用NioEventLoop的schedule(Runnable command, long delay, TimeUnit unit)系列接口執(zhí)行。

為什么NioEventLoop要支持用戶自定義Runnable和ScheduledFutureTask的執(zhí)行，并不是本文要討論的重點(diǎn)，后續(xù)會(huì)有專題文章進(jìn)行介紹。本文重點(diǎn)對(duì)它們的影響進(jìn)行分析。

在NioEventLoop中執(zhí)行Runnable和ScheduledFutureTask，意味著允許用戶在NioEventLoop中執(zhí)行非I/O操作類的業(yè)務(wù)邏輯，這些業(yè)務(wù)邏輯通常用消息報(bào)文的處理和協(xié)議管理相關(guān)。它們的執(zhí)行會(huì)搶占NioEventLoop I/O讀寫的CPU時(shí)間，如果用戶自定義Task過多，或者單個(gè)Task執(zhí)行周期過長(zhǎng)，會(huì)導(dǎo)致I/O讀寫操作被阻塞，這樣也間接導(dǎo)致close_wait堆積。

所以，如果用戶在代碼中使用到了Runnable和ScheduledFutureTask，請(qǐng)合理設(shè)置ioRatio的比例，通過NioEventLoop的setIoRatio(int ioRatio)方法可以設(shè)置該值，默認(rèn)值為50，即I/O操作和用戶自定義任務(wù)的執(zhí)行時(shí)間比為1：1。

我的建議是當(dāng)服務(wù)端處理海量客戶端長(zhǎng)連接的時(shí)候，不要在NioEventLoop中執(zhí)行自定義Task，或者非心跳類的定時(shí)任務(wù)。

設(shè)計(jì)要點(diǎn)3：IdleStateHandler使用要當(dāng)心。很多用戶會(huì)使用IdleStateHandler做心跳發(fā)送和檢測(cè)，這種用法值得提倡。相比于自己?jiǎn)⒍〞r(shí)任務(wù)發(fā)送心跳，這種方式更高效。但是在實(shí)際開發(fā)中需要注意的是，在心跳的業(yè)務(wù)邏輯處理中，無論是正常還是異常場(chǎng)景，處理時(shí)延要可控，防止時(shí)延不可控導(dǎo)致的NioEventLoop被意外阻塞。例如，心跳超時(shí)或者發(fā)生I/O異常時(shí)，業(yè)務(wù)調(diào)用Email發(fā)送接口告警，由于Email服務(wù)端處理超時(shí)，導(dǎo)致郵件發(fā)送客戶端被阻塞，級(jí)聯(lián)引起IdleStateHandler的AllIdleTimeoutTask任務(wù)被阻塞，最終NioEventLoop多路復(fù)用器上其它的鏈路讀寫被阻塞。

對(duì)于ReadTimeoutHandler和WriteTimeoutHandler，約束同樣存在。

3.3. 合理的心跳周期

百萬級(jí)的推送服務(wù)，意味著會(huì)存在百萬個(gè)長(zhǎng)連接，每個(gè)長(zhǎng)連接都需要靠和App之間的心跳來維持鏈路。合理設(shè)置心跳周期是非常重要的工作，推送服務(wù)的心跳周期設(shè)置需要考慮移動(dòng)無線網(wǎng)絡(luò)的特點(diǎn)。

當(dāng)一臺(tái)智能手機(jī)連上移動(dòng)網(wǎng)絡(luò)時(shí)，其實(shí)并沒有真正連接上Internet，運(yùn)營(yíng)商分配給手機(jī)的IP其實(shí)是運(yùn)營(yíng)商的內(nèi)網(wǎng)IP，手機(jī)終端要連接上Internet還必須通過運(yùn)營(yíng)商的網(wǎng)關(guān)進(jìn)行IP地址的轉(zhuǎn)換，這個(gè)網(wǎng)關(guān)簡(jiǎn)稱為NAT(NetWork Address Translation)，簡(jiǎn)單來說就是手機(jī)終端連接Internet 其實(shí)就是移動(dòng)內(nèi)網(wǎng)IP，端口，外網(wǎng)IP之間相互映射。

GGSN(GateWay GPRS Support Note)模塊就實(shí)現(xiàn)了NAT功能，由于大部分的移動(dòng)無線網(wǎng)絡(luò)運(yùn)營(yíng)商為了減少網(wǎng)關(guān)NAT映射表的負(fù)荷，如果一個(gè)鏈路有一段時(shí)間沒有通信時(shí)就會(huì)刪除其對(duì)應(yīng)表，造成鏈路中斷，正是這種刻意縮短空閑連接的釋放超時(shí)，原本是想節(jié)省信道資源的作用，沒想到讓互聯(lián)網(wǎng)的應(yīng)用不得以遠(yuǎn)高于正常頻率發(fā)送心跳來維護(hù)推送的長(zhǎng)連接。以中移動(dòng)的2.5G網(wǎng)絡(luò)為例，大約5分鐘左右的基帶空閑，連接就會(huì)被釋放。

由于移動(dòng)無線網(wǎng)絡(luò)的特點(diǎn)，推送服務(wù)的心跳周期并不能設(shè)置的太長(zhǎng)，否則長(zhǎng)連接會(huì)被釋放，造成頻繁的客戶端重連，但是也不能設(shè)置太短，否則在當(dāng)前缺乏統(tǒng)一心跳框架的機(jī)制下很容易導(dǎo)致信令風(fēng)暴（例如微信心跳信令風(fēng)暴問題）。具體的心跳周期并沒有統(tǒng)一的標(biāo)準(zhǔn)，180S也許是個(gè)不錯(cuò)的選擇，微信為300S。

在Netty中，可以通過在ChannelPipeline中增加IdleStateHandler的方式實(shí)現(xiàn)心跳檢測(cè)，在構(gòu)造函數(shù)中指定鏈路空閑時(shí)間，然后實(shí)現(xiàn)空閑回調(diào)接口，實(shí)現(xiàn)心跳的發(fā)送和檢測(cè)，代碼如下：

public void initChannel({@link Channel} channel) {

channel.pipeline().addLast('idleStateHandler', new {@link ? IdleStateHandler}(0, 0, 180));

channel.pipeline().addLast('myHandler', new MyHandler());

}

攔截鏈路空閑事件并處理心跳：

public class MyHandler extends {@link ChannelHandlerAdapter} {

? ? {@code @Override}

? ? public void userEventTriggered({@link ChannelHandlerContext} ctx, {@link Object} evt) throws {@link Exception} {

? ? ? ? ?if (evt instanceof {@link IdleStateEvent}} {

? ? ? ? ? ? //心跳處理

? ? ? ? ? ? }

? ? ? ? ? }

? ? ? }

3.4. 合理設(shè)置接收和發(fā)送緩沖區(qū)容量

對(duì)于長(zhǎng)鏈接，每個(gè)鏈路都需要維護(hù)自己的消息接收和發(fā)送緩沖區(qū)，JDK原生的NIO類庫(kù)使用的是java.nio.ByteBuffer,它實(shí)際是一個(gè)長(zhǎng)度固定的Byte數(shù)組，我們都知道數(shù)組無法動(dòng)態(tài)擴(kuò)容，ByteBuffer也有這個(gè)限制，相關(guān)代碼如下：

public abstract class ByteBuffer

? ?extends Buffer

? ?implements Comparable{

? ?final byte[] hb; // Non-null only for heap buffers

? ?final int offset;

? ?boolean isReadOnly;

容量無法動(dòng)態(tài)擴(kuò)展會(huì)給用戶帶來一些麻煩，例如由于無法預(yù)測(cè)每條消息報(bào)文的長(zhǎng)度，可能需要預(yù)分配一個(gè)比較大的ByteBuffer，這通常也沒有問題。但是在海量推送服務(wù)系統(tǒng)中，這會(huì)給服務(wù)端帶來沉重的內(nèi)存負(fù)擔(dān)。假設(shè)單條推送消息最大上限為10K，消息平均大小為5K，為了滿足10K消息的處理，ByteBuffer的容量被設(shè)置為10K，這樣每條鏈路實(shí)際上多消耗了5K內(nèi)存，如果長(zhǎng)鏈接鏈路數(shù)為100萬，每個(gè)鏈路都獨(dú)立持有ByteBuffer接收緩沖區(qū)，則額外損耗的總內(nèi)存 Total(M) = 1000000 * 5K = 4882M。內(nèi)存消耗過大，不僅僅增加了硬件成本，而且大內(nèi)存容易導(dǎo)致長(zhǎng)時(shí)間的Full GC，對(duì)系統(tǒng)穩(wěn)定性會(huì)造成比較大的沖擊。

實(shí)際上，最靈活的處理方式就是能夠動(dòng)態(tài)調(diào)整內(nèi)存，即接收緩沖區(qū)可以根據(jù)以往接收的消息進(jìn)行計(jì)算，動(dòng)態(tài)調(diào)整內(nèi)存，利用CPU資源來?yè)Q內(nèi)存資源，具體的策略如下：

1,ByteBuffer支持容量的擴(kuò)展和收縮，可以按需靈活調(diào)整，以節(jié)約內(nèi)存；

2,接收消息的時(shí)候，可以按照指定的算法對(duì)之前接收的消息大小進(jìn)行分析，并預(yù)測(cè)未來的消息大小，按照預(yù)測(cè)值靈活調(diào)整緩沖區(qū)容量，以做到最小的資源損耗滿足程序正常功能。

幸運(yùn)的是，Netty提供的ByteBuf支持容量動(dòng)態(tài)調(diào)整，對(duì)于接收緩沖區(qū)的內(nèi)存分配器，Netty提供了兩種：

1,FixedRecvByteBufAllocator：固定長(zhǎng)度的接收緩沖區(qū)分配器，由它分配的ByteBuf長(zhǎng)度都是固定大小的，并不會(huì)根據(jù)實(shí)際數(shù)據(jù)報(bào)的大小動(dòng)態(tài)收縮。但是，如果容量不足，支持動(dòng)態(tài)擴(kuò)展。動(dòng)態(tài)擴(kuò)展是Netty ByteBuf的一項(xiàng)基本功能，與ByteBuf分配器的實(shí)現(xiàn)沒有關(guān)系；

2,AdaptiveRecvByteBufAllocator：容量動(dòng)態(tài)調(diào)整的接收緩沖區(qū)分配器，它會(huì)根據(jù)之前Channel接收到的數(shù)據(jù)報(bào)大小進(jìn)行計(jì)算，如果連續(xù)填充滿接收緩沖區(qū)的可寫空間，則動(dòng)態(tài)擴(kuò)展容量。如果連續(xù)2次接收到的數(shù)據(jù)報(bào)都小于指定值，則收縮當(dāng)前的容量，以節(jié)約內(nèi)存。

相對(duì)于FixedRecvByteBufAllocator，使用AdaptiveRecvByteBufAllocator更為合理，可以在創(chuàng)建客戶端或者服務(wù)端的時(shí)候指定RecvByteBufAllocator，代碼如下：

Bootstrap b = new Bootstrap();

?b.group(group)

? ? ?.channel(NioSocketChannel.class)

? ? ?.option(ChannelOption.TCP_NODELAY, true)

? ? ?.option(ChannelOption.RCVBUF_ALLOCATOR, AdaptiveRecvByteBufAllocator.DEFAULT)

如果默認(rèn)沒有設(shè)置，則使用AdaptiveRecvByteBufAllocator。

另外值得注意的是，無論是接收緩沖區(qū)還是發(fā)送緩沖區(qū)，緩沖區(qū)的大小建議設(shè)置為消息的平均大小，不要設(shè)置成最大消息的上限，這會(huì)導(dǎo)致額外的內(nèi)存浪費(fèi)。通過如下方式可以設(shè)置接收緩沖區(qū)的初始大小：

/**

?* Creates a new predictor with the specified parameters.

? ? ? ?*

? ? ? ?* @param minimum

? ? ? ?* ? ? ? ? ? ?the inclusive lower bound of the expected buffer size

? ? ? ?* @param initial

? ? ? ?* ? ? ? ? ? ?the initial buffer size when no feed back was received

* @param maximum

? ? ? ?* ? ? ? ? ? ?the inclusive upper bound of the expected buffer size

? ? ? ?*/

? ? ?public AdaptiveRecvByteBufAllocator(int minimum, int initial, int maximum)

對(duì)于消息發(fā)送，通常需要用戶自己構(gòu)造ByteBuf并編碼，例如通過如下工具類創(chuàng)建消息發(fā)送緩沖區(qū)：

圖3-2 構(gòu)造指定容量的緩沖區(qū)

3.5. 內(nèi)存池

推送服務(wù)器承載了海量的長(zhǎng)鏈接，每個(gè)長(zhǎng)鏈接實(shí)際就是一個(gè)會(huì)話。如果每個(gè)會(huì)話都持有心跳數(shù)據(jù)、接收緩沖區(qū)、指令集等數(shù)據(jù)結(jié)構(gòu)，而且這些實(shí)例隨著消息的處理朝生夕滅，這就會(huì)給服務(wù)器帶來沉重的GC壓力，同時(shí)消耗大量的內(nèi)存。

最有效的解決策略就是使用內(nèi)存池，每個(gè)NioEventLoop線程處理N個(gè)鏈路，在線程內(nèi)部，鏈路的處理時(shí)串行的。假如A鏈路首先被處理，它會(huì)創(chuàng)建接收緩沖區(qū)等對(duì)象，待解碼完成之后，構(gòu)造的POJO對(duì)象被封裝成Task后投遞到后臺(tái)的線程池中執(zhí)行，然后接收緩沖區(qū)會(huì)被釋放，每條消息的接收和處理都會(huì)重復(fù)接收緩沖區(qū)的創(chuàng)建和釋放。如果使用內(nèi)存池，則當(dāng)A鏈路接收到新的數(shù)據(jù)報(bào)之后，從NioEventLoop的內(nèi)存池中申請(qǐng)空閑的ByteBuf，解碼完成之后，調(diào)用release將ByteBuf釋放到內(nèi)存池中，供后續(xù)B鏈路繼續(xù)使用。

使用內(nèi)存池優(yōu)化之后，單個(gè)NioEventLoop的ByteBuf申請(qǐng)和GC次數(shù)從原來的N = 1000000/64 = 15625 次減少為最少0次（假設(shè)每次申請(qǐng)都有可用的內(nèi)存）。

下面我們以推特使用Netty4的PooledByteBufAllocator進(jìn)行GC優(yōu)化作為案例，對(duì)內(nèi)存池的效果進(jìn)行評(píng)估，結(jié)果如下：

垃圾生成速度是原來的1/5，而垃圾清理速度快了5倍。使用新的內(nèi)存池機(jī)制，幾乎可以把網(wǎng)絡(luò)帶寬壓滿。

Netty4之前的版本問題如下：每當(dāng)收到新信息或者用戶發(fā)送信息到遠(yuǎn)程端，Netty 3均會(huì)創(chuàng)建一個(gè)新的堆緩沖區(qū)。這意味著，對(duì)應(yīng)每一個(gè)新的緩沖區(qū)，都會(huì)有一個(gè)new byte[capacity]。這些緩沖區(qū)會(huì)導(dǎo)致GC壓力，并消耗內(nèi)存帶寬。為了安全起見，新的字節(jié)數(shù)組分配時(shí)會(huì)用零填充，這會(huì)消耗內(nèi)存帶寬。然而，用零填充的數(shù)組很可能會(huì)再次用實(shí)際的數(shù)據(jù)填充，這又會(huì)消耗同樣的內(nèi)存帶寬。如果Java虛擬機(jī)（JVM）提供了創(chuàng)建新字節(jié)數(shù)組而又無需用零填充的方式，那么我們本來就可以將內(nèi)存帶寬消耗減少50%，但是目前沒有那樣一種方式。

在Netty 4中實(shí)現(xiàn)了一個(gè)新的ByteBuf內(nèi)存池，它是一個(gè)純Java版本的 jemalloc （Facebook也在用）。現(xiàn)在，Netty不會(huì)再因?yàn)橛昧闾畛渚彌_區(qū)而浪費(fèi)內(nèi)存帶寬了。不過，由于它不依賴于GC，開發(fā)人員需要小心內(nèi)存泄漏。如果忘記在處理程序中釋放緩沖區(qū)，那么內(nèi)存使用率會(huì)無限地增長(zhǎng)。

Netty默認(rèn)不使用內(nèi)存池，需要在創(chuàng)建客戶端或者服務(wù)端的時(shí)候進(jìn)行指定,使用內(nèi)存池之后，內(nèi)存的申請(qǐng)和釋放必須成對(duì)出現(xiàn)，即retain()和release()要成對(duì)出現(xiàn)，否則會(huì)導(dǎo)致內(nèi)存泄露。

值得注意的是，如果使用內(nèi)存池，完成ByteBuf的解碼工作之后必須顯式的調(diào)用ReferenceCountUtil.release(msg)對(duì)接收緩沖區(qū)ByteBuf進(jìn)行內(nèi)存釋放，否則它會(huì)被認(rèn)為仍然在使用中，這樣會(huì)導(dǎo)致內(nèi)存泄露。

3.6. 當(dāng)心“日志隱形殺手”

通常情況下，大家都知道不能在Netty的I/O線程上做執(zhí)行時(shí)間不可控的操作，例如訪問數(shù)據(jù)庫(kù)、發(fā)送Email等。但是有個(gè)常用但是非常危險(xiǎn)的操作卻容易被忽略，那便是記錄日志。

通常，在生產(chǎn)環(huán)境中，需要實(shí)時(shí)打印接口日志，其它日志處于ERROR級(jí)別，當(dāng)推送服務(wù)發(fā)生I/O異常之后，會(huì)記錄異常日志。如果當(dāng)前磁盤的WIO比較高，可能會(huì)發(fā)生寫日志文件操作被同步阻塞，阻塞時(shí)間無法預(yù)測(cè)。這就會(huì)導(dǎo)致Netty的NioEventLoop線程被阻塞，Socket鏈路無法被及時(shí)關(guān)閉、其它的鏈路也無法進(jìn)行讀寫操作等。

以最常用的log4j為例，盡管它支持異步寫日志（AsyncAppender），但是當(dāng)日志隊(duì)列滿之后，它會(huì)同步阻塞業(yè)務(wù)線程，直到日志隊(duì)列有空閑位置可用，相關(guān)代碼如下：

synchronized (this.buffer) {

? ? ?while (true) {

? ? ?int previousSize = this.buffer.size();

? ? ?if (previousSize < this.bufferSize) {

? ? ?this.buffer.add(event);

? ? ?if (previousSize != 0) break;

? ? ? ?this.buffer.notifyAll(); break;

? ? ?}

? ? ?boolean discard = true;

? ? ?if ((this.blocking) && (!Thread.interrupted()) && (Thread.currentThread() != this.dispatcher)) //判斷是業(yè)務(wù)線程

? ? ?{

? ? ?try

? ? ?{

? ? ? ? ? this.buffer.wait();//阻塞業(yè)務(wù)線程

? ? ? ? ? discard = false;

? ? ?}

? ? ?catch (InterruptedException e)

? ? {

? ? ? ? ? Thread.currentThread().interrupt();

? ? ? ?}

? ? ?}

類似這類BUG具有極強(qiáng)的隱蔽性，往往WIO高的時(shí)間持續(xù)非常短，或者是偶現(xiàn)的，在測(cè)試環(huán)境中很難模擬此類故障，問題定位難度非常大。這就要求讀者在平時(shí)寫代碼的時(shí)候一定要當(dāng)心，注意那些隱性地雷。

3.7. TCP參數(shù)優(yōu)化

常用的TCP參數(shù)，例如TCP層面的接收和發(fā)送緩沖區(qū)大小設(shè)置，在Netty中分別對(duì)應(yīng)ChannelOption的SO_SNDBUF和SO_RCVBUF，需要根據(jù)推送消息的大小，合理設(shè)置，對(duì)于海量長(zhǎng)連接，通常32K是個(gè)不錯(cuò)的選擇。

另外一個(gè)比較常用的優(yōu)化手段就是軟中斷，如圖所示：如果所有的軟中斷都運(yùn)行在CPU0相應(yīng)網(wǎng)卡的硬件中斷上，那么始終都是cpu0在處理軟中斷，而此時(shí)其它CPU資源就被浪費(fèi)了，因?yàn)闊o法并行的執(zhí)行多個(gè)軟中斷。

圖3-3 中斷信息

大于等于2.6.35版本的Linux kernel內(nèi)核，開啟RPS，網(wǎng)絡(luò)通信性能提升20%之上。RPS的基本原理：根據(jù)數(shù)據(jù)包的源地址，目的地址以及目的和源端口，計(jì)算出一個(gè)hash值，然后根據(jù)這個(gè)hash值來選擇軟中斷運(yùn)行的cpu。從上層來看，也就是說將每個(gè)連接和cpu綁定，并通過這個(gè)hash值，來均衡軟中斷運(yùn)行在多個(gè)cpu上，從而提升通信性能。

3.8. JVM參數(shù)

最重要的參數(shù)調(diào)整有兩個(gè)：

-Xmx:JVM最大內(nèi)存需要根據(jù)內(nèi)存模型進(jìn)行計(jì)算并得出相對(duì)合理的值；

GC相關(guān)的參數(shù): 例如新生代和老生代、永久代的比例，GC的策略，新生代各區(qū)的比例等，需要根據(jù)具體的場(chǎng)景進(jìn)行設(shè)置和測(cè)試，并不斷的優(yōu)化，盡量將Full GC的頻率降到最低。