學(xué)習(xí)筆記面試寶典

1、基礎(chǔ)篇1、TCP、UDP的區(qū)別？TCP與UDP區(qū)別總結(jié)：1. TCP面向連接（如打 要先撥號(hào)建立連接）;UDP是無(wú)連接的，即 數(shù)據(jù)之前不需要建立連接。2. TCP提供可靠的服務(wù)。也就是說(shuō)，通過(guò)TCP連接傳送的數(shù)據(jù)，無(wú)差錯(cuò)，不丟失，不重復(fù)，且按序到 達(dá);UDP盡最大努力交付，即不保證可靠交付3. TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無(wú)結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的 UDP沒(méi)有擁塞 ，因此網(wǎng)絡(luò)出現(xiàn)擁塞 使源主機(jī)的 速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如IP ，實(shí)時(shí)視頻會(huì)議等）4. 每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信5. TCP首部開(kāi)銷(xiāo)20字節(jié);

2、UDP的首部開(kāi)銷(xiāo)小，只有8個(gè)字節(jié)6. TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道2、TCP協(xié)議如何保證可靠傳輸？校驗(yàn)和，確認(rèn) 和序列號(hào)序列號(hào)：TCP傳輸時(shí)將每個(gè)字節(jié)的數(shù)據(jù)都進(jìn)行了編號(hào)，這就是序列號(hào)。確認(rèn) ：TCP傳輸?shù)倪^(guò)程中，每次接收方收到數(shù)據(jù)后，都會(huì)對(duì)傳輸方進(jìn)行確認(rèn) 。也就是 ACK報(bào)文。這個(gè)ACK報(bào)文當(dāng)中帶有對(duì)應(yīng)的確認(rèn)序列號(hào)，告訴 方，接收到了哪些數(shù)據(jù)，下一次的數(shù)據(jù)從哪里發(fā)。序列號(hào)的作用不僅僅是 的作用，有了序列號(hào)能夠?qū)⒔邮盏降臄?shù)據(jù)根據(jù)序列號(hào)排序，并且去掉重復(fù)序列號(hào)的數(shù)據(jù)。這也是TCP傳輸可靠性的保證之一。超時(shí)重傳：當(dāng)TCP發(fā)出一個(gè) ，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到

3、這個(gè)報(bào)文段。如果不 收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段。流量 ：TCP連接的每一方都有固定大小的緩沖空間，TCP的接收端只 端 接收端緩沖區(qū)能接納的數(shù)據(jù)。當(dāng)接收方來(lái)不及處理 方的數(shù)據(jù)，能提示 方降低 的速率，防止包丟失。TCP使用的流量 協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。接收方有即時(shí)窗口（滑動(dòng)窗口），隨ACK報(bào)文發(fā)送擁塞 ：如果網(wǎng)絡(luò)出現(xiàn)擁塞，分組將會(huì)丟失，此時(shí) 方會(huì)繼續(xù)重傳，從而導(dǎo)致網(wǎng)絡(luò)擁塞程度更高。因此當(dāng)出現(xiàn)擁塞時(shí)，應(yīng)當(dāng)這一點(diǎn)和流量 很像，但是出發(fā)點(diǎn)不同。流量 是 接收方能來(lái)得及接收，而擁塞 是為了降低整個(gè)網(wǎng)絡(luò)的擁塞程度。TCP 主要通過(guò)四個(gè)算法來(lái)進(jìn)行擁塞 ：慢開(kāi)始、擁塞避免、快重傳、快恢復(fù)。3、T

4、CP的握手、揮 制？TCP的握 制：TCP的揮 制：詳情參考：4、TCP的粘包/拆包 及其解決方法是什么？為什么會(huì)發(fā)生TCP粘包、拆包？ 發(fā)生TCP粘包、拆包主要是由于下面一些 ：1. 應(yīng)用程序?qū)懭氲臄?shù)據(jù)大于套接字緩沖區(qū)大小，這將會(huì)發(fā)生拆包。2. 應(yīng)用程序?qū)懭霐?shù)據(jù)小于套接字緩沖區(qū)大小，網(wǎng)卡將應(yīng)用多次寫(xiě)入的數(shù)據(jù) 到網(wǎng)絡(luò)上，這將會(huì)發(fā)生粘包。3. 進(jìn)行MSS（最大報(bào)文長(zhǎng)度）大小的TCP分段，當(dāng)TCP報(bào)文長(zhǎng)度-TCP頭部長(zhǎng)度MSS的時(shí)候?qū)l(fā)生拆 包。4. 接收方法不及時(shí) 套接字緩沖區(qū)數(shù)據(jù)，這將發(fā)生粘包。粘包、拆包解決辦法:TCP本身是面向流的，作為網(wǎng)絡(luò)服務(wù)器，如何從這源源不斷涌來(lái)的數(shù)據(jù)流中拆分出或者合

