1. 背景

1.1 驚人的性能數(shù)據(jù)

最近一個圈內(nèi)朋友通過私信告訴我，通過使用Netty4 + Thrift壓縮二進制編解碼技術(shù),，他們實現(xiàn)了10W TPS（1K的復(fù)雜POJO對象）的跨節(jié)點遠程服務(wù)調(diào)用,。相比于傳統(tǒng)基于Java序列化+BIO（同步阻塞IO）的通信框架，性能提升了8倍多,。

事實上,，我對這個數(shù)據(jù)并不感到驚訝，根據(jù)我5年多的NIO編程經(jīng)驗,，通過選擇合適的NIO框架,，加上高性能的壓縮二進制編解碼技術(shù),，精心的設(shè)計Reactor線程模型，達到上述性能指標(biāo)是完全有可能的,。

下面我們就一起來看下Netty是如何支持10W TPS的跨節(jié)點遠程服務(wù)調(diào)用的,，在正式開始講解之前，我們先簡單介紹下Netty,。

1.2 Netty基礎(chǔ)入門

Netty是一個高性能,、異步事件驅(qū)動的NIO框架，它提供了對TCP,、UDP和文件傳輸?shù)闹С?，作為一個異步NIO框架，Netty的所有IO操作都是異步非阻塞的,，通過Future-Listener機制,，用戶可以方便的主動獲取或者通過通知機制獲得IO操作結(jié)果。

作為當(dāng)前最流行的NIO框架,，Netty在互聯(lián)網(wǎng)領(lǐng)域,、大數(shù)據(jù)分布式計算領(lǐng)域、游戲行業(yè),、通信行業(yè)等獲得了廣泛的應(yīng)用,，一些業(yè)界著名的開源組件也基于Netty的NIO框架構(gòu)建。

2. Netty高性能之道

2.1. RPC調(diào)用的性能模型分析

2.1.1.傳統(tǒng)RPC調(diào)用性能差的三宗罪

網(wǎng)絡(luò)傳輸方式問題：傳統(tǒng)的RPC框架或者基于RMI等方式的遠程服務(wù)（過程）調(diào)用采用了同步阻塞IO,，當(dāng)客戶端的并發(fā)壓力或者網(wǎng)絡(luò)時延增大之后,，同步阻塞IO會由于頻繁的wait導(dǎo)致IO線程經(jīng)常性的阻塞，由于線程無法高效的工作,，IO處理能力自然下降,。

下面，我們通過BIO通信模型圖看下BIO通信的弊端：

BIO通信模型圖

采用BIO通信模型的服務(wù)端,，通常由一個獨立的Acceptor線程負責(zé)監(jiān)聽客戶端的連接,，接收到客戶端連接之后為客戶端連接創(chuàng)建一個新的線程處理請求消息，處理完成之后,，返回應(yīng)答消息給客戶端,，線程銷毀，這就是典型的一請求一應(yīng)答模型,。該架構(gòu)最大的問題就是不具備彈性伸縮能力,，當(dāng)并發(fā)訪問量增加后，服務(wù)端的線程個數(shù)和并發(fā)訪問數(shù)成線性正比,，由于線程是JAVA虛擬機非常寶貴的系統(tǒng)資源,，當(dāng)線程數(shù)膨脹之后，系統(tǒng)的性能急劇下降,，隨著并發(fā)量的繼續(xù)增加,，可能會發(fā)生句柄溢出,、線程堆棧溢出等問題，并導(dǎo)致服務(wù)器最終宕機,。

序列化方式問題：Java序列化存在如下幾個典型問題：

1) Java序列化機制是Java內(nèi)部的一種對象編解碼技術(shù),，無法跨語言使用；例如對于異構(gòu)系統(tǒng)之間的對接,，Java序列化后的碼流需要能夠通過其它語言反序列化成原始對象（副本）,，目前很難支持；

2) 相比于其它開源的序列化框架,，Java序列化后的碼流太大,，無論是網(wǎng)絡(luò)傳輸還是持久化到磁盤，都會導(dǎo)致額外的資源占用,；

3) 序列化性能差（CPU資源占用高）,。

線程模型問題：由于采用同步阻塞IO，這會導(dǎo)致每個TCP連接都占用1個線程,，由于線程資源是JVM虛擬機非常寶貴的資源,，當(dāng)IO讀寫阻塞導(dǎo)致線程無法及時釋放時，會導(dǎo)致系統(tǒng)性能急劇下降,，嚴重的甚至?xí)?dǎo)致虛擬機無法創(chuàng)建新的線程,。

