[[407305]]

一 什么是 Netty? 能做什么?

Netty 是一個(gè)致力于創(chuàng)建高性能網(wǎng)絡(luò)應(yīng)用程序的成熟的 IO 框架。

相比較與直接使用底層的 Java IO API，你不需要先成為網(wǎng)絡(luò)專家就可以基于 Netty 去構(gòu)建復(fù)雜的網(wǎng)絡(luò)應(yīng)用。

業(yè)界常見(jiàn)的涉及到網(wǎng)絡(luò)通信的相關(guān)中間件大部分基于 Netty 實(shí)現(xiàn)網(wǎng)絡(luò)層。

二 設(shè)計(jì)一個(gè)分布式服務(wù)框架

1 Architecture

2 遠(yuǎn)程調(diào)用的流程

啟動(dòng)服務(wù)端(服務(wù)提供者)并發(fā)布服務(wù)到注冊(cè)中心。
啟動(dòng)客戶端(服務(wù)消費(fèi)者)并去注冊(cè)中心訂閱感興趣的服務(wù)。
客戶端收到注冊(cè)中心推送的服務(wù)地址列表。
調(diào)用者發(fā)起調(diào)用，Proxy從服務(wù)地址列表中選擇一個(gè)地址并將請(qǐng)求信息 <group，providerName，version>，methodName，args[] 等信息序列化為字節(jié)數(shù)組并通過(guò)網(wǎng)絡(luò)發(fā)送到該地址上。
服務(wù)端收到收到并反序列化請(qǐng)求信息，根據(jù) <group，providerName，version> 從本地服務(wù)字典里查找到對(duì)應(yīng)providerObject，再根據(jù) <methodName，args[]> 通過(guò)反射調(diào)用指定方法，并將方法返回值序列化為字節(jié)數(shù)組返回給客戶端。
客戶端收到響應(yīng)信息再反序列化為 Java 對(duì)象后由 Proxy 返回給方法調(diào)用者。
以上流程對(duì)方法調(diào)用者是透明的，一切看起來(lái)就像本地調(diào)用一樣。

3 遠(yuǎn)程調(diào)用客戶端圖解

重要概念：RPC三元組 <ID，Request，Response>。

PS: 若是 netty4.x 的線程模型，IO Thread(worker) —> Map<InvokeId，F(xiàn)uture> 代替全局 Map 能更好的避免線程競(jìng)爭(zhēng)。

4 遠(yuǎn)程調(diào)用服務(wù)端圖解

5 遠(yuǎn)程調(diào)用傳輸層圖解

6 設(shè)計(jì)傳輸層協(xié)議棧

協(xié)議頭

協(xié)議體

1）metadata: <group，providerName，version>

2）methodName

3）parameterTypes[] 真的需要嗎?

（a）有什么問(wèn)題?

反序列化時(shí) ClassLoader.loadClass() 潛在鎖競(jìng)爭(zhēng)。
協(xié)議體碼流大小。
泛化調(diào)用多了參數(shù)類型。
（b）能解決嗎?

Java方法靜態(tài)分派規(guī)則參考JLS <Java語(yǔ)言規(guī)范> $15.12.2.5 Choosing the Most Specific Method 章節(jié)。
（c）args[]

（d）其他：traceId，appName…

三 一些Features&好的實(shí)踐&壓榨性能

1 創(chuàng)建客戶端代理對(duì)象

1）Proxy 做什么?

集群容錯(cuò) —> 負(fù)載均衡 —> 網(wǎng)絡(luò)
2）有哪些創(chuàng)建 Proxy 的方式?

jdk proxy/javassist/cglib/asm/bytebuddy
3）要注意的：

注意攔截toString，equals，hashCode等方法避免遠(yuǎn)程調(diào)用。
4）推薦的(bytebuddy)：

2 優(yōu)雅的同步/異步調(diào)用

先往上翻再看看“遠(yuǎn)程調(diào)用客戶端圖解”
再往下翻翻看看 Failover 如何處理更好
思考下如何拿到 future?

3 單播/組播

消息派發(fā)器
FutureGroup

4 泛化調(diào)用

5 序列化/反序列化

協(xié)議 header 標(biāo)記 serializer type，同時(shí)支持多種。

6 可擴(kuò)展性

Java SPI：

java.util.ServiceLoader
META-INF/services/com.xxx.Xxx

7 服務(wù)級(jí)別線程池隔離