5、并出有意義的信息呢？通常會(huì)有以下一些常用的方法：1. 端給每個(gè)數(shù)據(jù)包添加包首部，首部中應(yīng)該至少包含數(shù)據(jù)包的長(zhǎng)度，這樣接收端在接收到數(shù)據(jù)后，通過(guò) 包首部的長(zhǎng)度字段，便知道每一個(gè)數(shù)據(jù)包的實(shí)際長(zhǎng)度了。2. 端將每個(gè)數(shù)據(jù)包封裝為固定長(zhǎng)度（不夠的可以通過(guò)補(bǔ)0填充），這樣接收端每次從接收緩沖區(qū)中 固定長(zhǎng)度的數(shù)據(jù)就自然而然的把每個(gè)數(shù)據(jù)包拆 來(lái)。3. 可以在數(shù)據(jù)包之間設(shè)置邊界，如添加特殊符號(hào)，這樣，接收端通過(guò)這個(gè)邊界就可以將不同的數(shù)據(jù)包拆 。5、Netty的粘包/拆包是怎么處理的，有哪些實(shí)現(xiàn)？對(duì)于粘包和拆包問(wèn)題，常見(jiàn)的解決方案有四種：1. 客戶(hù)端在 數(shù)據(jù)包的時(shí)候，每個(gè)包都固定長(zhǎng)度，比如1024個(gè)字節(jié)大小，如果

6、客戶(hù)端 的數(shù)據(jù)長(zhǎng)度不足1024個(gè)字節(jié)，則通過(guò)補(bǔ)充空格的方式補(bǔ)全到指定長(zhǎng)度；Netty提供的FixedLengthFrameDecoder2. 客戶(hù)端在每個(gè)包的末尾使用固定的分隔符，例如rn，如果一個(gè)包被拆分了，則等待下一個(gè)包過(guò)來(lái)之后找到其中的rn，然后對(duì)其拆分后的頭部部分與前一個(gè)包的剩余部分進(jìn)行合并，這樣就得到了一個(gè)完整的包；Netty提供LineBasedFrameDecoder與DelimiterBasedFrameDecoder3. 將消息分為頭部和消息體，在頭部中保存有當(dāng)前整個(gè)消息的長(zhǎng)度，只有在 到足夠長(zhǎng)度的消息之后才算是讀到了一個(gè)完整的消息；Netyy提供了LengthFieldBa

7、sedFrameDecoder與LengthFieldPrepender4. 通過(guò)自定義協(xié)議進(jìn)行粘包和拆包的處理。Netty提供了通過(guò)實(shí)現(xiàn)MessageToByteEncoder和ByteToMessageDecoder來(lái)實(shí)現(xiàn)6、同步與異步、阻塞與非阻塞的區(qū)別？簡(jiǎn)單點(diǎn)理解就是：1. 同步，就是我調(diào)用一個(gè)功能，該功能沒(méi)有結(jié)束前，我死等結(jié)果。2. 異步，就是我調(diào)用一個(gè)功能，不需要知道該功能結(jié)果，該功能有結(jié)果后通知我（回調(diào)通知）3. 阻塞，就是調(diào)用我（函數(shù)），我（函數(shù)）沒(méi)有接收完數(shù)據(jù)或者沒(méi)有得到結(jié)果之前，我 返回。4. 非阻塞，就是調(diào)用我（函數(shù)），我（函數(shù)）立即返回，通過(guò)select通知調(diào)用者同步I