2.1.2. 高性能的三個主題

1) 傳輸：用什么樣的通道將數(shù)據(jù)發(fā)送給對方，BIO,、NIO或者AIO,，IO模型在很大程度上決定了框架的性能,。

2) 協(xié)議：采用什么樣的通信協(xié)議,，HTTP或者內(nèi)部私有協(xié)議。協(xié)議的選擇不同,，性能模型也不同,。相比于公有協(xié)議，內(nèi)部私有協(xié)議的性能通?？梢员辉O(shè)計的更優(yōu),。

3) 線程：數(shù)據(jù)報如何讀取,？讀取之后的編解碼在哪個線程進行,，編解碼后的消息如何派發(fā)，Reactor線程模型的不同,，對性能的影響也非常大,。

RPC調(diào)用性能三要素

2.2 Netty高性能之道

2.2.1. 異步非阻塞通信

在IO編程過程中，當(dāng)需要同時處理多個客戶端接入請求時,，可以利用多線程或者IO多路復(fù)用技術(shù)進行處理,。IO多路復(fù)用技術(shù)通過把多個IO的阻塞復(fù)用到同一個select的阻塞上,，從而使得系統(tǒng)在單線程的情況下可以同時處理多個客戶端請求。與傳統(tǒng)的多線程/多進程模型比,，I/O多路復(fù)用的最大優(yōu)勢是系統(tǒng)開銷小,，系統(tǒng)不需要創(chuàng)建新的額外進程或者線程，也不需要維護這些進程和線程的運行,，降低了系統(tǒng)的維護工作量,，節(jié)省了系統(tǒng)資源。

JDK1.4提供了對非阻塞IO（NIO）的支持,，JDK1.5_update10版本使用epoll替代了傳統(tǒng)的select/poll,，極大的提升了NIO通信的性能。

JDK NIO通信模型如下所示：

NIO的多路復(fù)用模型圖

與Socket類和ServerSocket類相對應(yīng),，NIO也提供了SocketChannel和ServerSocketChannel兩種不同的套接字通道實現(xiàn),。這兩種新增的通道都支持阻塞和非阻塞兩種模式。阻塞模式使用非常簡單,，但是性能和可靠性都不好,，非阻塞模式正好相反。開發(fā)人員一般可以根據(jù)自己的需要來選擇合適的模式,，一般來說,，低負載、低并發(fā)的應(yīng)用程序可以選擇同步阻塞IO以降低編程復(fù)雜度,。但是對于高負載,、高并發(fā)的網(wǎng)絡(luò)應(yīng)用，需要使用NIO的非阻塞模式進行開發(fā),。

Netty架構(gòu)按照Reactor模式設(shè)計和實現(xiàn),，它的服務(wù)端通信序列圖如下：

NIO服務(wù)端通信序列圖

客戶端通信序列圖如下：

NIO客戶端通信序列圖

Netty的IO線程NioEventLoop由于聚合了多路復(fù)用器Selector，可以同時并發(fā)處理成百上千個客戶端Channel,，由于讀寫操作都是非阻塞的,，這就可以充分提升IO線程的運行效率，避免由于頻繁IO阻塞導(dǎo)致的線程掛起,。另外,，由于Netty采用了異步通信模式，一個IO線程可以并發(fā)處理N個客戶端連接和讀寫操作,，這從根本上解決了傳統(tǒng)同步阻塞IO一連接一線程模型,，架構(gòu)的性能、彈性伸縮能力和可靠性都得到了極大的提升,。

2.2.2. 零拷貝

很多用戶都聽說過Netty具有“零拷貝”功能,，但是具體體現(xiàn)在哪里又說不清楚，本小節(jié)就詳細對Netty的“零拷貝”功能進行講解,。

Netty的“零拷貝”主要體現(xiàn)在如下三個方面：

1) Netty的接收和發(fā)送ByteBuffer采用DIRECT BUFFERS,，使用堆外直接內(nèi)存進行Socket讀寫,，不需要進行字節(jié)緩沖區(qū)的二次拷貝。如果使用傳統(tǒng)的堆內(nèi)存（HEAP BUFFERS）進行Socket讀寫,，JVM會將堆內(nèi)存Buffer拷貝一份到直接內(nèi)存中,，然后才寫入Socket中。相比于堆外直接內(nèi)存,，消息在發(fā)送過程中多了一次緩沖區(qū)的內(nèi)存拷貝,。