要掛你先掛，別拉著我。

8 責(zé)任鏈模式的攔截器

太多擴(kuò)展需要從這里起步。

9 指標(biāo)度量(Metrics)

10 鏈路追蹤

OpenTracing

11 注冊(cè)中心

12 流控(應(yīng)用級(jí)別/服務(wù)級(jí)別)

要有能方便接入第三方流控中間件的擴(kuò)展能力。

13 Provider線程池滿了怎么辦?

14 軟負(fù)載均衡

1）加權(quán)隨機(jī) (二分法，不要遍歷)

2）加權(quán)輪訓(xùn)(最大公約數(shù))

3）最小負(fù)載

4）一致性 hash (有狀態(tài)服務(wù)場(chǎng)景)

5）其他

注意：要有預(yù)熱邏輯。

15 集群容錯(cuò)

1）Fail-fast

2）Failover

異步調(diào)用怎么處理?

Bad

Better

3）Fail-safe

4）Fail-back

5）Forking

6）其他

16 如何壓榨性能(Don’t trust it，Test it)

1）ASM 寫(xiě)個(gè) FastMethodAccessor 來(lái)代替服務(wù)端那個(gè)反射調(diào)用

2）序列化/反序列化

在業(yè)務(wù)線程中序列化/反序列化，避免占用 IO 線程：

序列化/反序列化占用數(shù)量極少的 IO 線程時(shí)間片。
反序列化常常會(huì)涉及到 Class 的加載，loadClass 有一把鎖競(jìng)爭(zhēng)嚴(yán)重(可通過(guò) JMC 觀察一下)。
選擇高效的序列化/反序列化框架：

如kryo/protobuf/protostuff/hessian/fastjson/…
選擇只是第一步，它(序列化框架)做的不好的，去擴(kuò)展和優(yōu)化之：

傳統(tǒng)的序列化/反序列化+寫(xiě)入/讀取網(wǎng)絡(luò)的流程：java對(duì)象--> byte[] -->堆外內(nèi)存 / 堆外內(nèi)存--> byte[] -->java對(duì)象。
優(yōu)化：省去 byte[] 環(huán)節(jié)，直接 讀/寫(xiě) 堆外內(nèi)存，這需要擴(kuò)展對(duì)應(yīng)的序列化框架。
String 編碼/解碼優(yōu)化。
Varint 優(yōu)化：多次 writeByte 合并為 writeShort/writeInt/writeLong。
Protostuff 優(yōu)化舉例：UnsafeNioBufInput 直接讀堆外內(nèi)存/UnsafeNioBufOutput 直接寫(xiě)堆外內(nèi)存。
3）IO 線程綁定 CPU

4）同步阻塞調(diào)用的客戶端和容易成為瓶頸，客戶端協(xié)程：

Java層面可選的并不多，暫時(shí)也都不完美。

5）Netty Native Transport & PooledByteBufAllocator：

減小GC帶來(lái)的波動(dòng)。
6）盡快釋放 IO 線程去做他該做的事情，盡量減少線程上下文切換。

四 Why Netty?

1 BIO vs NIO

2 Java 原生 NIO API 從入門到放棄

復(fù)雜度高

API復(fù)雜難懂，入門困。
粘包/半包問(wèn)題費(fèi)神。
需超強(qiáng)的并發(fā)/異步編程功底，否則很難寫(xiě)出高效穩(wěn)定的實(shí)現(xiàn)。
穩(wěn)定性差，坑多且深

調(diào)試?yán)щy，偶爾遭遇匪夷所思極難重現(xiàn)的bug，邊哭邊查是常有的事兒。
linux 下 EPollArrayWrapper.epollWait 直接返回導(dǎo)致空輪訓(xùn)進(jìn)而導(dǎo)致 100% cpu 的 bug 一直也沒(méi)解決利索，Netty幫你 work around (通過(guò)rebuilding selector)。

NIO代碼實(shí)現(xiàn)方面的一些缺點(diǎn)

1）Selector.selectedKeys() 產(chǎn)生太多垃圾

Netty 修改了 sun.nio.ch.SelectorImpl 的實(shí)現(xiàn)，使用雙數(shù)組代替 HashSet 存儲(chǔ)來(lái) selectedKeys：

相比HashSet(迭代器，包裝對(duì)象等)少了一些垃圾的產(chǎn)生(help GC)。
輕微的性能收益(1~2%)。
Nio 的代碼到處是 synchronized (比如 allocate direct buffer 和 Selector.wakeup() )：