8、O和異步IO的區(qū)別就在于：數(shù)據(jù)拷貝的時(shí)候進(jìn)程是否阻塞 阻塞IO和非阻塞IO的區(qū)別就在于：應(yīng)用程序的調(diào)用是否立即返回7、說(shuō)說(shuō)網(wǎng)絡(luò)IO模型？8、BIO、NIO、AIO分別是什么？BIO:同步并阻塞 ，服務(wù)器實(shí)現(xiàn)模式為 接一個(gè)線(xiàn)程，即客戶(hù)端有連接請(qǐng)求時(shí)服務(wù)器端就需要啟動(dòng) 一個(gè)線(xiàn)程進(jìn)行處理，如果這個(gè)連接不做任何事情會(huì)造成不必要的線(xiàn)程開(kāi)銷(xiāo)，當(dāng)然可以通過(guò)線(xiàn)程池機(jī)制改 善。BIO方式適用于連接數(shù)目比較小且固定的架構(gòu)，這種方式對(duì)服務(wù)器 要求比較高，并發(fā)局限于應(yīng)用中，JDK1.4以前的唯一選擇，但程序直觀簡(jiǎn)單易理解。NIO:同步非阻塞 ，服務(wù)器實(shí)現(xiàn)模式為一個(gè)請(qǐng)求一個(gè)線(xiàn)程，即客戶(hù)端 的連接請(qǐng)求都會(huì) 到多路復(fù)用器上

9、，多路復(fù)用器輪詢(xún)到連接有I/O請(qǐng)求 啟動(dòng)一個(gè)線(xiàn)程進(jìn)行處理。NIO方式適用于連接數(shù)目多且連接比較短（輕操作）的架構(gòu)，比如聊天服務(wù)器，并發(fā)局限于應(yīng)用中，編程比較復(fù)雜，JDK1.4開(kāi)始支持。AIO:異步非阻塞 ，服務(wù)器實(shí)現(xiàn)模式為一個(gè)有效請(qǐng)求一個(gè)線(xiàn)程，客戶(hù)端的I/O請(qǐng)求都是由OS先完成了再通知服務(wù)器應(yīng)用去啟動(dòng)線(xiàn)程進(jìn)行處理.AIO方式使用于連接數(shù)目多且連接比較長(zhǎng)（重操作）的架構(gòu)，比如相 冊(cè)服務(wù)器，充分調(diào)用OS參與并發(fā)操作，編程比較復(fù)雜，JDK7開(kāi)始支持。9、select、poll、epoll的機(jī)制及其區(qū)別？單個(gè)進(jìn)程打開(kāi)的文件描述符（fd文件句柄）不一致select ：有最大連接數(shù)限制數(shù)為1024，單個(gè)進(jìn)

10、程所能打開(kāi)的最大連接數(shù)由FD_ZETSIZE宏定義。poll：poll本質(zhì)上與select沒(méi)有區(qū)別，但是它沒(méi)有最大連接數(shù)的限制， 是它是基于鏈表來(lái)的。epoll：雖然連接有上限，但是很大，1G內(nèi)存的 可以打開(kāi)10萬(wàn)左右的連接，以此類(lèi)推。Socket的方式不一致select ：輪詢(xún)的方式，一個(gè)一個(gè)的socket檢查過(guò)去，發(fā)現(xiàn)有socket活躍 進(jìn)行處理，當(dāng)線(xiàn)性socket增多時(shí)，輪詢(xún)的速度將會(huì)變得很慢，造成線(xiàn)性造 能下降問(wèn)題。poll：對(duì)select稍微進(jìn)行了優(yōu)化，只是修改了文件描述符，但是 socket的方式還是輪詢(xún)。expoll：epoll內(nèi)核中實(shí)現(xiàn)是根據(jù)每個(gè)fd上的callback函數(shù)來(lái)實(shí)

11、現(xiàn)的，只有活躍的socket才會(huì)主動(dòng) 調(diào)用callback，通知expoll來(lái)處理這個(gè)socket。（會(huì)將連接的socket 到epoll中, 相當(dāng)于socket 的花名冊(cè), 如果有一個(gè)socket活躍了, 會(huì)回調(diào)一個(gè)函數(shù), 通知epoll,趕緊過(guò)來(lái)處理）內(nèi)存空間拷貝方式（消息傳遞方式）不一致 select：內(nèi)核想將消息傳遞到用戶(hù)態(tài)，需要將數(shù)據(jù)從內(nèi)核態(tài)拷貝到用戶(hù)態(tài),這個(gè)過(guò)程非常的耗時(shí)poll：同上epoll：epoll的內(nèi)核和用戶(hù)空間共享一塊內(nèi)存，因此內(nèi)存態(tài)數(shù)據(jù)和用戶(hù)態(tài)數(shù)據(jù)是共享的select、poll、epoll時(shí)間復(fù)雜度分別是：O(n)、O(n)、O(1)10、Netty跟Java NIO