2) Netty提供了組合Buffer對象，可以聚合多個ByteBuffer對象,，用戶可以像操作一個Buffer那樣方便的對組合Buffer進行操作,，避免了傳統(tǒng)通過內(nèi)存拷貝的方式將幾個小Buffer合并成一個大的Buffer。

3) Netty的文件傳輸采用了transferTo方法,，它可以直接將文件緩沖區(qū)的數(shù)據(jù)發(fā)送到目標(biāo)Channel,，避免了傳統(tǒng)通過循環(huán)write方式導(dǎo)致的內(nèi)存拷貝問題。

下面,，我們對上述三種“零拷貝”進行說明,，先看Netty 接收Buffer的創(chuàng)建：

異步消息讀取“零拷貝”

每循環(huán)讀取一次消息，就通過ByteBufAllocator的ioBuffer方法獲取ByteBuf對象,，下面繼續(xù)看它的接口定義：

ByteBufAllocator 通過ioBuffer分配堆外內(nèi)存

當(dāng)進行Socket IO讀寫的時候,，為了避免從堆內(nèi)存拷貝一份副本到直接內(nèi)存，Netty的ByteBuf分配器直接創(chuàng)建非堆內(nèi)存避免緩沖區(qū)的二次拷貝,，通過“零拷貝”來提升讀寫性能,。

下面我們繼續(xù)看第二種“零拷貝”的實現(xiàn)CompositeByteBuf，它對外將多個ByteBuf封裝成一個ByteBuf,，對外提供統(tǒng)一封裝后的ByteBuf接口,，它的類定義如下：

CompositeByteBuf類繼承關(guān)系

通過繼承關(guān)系我們可以看出CompositeByteBuf實際就是個ByteBuf的包裝器，它將多個ByteBuf組合成一個集合,，然后對外提供統(tǒng)一的ByteBuf接口,，相關(guān)定義如下：

CompositeByteBuf類定義

添加ByteBuf，不需要做內(nèi)存拷貝,，相關(guān)代碼如下：

新增ByteBuf的“零拷貝”

最后，我們看下文件傳輸?shù)摹傲憧截悺保?/p>

文件傳輸“零拷貝”

Netty文件傳輸DefaultFileRegion通過transferTo方法將文件發(fā)送到目標(biāo)Channel中,，下面重點看FileChannel的transferTo方法,，它的API DOC說明如下：

文件傳輸 “零拷貝”

對于很多操作系統(tǒng)它直接將文件緩沖區(qū)的內(nèi)容發(fā)送到目標(biāo)Channel中，而不需要通過拷貝的方式,，這是一種更加高效的傳輸方式,，它實現(xiàn)了文件傳輸?shù)摹傲憧截悺薄?/p>

2.2.3. 內(nèi)存池

隨著JVM虛擬機和JIT即時編譯技術(shù)的發(fā)展，對象的分配和回收是個非常輕量級的工作,。但是對于緩沖區(qū)Buffer,，情況卻稍有不同,，特別是對于堆外直接內(nèi)存的分配和回收，是一件耗時的操作,。為了盡量重用緩沖區(qū),，Netty提供了基于內(nèi)存池的緩沖區(qū)重用機制。下面我們一起看下Netty ByteBuf的實現(xiàn)：

內(nèi)存池ByteBuf

Netty提供了多種內(nèi)存管理策略,，通過在啟動輔助類中配置相關(guān)參數(shù),，可以實現(xiàn)差異化的定制。

下面通過性能測試,，我們看下基于內(nèi)存池循環(huán)利用的ByteBuf和普通ByteBuf的性能差異,。

用例一，使用內(nèi)存池分配器創(chuàng)建直接內(nèi)存緩沖區(qū)：

基于內(nèi)存池的非堆內(nèi)存緩沖區(qū)測試用例

用例二,，使用非堆內(nèi)存分配器創(chuàng)建的直接內(nèi)存緩沖區(qū)：

基于非內(nèi)存池創(chuàng)建的非堆內(nèi)存緩沖區(qū)測試用例

各執(zhí)行300萬次,，性能對比結(jié)果如下所示：