對(duì)于 allocate direct buffer，Netty 的 pooledBytebuf 有前置 TLAB(Thread-local allocation buffer)可有效的減少去競(jìng)爭(zhēng)鎖。
wakeup 調(diào)用多了鎖競(jìng)爭(zhēng)嚴(yán)重并且開(kāi)銷非常大(開(kāi)銷大原因: 為了在 select 線程外跟 select 線程通信，linux 平臺(tái)上用一對(duì) pipe，windows 由于 pipe 句柄不能放入 fd_set，只能委曲求全用兩個(gè) tcp 連接模擬)，wakeup 調(diào)用少了容易導(dǎo)致 select 時(shí)不必要的阻塞(如果懵逼了就直接用 Netty 吧，Netty中有對(duì)應(yīng)的優(yōu)化邏輯)。
Netty Native Transport 中鎖少了很多。
2）fdToKey 映射

EPollSelectorImpl#fdToKey 維持著所有連接的 fd(描述符)對(duì)應(yīng) SelectionKey 的映射，是個(gè) HashMap。
每個(gè) worker 線程有一個(gè) selector，也就是每個(gè) worker 有一個(gè) fdToKey，這些 fdToKey 大致均分了所有連接。
想象一下單機(jī) hold 幾十萬(wàn)的連接的場(chǎng)景，HashMap 從默認(rèn) size=16，一步一步 rehash...
3）Selector在linux 平臺(tái)是 Epoll LT 實(shí)現(xiàn)

Netty Native Transport支持Epoll ET。
4）Direct Buffers 事實(shí)上還是由 GC 管理

DirectByteBuffer.cleaner 這個(gè)虛引用負(fù)責(zé) free direct memory，DirectByteBuffer 只是個(gè)殼子，這個(gè)殼子如果堅(jiān)強(qiáng)的活下去熬過(guò)新生代的年齡限制最終晉升到老年代將是一件讓人傷心的事情…
無(wú)法申請(qǐng)到足夠的 direct memory 會(huì)顯式觸發(fā) GC，Bits.reserveMemory() -> { System.gc() }，首先因?yàn)?GC 中斷整個(gè)進(jìn)程不說(shuō)，代碼中還 sleep 100 毫秒，醒了要是發(fā)現(xiàn)還不行就 OOM。
更糟的是如果你聽(tīng)信了個(gè)別<XX優(yōu)化寶典>讒言設(shè)置了-XX:+DisableExplicitGC 參數(shù)，悲劇會(huì)靜悄悄的發(fā)生...
Netty的UnpooledUnsafeNoCleanerDirectByteBuf 去掉了 cleaner，由 Netty 框架維護(hù)引用計(jì)數(shù)來(lái)實(shí)時(shí)的去釋放。

五 Netty 的真實(shí)面目

1 Netty 中幾個(gè)重要概念及其關(guān)系

EventLoop

一個(gè) Selector。
一個(gè)任務(wù)隊(duì)列(mpsc_queue: 多生產(chǎn)者單消費(fèi)者 lock-free)。
一個(gè)延遲任務(wù)隊(duì)列(delay_queue: 一個(gè)二叉堆結(jié)構(gòu)的優(yōu)先級(jí)隊(duì)列，復(fù)雜度為O(log n))。
EventLoop 綁定了一個(gè) Thread，這直接避免了pipeline 中的線程競(jìng)爭(zhēng)。

Boss: mainReactor 角色，Worker: subReactor 角色

Boss 和 Worker 共用 EventLoop 的代碼邏輯，Boss 處理 accept 事件，Worker 處理 read，write 等事件。
Boss 監(jiān)聽(tīng)并 accept 連接(channel)后以輪訓(xùn)的方式將 channel 交給 Worker，Worker 負(fù)責(zé)處理此 channel 后續(xù)的read/write 等 IO 事件。
在不 bind 多端口的情況下 BossEventLoopGroup 中只需要包含一個(gè) EventLoop，也只能用上一個(gè)，多了沒(méi)用。
WorkerEventLoopGroup 中一般包含多個(gè) EventLoop，經(jīng)驗(yàn)值一般為 cpu cores * 2(根據(jù)場(chǎng)景測(cè)試找出最佳值才是王道)。
Channel 分兩大類 ServerChannel 和 Channel，ServerChannel 對(duì)應(yīng)著監(jiān)聽(tīng)套接字(ServerSocketChannel)，Channel 對(duì)應(yīng)著一個(gè)網(wǎng)絡(luò)連接。