12、有什么不同，為什么不直接使用JDK NIO類(lèi)庫(kù)？NIO有什么缺點(diǎn)：NIO的類(lèi)庫(kù)和API還是有點(diǎn)復(fù)雜，比如Buffer的使用 Selector編寫(xiě)復(fù)雜，如果對(duì)某個(gè) 后，業(yè)務(wù)代碼過(guò)于耦合 需要了解很多多線(xiàn)程的知識(shí)，熟悉網(wǎng)絡(luò)編程 面對(duì)斷 連、保丟失、粘包等，處理復(fù)雜NIO存在BUG，根據(jù)網(wǎng)上 說(shuō)是selector空輪訓(xùn)導(dǎo)致CPU飆升，具體有 的 JDK的官網(wǎng)Netty主要的優(yōu)點(diǎn)有：框架設(shè)計(jì)優(yōu)雅，底層模型隨意切換適應(yīng)不同的網(wǎng)絡(luò)協(xié)議要求提供很多標(biāo)準(zhǔn)的協(xié)議、安全、編碼 的支持解決了很多NIO不易用的問(wèn)題在很多開(kāi)源框架中使用，如Dubbo、RocketMQ、Spark等底層 有：Zero-Copy-Capa

13、ble Buffer，非常易用的靈拷貝Buffer（這個(gè)內(nèi)容很有意思，稍后專(zhuān)門(mén)來(lái)說(shuō)）；統(tǒng)一的API； 擴(kuò)展的時(shí)間模型傳輸方面的支持有：管道通信（具體不知道干啥的，還請(qǐng)老司機(jī)指教）；Http隧道；TCP與UDP協(xié)議方面的支持有：基于原始文本和二進(jìn)制的協(xié)議；解壓縮；大文件傳輸；流 傳輸；protobuf編 ；安全認(rèn)證；http和websocket總之提供了很多現(xiàn)成的功能可以直接供開(kāi)發(fā)者使用。12、Netty組件有哪些，分別有什么關(guān)聯(lián)？ChannelSocketEventLoop流，多線(xiàn)程處理，并發(fā)；ChannelHandler和ChannelPipeline Bootstrap 和 ServerB

14、ootstrap13、說(shuō)說(shuō)Netty的執(zhí)行流程？1. 創(chuàng)建ServerBootStrap實(shí)例2. 設(shè)置并綁定Reactor線(xiàn)程池：EventLoopGroup，EventLoop就是處理所有 到本線(xiàn)程的Selector上面的Channel3. 設(shè)置并綁定服務(wù)端的channel4. 創(chuàng)建處理網(wǎng)絡(luò) 的ChannelPipeline和handler，網(wǎng)絡(luò)時(shí)間以流的形式在其中流轉(zhuǎn)，handler完成 多數(shù)的功能定制：比如編 SSl安全認(rèn)證5. 綁定并啟動(dòng) 端口6. 當(dāng)輪訓(xùn)到準(zhǔn)備就緒的channel后，由Reactor線(xiàn)程：NioEventLoop執(zhí)行pipline中的方法，最終調(diào)度 并執(zhí)行channe

15、lHandler高級(jí)篇14、Netty高性能體現(xiàn)在哪些方面？.15、Netty的線(xiàn)程模型是怎么樣的？Reactor線(xiàn)程模型Reactor單線(xiàn)程模型 一個(gè)NIO線(xiàn)程+一個(gè)accept線(xiàn)程：Reactor多線(xiàn)程模型Reactor主從模型 主從Reactor多線(xiàn)程：多個(gè)acceptor的NIO線(xiàn)程池用于接受客戶(hù)端的連接Netty可以基于如上三種模型進(jìn)行靈活的配置?？偨Y(jié)Netty是建立在NIO基礎(chǔ)之上，Netty在NIO之上又提供了更 次的抽象。在Netty里面，Accept連接可以使用單獨(dú)的線(xiàn)程 處理，讀寫(xiě)操作又是另外的線(xiàn)程 處理。Accept連接和讀寫(xiě)操作也可以使用同一個(gè)線(xiàn)程 進(jìn)行處理。而請(qǐng)求處理