內(nèi)存池和非內(nèi)存池緩沖區(qū)寫入性能對比

性能測試表明，采用內(nèi)存池的ByteBuf相比于朝生夕滅的ByteBuf,，性能高23倍左右（性能數(shù)據(jù)與使用場景強相關(guān)）,。

下面我們一起簡單分析下Netty內(nèi)存池的內(nèi)存分配：

AbstractByteBufAllocator的緩沖區(qū)分配

繼續(xù)看newDirectBuffer方法，我們發(fā)現(xiàn)它是一個抽象方法,，由AbstractByteBufAllocator的子類負責(zé)具體實現(xiàn),，代碼如下：

newDirectBuffer的不同實現(xiàn)

代碼跳轉(zhuǎn)到PooledByteBufAllocator的newDirectBuffer方法，從Cache中獲取內(nèi)存區(qū)域PoolArena,，調(diào)用它的allocate方法進行內(nèi)存分配：

PooledByteBufAllocator的內(nèi)存分配

PoolArena的allocate方法如下：

PoolArena的緩沖區(qū)分配

我們重點分析newByteBuf的實現(xiàn),，它同樣是個抽象方法，由子類DirectArena和HeapArena來實現(xiàn)不同類型的緩沖區(qū)分配,，由于測試用例使用的是堆外內(nèi)存,，

PoolArena的newByteBuf抽象方法

因此重點分析DirectArena的實現(xiàn)：如果沒有開啟使用sun的unsafe，則

DirectArena的newByteBuf方法實現(xiàn)

執(zhí)行PooledDirectByteBuf的newInstance方法,，代碼如下：

PooledDirectByteBuf的newInstance方法實現(xiàn)

通過RECYCLER的get方法循環(huán)使用ByteBuf對象,，如果是非內(nèi)存池實現(xiàn)，則直接創(chuàng)建一個新的ByteBuf對象,。從緩沖池中獲取ByteBuf之后,，調(diào)用AbstractReferenceCountedByteBuf的setRefCnt方法設(shè)置引用計數(shù)器，用于對象的引用計數(shù)和內(nèi)存回收（類似JVM垃圾回收機制）,。

常用的Reactor線程模型有三種,，分別如下：

1) Reactor單線程模型；

2) Reactor多線程模型,；

3) 主從Reactor多線程模型

Reactor單線程模型,，指的是所有的IO操作都在同一個NIO線程上面完成，NIO線程的職責(zé)如下：

1) 作為NIO服務(wù)端，接收客戶端的TCP連接,；

2) 作為NIO客戶端,，向服務(wù)端發(fā)起TCP連接；

3) 讀取通信對端的請求或者應(yīng)答消息,；

4) 向通信對端發(fā)送消息請求或者應(yīng)答消息,。

Reactor單線程模型示意圖如下所示：

Reactor單線程模型

由于Reactor模式使用的是異步非阻塞IO，所有的IO操作都不會導(dǎo)致阻塞,，理論上一個線程可以獨立處理所有IO相關(guān)的操作,。從架構(gòu)層面看，一個NIO線程確實可以完成其承擔(dān)的職責(zé),。例如,，通過Acceptor接收客戶端的TCP連接請求消息，鏈路建立成功之后,，通過Dispatch將對應(yīng)的ByteBuffer派發(fā)到指定的Handler上進行消息解碼,。用戶Handler可以通過NIO線程將消息發(fā)送給客戶端。

對于一些小容量應(yīng)用場景,，可以使用單線程模型,。但是對于高負載、大并發(fā)的應(yīng)用卻不合適,，主要原因如下：

1) 一個NIO線程同時處理成百上千的鏈路,，性能上無法支撐，即便NIO線程的CPU負荷達到100%,，也無法滿足海量消息的編碼,、解碼、讀取和發(fā)送,；

2) 當(dāng)NIO線程負載過重之后,，處理速度將變慢，這會導(dǎo)致大量客戶端連接超時,，超時之后往往會進行重發(fā),，這更加重了NIO線程的負載，最終會導(dǎo)致大量消息積壓和處理超時,，NIO線程會成為系統(tǒng)的性能瓶頸,；

3) 可靠性問題：一旦NIO線程意外跑飛，或者進入死循環(huán),，會導(dǎo)致整個系統(tǒng)通信模塊不可用,，不能接收和處理外部消息，造成節(jié)點故障,。