2 Netty4 Thread Model

3 ChannelPipeline

4 Pooling&reuse

PooledByteBufAllocator

基于 jemalloc paper (3.x)
ThreadLocal caches for lock free：這個(gè)做法導(dǎo)致曾經(jīng)有坑——申請(qǐng)(Bytebuf)線程與歸還(Bytebuf)線程不是同一個(gè)導(dǎo)致內(nèi)存泄漏，后來(lái)用一個(gè)mpsc_queue解決，代價(jià)就是犧牲了一點(diǎn)點(diǎn)性能。
Different size classes。

Recycler

ThreadLocal + Stack。
曾經(jīng)有坑，申請(qǐng)(元素)線程與歸還(元素)線程不是同一個(gè)導(dǎo)致內(nèi)存泄漏。
后來(lái)改進(jìn)為不同線程歸還元素的時(shí)候放入一個(gè) WeakOrderQueue 中并關(guān)聯(lián)到 stack 上，下次 pop 時(shí)如果 stack 為空則先掃描所有關(guān)聯(lián)到當(dāng)前 stack 上的 weakOrderQueue。
WeakOrderQueue 是多個(gè)數(shù)組的鏈表，每個(gè)數(shù)組默認(rèn)size=16。
存在的問(wèn)題：思考一下老年代對(duì)象引用新生代對(duì)象對(duì) GC 的影響？

5 Netty Native Transport

相比 Nio 創(chuàng)建更少的對(duì)象，更小的 GC 壓力。

針對(duì) linux 平臺(tái)優(yōu)化，一些 specific features：

SO_REUSEPORT - 端口復(fù)用(允許多個(gè) socket 監(jiān)聽(tīng)同一個(gè) IP+端口，與 RPS/RFS 協(xié)作，可進(jìn)一步提升性能)：可把 RPS/RFS 模糊的理解為在軟件層面模擬多隊(duì)列網(wǎng)卡，并提供負(fù)載均衡能力，避免網(wǎng)卡收包發(fā)包的中斷集中的一個(gè) CPU core 上而影響性能。
TCP_FASTOPEN - 3次握手時(shí)也用來(lái)交換數(shù)據(jù)。
EDGE_TRIGGERED (支持Epoll ET是重點(diǎn))。
Unix 域套接字(同一臺(tái)機(jī)器上的進(jìn)程間通信，比如Service Mesh)。

6 多路復(fù)用簡(jiǎn)介

select/poll

本身的實(shí)現(xiàn)機(jī)制上的限制(采用輪詢方式檢測(cè)就緒事件，時(shí)間復(fù)雜度: O(n)，每次還要將臃腫的 fd_set 在用戶空間和內(nèi)核空間拷貝來(lái)拷貝去)，并發(fā)連接越大，性能越差。
poll 相比 select 沒(méi)有很大差異，只是取消了最大文件描述符個(gè)數(shù)的限制。
select/poll 都是 LT 模式。
epoll

采用回調(diào)方式檢測(cè)就緒事件，時(shí)間復(fù)雜度: O(1)，每次 epoll_wait 調(diào)用只返回已就緒的文件描述符。
epoll 支持 LT 和 ET 模式。

7 稍微深入了解一點(diǎn) Epoll

LT vs ET

概念：

LT：level-triggered 水平觸發(fā)
ET：edge-triggered 邊沿觸發(fā)
可讀：

buffer 不為空的時(shí)候 fd 的 events 中對(duì)應(yīng)的可讀狀態(tài)就被置為1，否則為0。
可寫(xiě)：

buffer 中有空間可寫(xiě)的時(shí)候 fd 的 events 中對(duì)應(yīng)的可寫(xiě)狀態(tài)就被置為1，否則為0。
圖解：

epoll 三個(gè)方法簡(jiǎn)介

1）主要代碼：linux-2.6.11.12/fs/eventpoll.c

2）int epoll_create(int size)

創(chuàng)建 rb-tree(紅黑樹(shù))和 ready-list (就緒鏈表)：

紅黑樹(shù)O(logN)，平衡效率和內(nèi)存占用，在容量需求不能確定并可能量很大的情況下紅黑樹(shù)是最佳選擇。
size參數(shù)已經(jīng)沒(méi)什么意義，早期epoll實(shí)現(xiàn)是hash表，所以需要size參數(shù)。
3）int epoll_ctl(int epfd，int op，int fd，struct epoll_event *event)