16、邏輯既可以使用單獨(dú)的線(xiàn)程 處理，也可以跟放在讀寫(xiě)線(xiàn)程一塊處理。線(xiàn)程 的每一個(gè)線(xiàn)程都是NIO線(xiàn)程。用戶(hù)可以根據(jù)實(shí)際情況進(jìn)行組裝，構(gòu)造出滿(mǎn)足系統(tǒng)需求的高性能并發(fā)模型。16、Netty的零拷貝提體現(xiàn)在哪里，與操 上的有什么區(qū)別？傳統(tǒng)意義的拷貝是在 數(shù)據(jù)的時(shí)候， 傳統(tǒng)的實(shí)現(xiàn)方式是：1. File.read(bytes)2. Socket.send(bytes)這種方式需要四次數(shù)據(jù)拷貝和四次上下文切換：1. 數(shù)據(jù)從磁盤(pán) 到內(nèi)核的read buffer2. 數(shù)據(jù)從內(nèi)核緩沖區(qū)拷貝到用戶(hù)緩沖區(qū)3. 數(shù)據(jù)從用戶(hù)緩沖區(qū)拷貝到內(nèi)核的socket buffer4. 數(shù)據(jù)從內(nèi)核的socket buffer拷貝到網(wǎng)卡接口

17、（硬件）的緩沖區(qū)零拷貝的概念明顯上面的第二 第三步是沒(méi)有必要的，通過(guò)java的FileChannel.transferTo方法，可以避免上面兩次多余的拷貝（當(dāng)然這需要底層操 支持）1. 調(diào)用transferTo,數(shù)據(jù)從文件由DMA引擎拷貝到內(nèi)核read buffer2. 接著DMA從內(nèi)核read buffer將數(shù)據(jù)拷貝到網(wǎng)卡接口buffer上面的兩次操作都不需要CPU參與，所以就達(dá)到了零拷貝。Netty中的零拷貝主要體現(xiàn)在三個(gè)方面：1、bytebufferNetty 和接收消息主要使用bytebuffer，bytebuffer使用對(duì)外內(nèi)存（DirectMemory）直接進(jìn)行Socket讀寫(xiě)。

18、：如果使用傳統(tǒng)的堆內(nèi)存進(jìn)行Socket讀寫(xiě)，JVM會(huì)將堆內(nèi)存buffer拷貝一份到直接內(nèi)存中然后再寫(xiě)入socket，多了一次緩沖區(qū)的內(nèi)存拷貝。DirectMemory中可以直接通過(guò)DMA 到網(wǎng)卡接口2、Composite Buffers傳統(tǒng)的ByteBuffer，如果需要將兩個(gè)ByteBuffer中的數(shù)據(jù)組合到一起，我們需要首先創(chuàng)建一個(gè)size=size1+size2大小的新的數(shù)組，然后將兩個(gè)數(shù)組中的數(shù)據(jù)拷貝到新的數(shù)組中。但是使用Netty提供的組合ByteBuf，就可以避免這樣的操作，因?yàn)镃ompositeByteBuf并沒(méi)有真正將多個(gè) Buffer組合起來(lái)，而是保存了它們的 ，從而避免了數(shù)

19、據(jù)的拷貝，實(shí)現(xiàn)了零拷貝。3、對(duì)于FileChannel.transferTo的使用Netty中使用了FileChannel的transferTo方法，該方法依賴(lài)于操實(shí)現(xiàn)零拷貝。17、Netty的內(nèi)存 怎么實(shí)現(xiàn)的？netty內(nèi)存池實(shí)現(xiàn)原理netty內(nèi)存池可以分配堆內(nèi)存和 內(nèi)存（Direct內(nèi)存），內(nèi)存分配的 算法是類(lèi)似的，從堆內(nèi)存分配代碼入手來(lái)學(xué)習(xí)整個(gè)內(nèi)存池的原理。netty框架處理IO 時(shí)，使用ByteBuf承載數(shù)據(jù)。ByteBuf的內(nèi)存分配由PooledByteBufAllocator來(lái)執(zhí)行，最終的內(nèi)存分配工作會(huì)被委托給PoolArena，堆內(nèi)存分配的PoolArena實(shí)現(xiàn)是HeapAren