為了解決這些問題，演進出了Reactor多線程模型，下面我們一起學(xué)習(xí)下Reactor多線程模型,。

Rector多線程模型與單線程模型最大的區(qū)別就是有一組NIO線程處理IO操作,，它的原理圖如下：

Reactor多線程模型

Reactor多線程模型的特點：

1) 有專門一個NIO線程-Acceptor線程用于監(jiān)聽服務(wù)端，接收客戶端的TCP連接請求,；

2) 網(wǎng)絡(luò)IO操作-讀,、寫等由一個NIO線程池負責(zé)，線程池可以采用標(biāo)準(zhǔn)的JDK線程池實現(xiàn),，它包含一個任務(wù)隊列和N個可用的線程,，由這些NIO線程負責(zé)消息的讀取、解碼,、編碼和發(fā)送,；

3) 1個NIO線程可以同時處理N條鏈路，但是1個鏈路只對應(yīng)1個NIO線程,，防止發(fā)生并發(fā)操作問題,。

在絕大多數(shù)場景下，Reactor多線程模型都可以滿足性能需求,；但是,，在極特殊應(yīng)用場景中，一個NIO線程負責(zé)監(jiān)聽和處理所有的客戶端連接可能會存在性能問題,。例如百萬客戶端并發(fā)連接,，或者服務(wù)端需要對客戶端的握手消息進行安全認證，認證本身非常損耗性能,。在這類場景下,，單獨一個Acceptor線程可能會存在性能不足問題，為了解決性能問題,，產(chǎn)生了第三種Reactor線程模型-主從Reactor多線程模型,。

主從Reactor線程模型的特點是：服務(wù)端用于接收客戶端連接的不再是個1個單獨的NIO線程，而是一個獨立的NIO線程池,。Acceptor接收到客戶端TCP連接請求處理完成后（可能包含接入認證等）,，將新創(chuàng)建的SocketChannel注冊到IO線程池（sub reactor線程池）的某個IO線程上，由它負責(zé)SocketChannel的讀寫和編解碼工作,。Acceptor線程池僅僅只用于客戶端的登陸,、握手和安全認證，一旦鏈路建立成功,，就將鏈路注冊到后端subReactor線程池的IO線程上,，由IO線程負責(zé)后續(xù)的IO操作。

它的線程模型如下圖所示：

Reactor主從多線程模型

利用主從NIO線程模型,，可以解決1個服務(wù)端監(jiān)聽線程無法有效處理所有客戶端連接的性能不足問題,。因此，在Netty的官方demo中，推薦使用該線程模型,。

事實上,，Netty的線程模型并非固定不變，通過在啟動輔助類中創(chuàng)建不同的EventLoopGroup實例并通過適當(dāng)?shù)膮?shù)配置,，就可以支持上述三種Reactor線程模型,。正是因為Netty 對Reactor線程模型的支持提供了靈活的定制能力，所以可以滿足不同業(yè)務(wù)場景的性能訴求,。

2.2.5. 無鎖化的串行設(shè)計理念

在大多數(shù)場景下,，并行多線程處理可以提升系統(tǒng)的并發(fā)性能。但是,，如果對于共享資源的并發(fā)訪問處理不當(dāng),，會帶來嚴重的鎖競爭，這最終會導(dǎo)致性能的下降,。為了盡可能的避免鎖競爭帶來的性能損耗,，可以通過串行化設(shè)計，即消息的處理盡可能在同一個線程內(nèi)完成,，期間不進行線程切換,，這樣就避免了多線程競爭和同步鎖。

為了盡可能提升性能,，Netty采用了串行無鎖化設(shè)計,，在IO線程內(nèi)部進行串行操作，避免多線程競爭導(dǎo)致的性能下降,。表面上看,，串行化設(shè)計似乎CPU利用率不高，并發(fā)程度不夠,。但是,，通過調(diào)整NIO線程池的線程參數(shù)，可以同時啟動多個串行化的線程并行運行,，這種局部無鎖化的串行線程設(shè)計相比一個隊列-多個工作線程模型性能更優(yōu),。

Netty的串行化設(shè)計工作原理圖如下：

Netty串行化工作原理圖