把epitem放入rb-tree并向內(nèi)核中斷處理程序注冊(cè)ep_poll_callback，callback觸發(fā)時(shí)把該epitem放進(jìn)ready-list。
4）int epoll_wait(int epfd，struct epoll_event * events，int maxevents，int timeout)

ready-list —> events[]。

epoll 的數(shù)據(jù)結(jié)構(gòu)

epoll_wait 工作流程概述

對(duì)照代碼：linux-2.6.11.12/fs/eventpoll.c：

1）epoll_wait 調(diào)用 ep_poll

當(dāng) rdlist(ready-list) 為空(無(wú)就緒fd)時(shí)掛起當(dāng)前線程,直到 rdlist 不為空時(shí)線程才被喚醒。

2）文件描述符 fd 的 events 狀態(tài)改變

buffer由不可讀變?yōu)榭勺x或由不可寫(xiě)變?yōu)榭蓪?xiě)，導(dǎo)致相應(yīng)fd上的回調(diào)函數(shù)ep_poll_callback被觸發(fā)。

3）ep_poll_callback 被觸發(fā)

將相應(yīng)fd對(duì)應(yīng)epitem加入rdlist，導(dǎo)致rdlist不空，線程被喚醒，epoll_wait得以繼續(xù)執(zhí)行。

4）執(zhí)行 ep_events_transfer 函數(shù)

將rdlist中的epitem拷貝到txlist中，并將rdlist清空。
如果是epoll LT，并且fd.events狀態(tài)沒(méi)有改變(比如buffer中數(shù)據(jù)沒(méi)讀完并不會(huì)改變狀態(tài))，會(huì)再重新將epitem放回rdlist。

5）執(zhí)行 ep_send_events 函數(shù)

掃描txlist中的每個(gè)epitem，調(diào)用其關(guān)聯(lián)fd對(duì)應(yīng)的poll方法取得較新的events。
將取得的events和相應(yīng)的fd發(fā)送到用戶空間。

8 Netty 的最佳實(shí)踐

1）業(yè)務(wù)線程池必要性

業(yè)務(wù)邏輯尤其是阻塞時(shí)間較長(zhǎng)的邏輯，不要占用netty的IO線程，dispatch到業(yè)務(wù)線程池中去。

2）WriteBufferWaterMark

注意默認(rèn)的高低水位線設(shè)置(32K~64K)，根據(jù)場(chǎng)景適當(dāng)調(diào)整(可以思考一下如何利用它)。

3）重寫(xiě) MessageSizeEstimator 來(lái)反應(yīng)真實(shí)的高低水位線

默認(rèn)實(shí)現(xiàn)不能計(jì)算對(duì)象size，由于write時(shí)還沒(méi)路過(guò)任何一個(gè)outboundHandler就已經(jīng)開(kāi)始計(jì)算message size，此時(shí)對(duì)象還沒(méi)有被encode成Bytebuf，所以size計(jì)算肯定是不準(zhǔn)確的(偏低)。

4）注意EventLoop#ioRatio的設(shè)置(默認(rèn)50)

這是EventLoop執(zhí)行IO任務(wù)和非IO任務(wù)的一個(gè)時(shí)間比例上的控制。

5）空閑鏈路檢測(cè)用誰(shuí)調(diào)度?

Netty4.x默認(rèn)使用IO線程調(diào)度，使用eventLoop的delayQueue，一個(gè)二叉堆實(shí)現(xiàn)的優(yōu)先級(jí)隊(duì)列，復(fù)雜度為O(log N)，每個(gè)worker處理自己的鏈路監(jiān)測(cè)，有助于減少上下文切換，但是網(wǎng)絡(luò)IO操作與idle會(huì)相互影響。
如果總的連接數(shù)小，比如幾萬(wàn)以內(nèi)，上面的實(shí)現(xiàn)并沒(méi)什么問(wèn)題，連接數(shù)大建議用HashedWheelTimer實(shí)現(xiàn)一個(gè)IdleStateHandler，HashedWheelTimer復(fù)雜度為 O(1)，同時(shí)可以讓網(wǎng)絡(luò)IO操作和idle互不影響，但有上下文切換開(kāi)銷。

6）使用ctx.writeAndFlush還是channel.writeAndFlush?