20、ty通常被用于高并發(fā)系統(tǒng)，多線(xiàn)程競(jìng)爭(zhēng)加鎖會(huì)影響內(nèi)存分配的效率，為了緩解高并發(fā)時(shí)的線(xiàn)程競(jìng)爭(zhēng)，netty 使用者創(chuàng)建多個(gè)分配器（PoolArena）來(lái)分離線(xiàn)程競(jìng)爭(zhēng)，提高內(nèi)存分配效率?？赏ㄟ^(guò)PooledByteBufAllocator構(gòu)造子中的nHeapArena參數(shù)來(lái)設(shè)置PoolArena的數(shù)量，或者直接取框架中的 默認(rèn)值，通過(guò)以下代碼決定默認(rèn)值，默認(rèn)值根據(jù)CPU 數(shù)、JVM最大可用內(nèi)存以及默認(rèn)內(nèi)存塊（PoolChunk）大小等參數(shù)來(lái)計(jì)算這個(gè)默認(rèn)值，計(jì)算邏輯是：1）獲取系統(tǒng)變量ty.allocator.numHeapArenas，通過(guò)System.setProperty(ty.alloc

21、ator.numHeapArenas, )或者增加JVM啟動(dòng)參數(shù)- Dty.allocator.numHeapArenas= 設(shè)置，如果設(shè)置了值，把這個(gè)值當(dāng)做Arena的個(gè)數(shù)。2）如果沒(méi)有設(shè)置ty.allocator.numHeapArenas系統(tǒng)變量，計(jì)算CPU 數(shù)*2和JVM最大可用內(nèi)存/默認(rèn)內(nèi)存塊大小/2/3，取其中一個(gè)較少的值當(dāng)做PoolArena的個(gè)數(shù)。確定PoolArena個(gè)數(shù)之后框架會(huì)創(chuàng)建一個(gè)PoolArena數(shù)組，數(shù)組中所有的PoolArena都會(huì)用來(lái)執(zhí)行內(nèi)存 分配。線(xiàn)程申請(qǐng)內(nèi)存分配時(shí)，線(xiàn)程會(huì)在這個(gè)PoolArena數(shù)組中挑選一個(gè)當(dāng)前被占用次數(shù)最少的Arena執(zhí)行內(nèi)存分配。此外

22、，netty使用擴(kuò)展的線(xiàn)程對(duì)象FastThreadLocalThread來(lái)優(yōu)化ThreadLocal性能，具體的優(yōu)化思路 是：默認(rèn)的ThreadLocal使用ThreadLocalMap 線(xiàn)程局部變量，它的實(shí)現(xiàn)方式類(lèi)似于HashMap，需 要計(jì)算hashCode 到線(xiàn)程局部變量所在Entry的索引，而FastThreadLocalThread使用FastThreadLocal代替ThreadLocal，F(xiàn)astThreadLocalThread用一個(gè)數(shù)組來(lái)維護(hù)線(xiàn)程變量，每個(gè)FastThreadLocal維護(hù)一個(gè)index，該index就是線(xiàn)程局部變量在數(shù)組中的位置，線(xiàn)程變量直接通過(guò)index無(wú)需計(jì)算hashCode，F(xiàn)astThreadLocal的優(yōu)勢(shì)是減少了hashCode的計(jì)算過(guò)程，雖然性能只會(huì)有輕微的提升，但在高并發(fā)系統(tǒng)中，即使只是輕微的提升也會(huì)成倍放大。請(qǐng)閱讀文章：?.18、Netty的對(duì)象 怎么實(shí)現(xiàn)的？Netty 并沒(méi)有使用第 庫(kù)實(shí)現(xiàn)對(duì)象池，而是 實(shí)現(xiàn)了一個(gè)相對(duì)輕量的對(duì)象池。通過(guò)使用threadLocal，避免了多線(xiàn)程下取數(shù)據(jù)時(shí)可能出現(xiàn)的線(xiàn)程安全問(wèn)題，同時(shí)，為了實(shí)現(xiàn)多線(xiàn)程回收同一個(gè) 實(shí)