Netty的NioEventLoop讀取到消息之后，直接調(diào)用ChannelPipeline的fireChannelRead(Object msg),，只要用戶不主動切換線程,，一直會由NioEventLoop調(diào)用到用戶的Handler，期間不進行線程切換,，這種串行化處理方式避免了多線程操作導(dǎo)致的鎖的競爭,，從性能角度看是最優(yōu)的。

2.2.6. 高效的并發(fā)編程

Netty的高效并發(fā)編程主要體現(xiàn)在如下幾點：

1) volatile的大量,、正確使用;

2) CAS和原子類的廣泛使用,；

3) 線程安全容器的使用,；

4) 通過讀寫鎖提升并發(fā)性能。

如果大家想了解Netty高效并發(fā)編程的細節(jié),，可以閱讀之前我在微博分享的《多線程并發(fā)編程在 Netty 中的應(yīng)用分析》,，在這篇文章中對Netty的多線程技巧和應(yīng)用進行了詳細的介紹和分析,。

2.2.7. 高性能的序列化框架

影響序列化性能的關(guān)鍵因素總結(jié)如下：

1) 序列化后的碼流大?。ňW(wǎng)絡(luò)帶寬的占用）；

2) 序列化&反序列化的性能（CPU資源占用）,；

3) 是否支持跨語言（異構(gòu)系統(tǒng)的對接和開發(fā)語言切換）,。

Netty默認提供了對Google Protobuf的支持，通過擴展Netty的編解碼接口,，用戶可以實現(xiàn)其它的高性能序列化框架,，例如Thrift的壓縮二進制編解碼框架。

下面我們一起看下不同序列化&反序列化框架序列化后的字節(jié)數(shù)組對比：

各序列化框架序列化碼流大小對比

從上圖可以看出,，Protobuf序列化后的碼流只有Java序列化的1/4左右,。正是由于Java原生序列化性能表現(xiàn)太差，才催生出了各種高性能的開源序列化技術(shù)和框架（性能差只是其中的一個原因,，還有跨語言,、IDL定義等其它因素）。

2.2.8. 靈活的TCP參數(shù)配置能力

合理設(shè)置TCP參數(shù)在某些場景下對于性能的提升可以起到顯著的效果,，例如SO_RCVBUF和SO_SNDBUF,。如果設(shè)置不當(dāng)，對性能的影響是非常大的,。下面我們總結(jié)下對性能影響比較大的幾個配置項：

1) SO_RCVBUF和SO_SNDBUF：通常建議值為128K或者256K,；

2) SO_TCPNODELAY：NAGLE算法通過將緩沖區(qū)內(nèi)的小封包自動相連，組成較大的封包,，阻止大量小封包的發(fā)送阻塞網(wǎng)絡(luò),，從而提高網(wǎng)絡(luò)應(yīng)用效率。但是對于時延敏感的應(yīng)用場景需要關(guān)閉該優(yōu)化算法,；

3) 軟中斷：如果Linux內(nèi)核版本支持RPS（2.6.35以上版本）,，開啟RPS后可以實現(xiàn)軟中斷，提升網(wǎng)絡(luò)吞吐量,。RPS根據(jù)數(shù)據(jù)包的源地址,，目的地址以及目的和源端口，計算出一個hash值,，然后根據(jù)這個hash值來選擇軟中斷運行的cpu,，從上層來看，也就是說將每個連接和cpu綁定,，并通過這個hash值,，來均衡軟中斷在多個cpu上,，提升網(wǎng)絡(luò)并行處理性能。

Netty在啟動輔助類中可以靈活的配置TCP參數(shù),，滿足不同的用戶場景,。相關(guān)配置接口定義如下：

Netty的TCP參數(shù)配置定義

2.3 總結(jié)

通過對Netty的架構(gòu)和性能模型進行分析，我們發(fā)現(xiàn)Netty架構(gòu)的高性能是被精心設(shè)計和實現(xiàn)的,，得益于高質(zhì)量的架構(gòu)和代碼,，Netty支持10W TPS的跨節(jié)點服務(wù)調(diào)用并不是件十分困難的事情。

3. 作者簡介

李林鋒,，2007年畢業(yè)于東北大學(xué),，2008年進入華為公司從事高性能通信軟件的設(shè)計和開發(fā)工作，有6年NIO設(shè)計和開發(fā)經(jīng)驗,，精通Netty,、Mina等NIO框架。Netty中國社區(qū)創(chuàng)始人,，《Netty權(quán)威指南》作者,。