ctx.write直接走到下一個(gè)outbound handler，注意別讓它違背你的初衷繞過(guò)了空閑鏈路檢測(cè)。
channel.write從末尾開(kāi)始倒著向前挨個(gè)路過(guò)pipeline中的所有outbound handlers。

7）使用Bytebuf.forEachByte() 來(lái)代替循環(huán) ByteBuf.readByte()的遍歷操作，避免rangeCheck()

8）使用CompositeByteBuf來(lái)避免不必要的內(nèi)存拷貝

缺點(diǎn)是索引計(jì)算時(shí)間復(fù)雜度高，請(qǐng)根據(jù)自己場(chǎng)景衡量。

9）如果要讀一個(gè)int，用Bytebuf.readInt()，不要Bytebuf.readBytes(buf，0，4)

這能避免一次memory copy (long，short等同理)。

10）配置UnpooledUnsafeNoCleanerDirectByteBuf來(lái)代替jdk的DirectByteBuf，讓netty框架基于引用計(jì)數(shù)來(lái)釋放堆外內(nèi)存

io.netty.maxDirectMemory：

< 0: 不使用cleaner，netty方面直接繼承jdk設(shè)置的最大direct memory size，(jdk的direct memory size是獨(dú)立的，這將導(dǎo)致總的direct memory size將是jdk配置的2倍)。
== 0: 使用cleaner，netty方面不設(shè)置最大direct memory size。
0：不使用cleaner，并且這個(gè)參數(shù)將直接限制netty的最大direct memory size，(jdk的direct memory size是獨(dú)立的，不受此參數(shù)限制)。

11）最佳連接數(shù)

一條連接有瓶頸，無(wú)法有效利用cpu，連接太多也白扯，最佳實(shí)踐是根據(jù)自己場(chǎng)景測(cè)試。

12）使用PooledBytebuf時(shí)要善于利用 -Dio.netty.leakDetection.level 參數(shù)

四種級(jí)別：DISABLED(禁用)，SIMPLE(簡(jiǎn)單)，ADVANCED(高級(jí))，PARANOID(偏執(zhí))。
SIMPLE，ADVANCED采樣率相同，不到1%(按位與操作 mask ==128 - 1)。
默認(rèn)是SIMPLE級(jí)別，開(kāi)銷不大。
出現(xiàn)泄漏時(shí)日志會(huì)出現(xiàn)“LEAK: ”字樣，請(qǐng)時(shí)不時(shí)grep下日志，一旦出現(xiàn)“LEAK: ”立刻改為ADVANCED級(jí)別再跑，可以報(bào)告泄漏對(duì)象在哪被訪問(wèn)的。
PARANOID：測(cè)試的時(shí)候建議使用這個(gè)級(jí)別，100%采樣。

13）Channel.attr()，將自己的對(duì)象attach到channel上

拉鏈法實(shí)現(xiàn)的線程安全的hash表，也是分段鎖(只鎖鏈表頭)，只有hash沖突的情況下才有鎖競(jìng)爭(zhēng)(類似ConcurrentHashMapV8版本)。
默認(rèn)hash表只有4個(gè)桶，使用不要太任性。

9 從 Netty 源碼中學(xué)到的代碼技巧

1）海量對(duì)象場(chǎng)景中 AtomicIntegerFieldUpdater --> AtomicInteger

Java中對(duì)象頭12 bytes(開(kāi)啟壓縮指針的情況下)，又因?yàn)镴ava對(duì)象按照8字節(jié)對(duì)齊，所以對(duì)象最小16 bytes，AtomicInteger大小為16 bytes，AtomicLong大小為 24 bytes。
AtomicIntegerFieldUpdater作為static field去操作volatile int。

2）FastThreadLocal，相比jdk的實(shí)現(xiàn)更快

線性探測(cè)的Hash表 —> index原子自增的裸數(shù)組存儲(chǔ)。

3）IntObjectHashMap / LongObjectHashMap …

Integer—> int
Node[] —> 裸數(shù)組

4）RecyclableArrayList

基于前面說(shuō)的Recycler，頻繁new ArrayList的場(chǎng)景可考慮。

5）JCTools

一些jdk沒(méi)有的 SPSC/MPSC/SPMC/MPMC 無(wú)鎖并發(fā)隊(duì)以及NonblockingHashMap(可以對(duì)比ConcurrentHashMapV6/V8)