前段時間，我在 B 站上看到一個技術視頻，題目叫做《機票報價高并發場景下的一些解決方案》。

up 主是 Qunar技術大本營，也就是我們耳熟能詳的“去哪兒”。

視頻鏈接在這里：

https://www.bilibili.com/video/BV1eX4y1F7zJ?p=2

當時其實我是被他的這個圖片給吸引到了（里面的 12 qps 應該是 12k qps）：

他介紹了兩個核心系統在經過一個“數據壓縮”的操作之后，分別節約了 204C 和 2160C 的服務器資源。

共計就是 2364C 的服務器資源。

如果按照一般標配的 4C8G 服務器，好家伙，這就是節約了 591 臺機器啊，你想想一年就節約了多大一筆開銷。

視頻中介紹了幾種數據壓縮的方案，其中方案之一就是用了高性能集合：

因為他們的系統設計中大量用到“本地緩存”，而本地緩存大多就是使用 HashMap 來幫忙。

所以他們把 HashMap 換成了性能更好的 IntObjectHashMap，這個類出自 Netty。

為什么換了一個類之后，就節約了這么多的資源呢？

換言之，IntObjectHashMap 性能更好的原因是什么呢？

我也不知道，所以我去研究了一下。

拉源碼

研究的第一步肯定是要找到對應的源碼。

你可以去找個 Netty 依賴，然后找到里面的 IntObjectHashMap。

我這邊本地剛好有我之前拉下來的 Netty 源碼，只需要同步一下最新的代碼就行了。

但是我在 4.1 分支里面找這個類的時候并沒有找到，只看到了一個相關的 Benchmark 類：

點進去一看，確實沒有 IntObjectHashMap 這個類：

很納悶啊，我反正也沒搞懂為啥，但是我直接就是一個不糾結了，反正我現在只是想找到一個 IntObjectHashMap 類而已。

4.1 分支如果沒有的話，那么就 4.0 上看看唄：

于是我切到了 4.0 分支里面去找了一下，很順利就找到了對應的類和測試類：

能看到測試類，其實也是我喜歡把項目源碼拉下來的原因。如果你是通過引入 Netty 的 Maven 依賴的方式找到對應類的，就看不到測試類了。

有時候配合著測試類看源碼，事半功倍，一個看源碼的小技巧，送給你。

而我要拉源碼的最重要的一個目的其實是這個：

可以看到這個類的提交記錄，觀察到這個類的演變過程，這個是很重要的。

因為一次提交絕大部分情況下對應著一次 bug 修改或者性能優化，都是我們應該關注的地方。

比如，我們可以看到這個小哥針對 hashIndex 方法提交了三次：

在正式研究 IntObjectHashMap 源碼之前，我們先看看只關注 hashIndex 這個局部的方法。

首先，這個地方現在的代碼是這樣的：

我知道這個方法是獲取 int 類型的 key 在 keys 這個數組中的下標，支持 key 是負數的情況。

那么為啥這一行代碼就提交了三次呢？

我們先看第一次提交：

非常清晰，左邊是最原始的代碼，如果 key 是負數的話，那么返回的 index 就是負數，很明顯不符合邏輯。

所以有人提交了右邊的代碼，在算出 hash 值為負數的時候，加上數組的長度，最終得到一個正數。

很快，提交代碼的哥們，發現了一個更好的寫法，進行了一次優化提交：

拿掉了小于零的判斷。不管 key%length 算出的值是正還是負，都將結果加上一個數組的長度后再次對數組的長度進行 % 運行。

這樣保證算出來的 index 一定是一個正數。

第三次提交的代碼就很好理解了，代入變量：

所以，最終的代碼就是這樣的：

return (key % keys.length + keys.length) % keys.length;

這樣的寫法，不比判斷小于零優雅的多且性能也好一點嗎？而且這也是一個常規的優化方案。

如果你看不到代碼提交記錄，你就看不到這個方法的演變過程。我想表達的是：在代碼提交記錄中能挖掘到非常多比源碼更有價值的信息。

又是一個小技巧，送給你。

IntObjectHashMap

接下來我們一起探索一下 IntObjectHashMap 的奧秘。

關于這個 Map，其實有兩個相關的類：

其中 IntObjectMap 是個接口。

它們不依賴除了 JDK 之外的任何東西，所以你搞懂原理之后，如果發現自己的業務場景下有合適的場景，完全可以把這兩個類粘貼到自己的項目中去，一行代碼都不用改，拿來就用。

在研究了官方的測試用例和代碼提交記錄之后，我選擇先把這兩個類粘出來，自己寫個代碼調試一下，這樣的好處就是可以隨時修改其中的源碼，以便我們進行研究。

在安排 IntObjectHashMap 源碼之前，我們先關注一下它 javadoc 里面的這幾句話：

第一句話就非常的關鍵，這里解釋了 IntObjectHashMap 針對 key 沖突時的解決方案：

它對于 key 使用的是 open addressing 策略，也就是開放尋址策略。

為什么使用開放尋址呢，而不是采用和 HashMap 一樣掛個鏈表呢？

這里也回答了這個問題：To minimize the memory footprint，也就是為了最小化內存占用。

怎么就減少了內存的占用呢？

這個問題下面看源碼的時候會說，但是這里提一句：你就想想如果用鏈表，是不是至少得有一個 next 指針，維護這個東西是不是又得占用空間？

不多說了，說回開放尋址。

開放尋址是一種策略，該策略也分為很多種實現方案，比如：

• 線性探測方法（Linear Probing）

• 二次探測（Quadratic probing）

• 雙重散列（Double hashing）

從上面劃線部分的最后一句話就可以知道，IntObjectHashMap 使用的就是 linear probing，即線性探測。

現在我們基本了解到 IntObjectHashMap 這個 map 針對 hash 沖突時使用的解決方案了。

接下來，我們搞個測試用例實操一把。代碼很簡單，就一個初始化，一個 put 方法：

就這么幾行代碼，一眼望去和 HashMap 好像沒啥區別。但是仔細一想，還是發現了一點端倪。

如果我們用 HashMap 的話，初始化應該是這樣的：

HashMap<Integer,Object> hashMap = new HashMap<>(10);

你再看看 IntObjectHashMap 這個類定義是怎么樣的？

只有一個 Object：

這個 Object 代表的是 map 里面裝的 value。

那么 key 是什么，去哪兒了呢？是不是第一個疑問就產生了呢？

查看 put 方法之后，我發現 key 竟然就是 int 類型的值：

也就是這個類已經限制住了 key 就是 int 類型的值，所以不能在初始化的時候指定 key 的泛型了。

這個類從命名上也已經明確說明這一點了：我是 IntObjectHashMap，key 是 int，value 是 Object 的 HashMap。

那么我為什么用了個“竟然”呢？

因為你看看 HashMap 的 key 是個啥玩意：

是個 Object 類型。

也就是說，如果我們想這樣初始化 HashMap 是不可以的：

ide 都會提醒你：老弟，別搞事啊，你這里不能放基本類型，你得搞個包裝類型進來。

而我們平常編碼的時候能這樣把 int 類型放進去，是因為有“裝箱”的操作被隱藏起來了：

所以才會有一道上古時期的八股文問題：HashMap 的 key 可以用基本類型嗎？

想也不用想，不可以！

key，從包裝類型變成了基本類型，這就是一個性能優化的點。因為眾所周知，基本類型比包裝類型占用的空間更小。

接著，我們先從它的構造方法入手，主要關注我框起來的部分：

首先進來就是兩個 if 判斷，對參數合法性進行了校驗。

接著看標號為 ① 的地方，從方法名看是要做容量調整:

從代碼和方法上的注釋可以看出，這里是想把容量調整為一個奇數，比如我給進來 8 ，它會給我調整為 9：

至于容量為什么不能是偶數，從注釋上給了一個解釋：

Even capacities can break probing.

意思是容量為偶數的時候會破壞 probing，即我們前面提到的線性探測。

額...

我并沒有考慮明白為什么偶數的容量會破壞線性探測，但是這不重要，先存疑，接著往下梳理主要流程。

從標號為 ② 的地方可以看出這是在做數據初始化的操作。前面我們得到了 capacity 為 9，這里就是初始兩個數組，分別是 key[] 和 values[]，且這兩個數組的容量是一樣的，都是 9：

兩個數組在構造方法中完成初始化后，是這樣的：

構造方法我們就主要關注容量的變化和 key[]、values[] 這兩個數組。

構造方法給你鋪墊好了，接著我們再看 put 方法，就會比較絲滑了：

put 方法的代碼也沒幾行，分析起來非常的清晰。

首先是標號為 ① 的地方，hashIndex 方法，就是獲取本次 put 的 key 對應在 key[] 數組中的下標。

這個方法文章開始的時候已經分析過了，我們甚至知道這個方法的演變過程，不再多說。

然后就是進入一個 for(;;) 循環。

先看標號為 ② 的地方，你注意看，這個時候的判斷條件是?value[index] == null，是判斷算出來的 index 對應的 value[] 數組對應的下標是否有值。

前面我專門強調了一句，還給你畫了一個圖：

key[] 和 values[] 這兩個數組的容量是一樣的。

為什么不先判斷該 index 在 key[] 中是否存在呢？

可以倒是可以，但是你想想如果 value[] 對應下標中的值是 null 的話，那么說明這個位置上并沒有維護過任何東西。key 和 value 的位置是一一對應的，所以根本就不用去關心 key 是否存在。

如果?value[index] == null?為 true，那么說明這個 key 之前沒有被維護過，直接把對應的值維護上，且 key[] 和 values[] 數組需要分別維護。

假設以我的演示代碼為例，第四次循環結束后是這樣的：

維護完成后，判斷一下當前的容量是否需要觸發擴容：

growSize 的代碼是這樣的：

在這個方法里面，我們可以看到 IntObjectHashMap 的擴容機制是一次擴大 2 倍。

額外說一句：這個地方就有點 low 了，源碼里面擴大二倍肯定得上位運算，用 length << 1 才對味兒嘛。

但是擴容之前需要滿足一個條件：size > maxSize

size，我們知道是表示當前 map 里面放了幾個 value 。

那么 maxSize 是啥玩意呢？

這個值在構造函數里面進行的初始化。比如在我的示例代碼中 maxSize 就等于 4：

也就是說，如果我再插入一個數據，它就要擴容了，比如我插入了第五個元素后，數組的長度就變成了 19：

前面我們討論的是?value[index] == null?為 true 的情況。那么如果是 false 呢？

就來到了標號為 ③ 的地方。

判斷 key[] 數組 index 下標處的值是否是當前的這個 key。

如果是，說明要覆蓋。先把原來該位置上的值拿出來，然后直接做一個覆蓋的操作，并返回原值，這個邏輯很簡單。

但是，如果不是這個 key 呢？

說明什么情況？

是不是說明這個 key 想要放的 index 位置已經被其他的 key 先給占領了？

這個情況是不是就是出現了 hash 沖突？

出現了 hash 沖突怎么辦？

那么就來到了標號為 ③ 的地方，看這個地方的注釋：

Conflict, keep probing ...
沖突，繼續探測 ...

繼續探測就是看當前發生沖突的 index 的下一個位置是啥。

如果讓我來寫，很簡單，下一個位置嘛，我閉著眼睛用腳都能敲出來，就是 index+1 嘛。

但是我們看看源碼是怎么寫的：

確實看到了 index+1，但是還有一個先決條件，即?index != values.length -1。

如果上述表達式成立，很簡單，采用 index+1。

如果上面的表達式不成立，說明當前的 index 是 values[] 數組的最后一個位置，那么就返回 0，也就是返回數組的第一個下標。

要觸發這個場景，就是要搞一個 hash 沖突的場景。我寫個代碼給你演示一下：

上面的代碼只有當算出來的下標為 8 的時候才會往 IntObjectHashMap 里面放東西，這樣在下標為 8 的位置就出現了 hash 沖突。

比如 100 之內，下標為 8 的數是這些：

第一次循環之后是這樣的：

而第二次循環的時候，key 是 17，它會發現下標為 8 的地方已經被占了：

所以，走到了這個判斷中：

返回 index=0，于是它落在了這個地方：

看起來就是一個環，對不對？

是的，它就是一個環。

但是你再細細的看這個判斷：

每次計算完 index 后，還要判斷是否等于本次循環的 startIndex。如果相等，說明跑了一圈了，還沒找到空位子，那么就拋出 “Unable to insert” 異常。

有的朋友馬上就跳出來了：不對啊，不是會在用了一半空間以后，以 2 倍擴容嗎？應該早就在容量滿之前就擴容了才對呀？

這位朋友，你很機智啊，你的疑問和我第一次看到這個地方的疑問是一樣的，我們都是心思縝密的好孩子。

但是注意看，在拋出異常的地方，源碼里面給了一個注釋：

Can only happen if the map was full at MAX_ARRAY_SIZE and couldn't grow.
這種情況只有 Map 已經滿了，且無法繼續擴容時才會發生。

擴容，那肯定也是有一個上限才對，再看看擴容的時候的源碼：

最大容量是 Integer.MAX_VALUE - 8，說明是有上限的。

但是，等等，Integer.MAX_VALUE 我懂，減 8 是什么情況？

誒，反正我是知道的，但是咱就是不說，不是本文重點。你要有興趣，自己去探索，我就給你截個圖完事：

如果我想要驗證一下 “Unable to insert” 怎么辦呢？

這還不簡單嗎？源碼都在我手上呢。

兩個方案，一個是修改 growSize() 方法的源碼，把最長的長度限制修改為指定值，比如 8。

第二個方案是直接嚴禁擴容，把這行代碼給它注釋了：

然后把測試用例跑起來：

你會發現在插入第 10 個值的時候，拋出了 “Unable to insert” 異常。

第 10 個值，89，就是這樣似兒的，轉一圈，又走回了 startIndex：

滿足這個條件，所以拋出異常：

(index = probeNext(index)) == startIndex

到這里，put 方法就講完了。你也了解到了它的數據結構，也了解到了它的基本運行原理。

那你還記得我寫這篇文章要追尋的問題是什么嗎?

IntObjectHashMap 性能更好的原因是什么呢？

前面提到了一個點是 key 可以使用原生的 int 類型而不用包裝的 Integer 類型。

現在我要揭示第二個點了：value 沒有一些亂七八糟的東西，value 就是一個純粹的 value。你放進來是什么，就是什么。

你想想 HashMap 的結構，它里面有個 Node，封裝了 Hash、key、value、next 這四個屬性：

這部分東西也是 IntObjectHashMap 節約出來的，而這部分節約出來的，才是占大頭的地方。

你不要看不起這一點點內存占用。在一個巨大的基數面前，任何一點小小的優化，都能被放大無數倍。

不知道你還記不記得《深入理解Java虛擬機》一書里面的這個案例：

不恰當的數據結構導致內存在占用過大。這個問題，就完全可以使用 Netty 的 LongObjectHashMap 數據結構來解決，只需要換個類，就能節省非常多的資源。

道理，是同樣的道理。

額外一個點

最后，我再給你額外補充一個我看源碼時的意外收獲。

Deletions implement compaction, so cost of remove can approach O(N) for full maps, which makes a small loadFactor recommended.
刪除實現了 compaction，所以對于一個滿了的 map 來說，刪除的成本可能接近 O(N) ，所以我們推薦使用小一點的 loadFactor。

里面有兩個單詞，compaction 和 loadFactor。

先說 loadFactor 屬性，是在構造方法里面初始化的：

為什么 loadFactor 必須是一個 (0,1] 之間的數呢？

首先要看一下 loadFactor 是在什么時候用的：

只會在計算 maxSize 的時候用到，是用當前 capacity 乘以這個系數。

如果這個系數是大于 1 的，那么最終算出來的值，也就是 maxSize 會大于 capacity。

假設我們的 loadFactor 設置為 1.5，capacity 設置為 21，那么計算出來的 maxSize 就是 31，都已經超過 capacity 了，沒啥意義。

總之：loadFactor 是用來計算 maxSize 的，而前面講了 maxSize 是用來控制擴容條件的。也就是說 loadFactor 越小，那么 maxSize 也越小，就越容易觸發擴容。反之，loadFactor 越大，越不容易擴容。loadFactor 的默認值是 0.5。

接下來我來解釋前面注釋中有個單詞 compaction，翻譯過來的話叫做這玩意：

可以理解為就是一種“壓縮”吧，但是“刪除實現了壓縮”這句話就很抽象。

不著急，我給你講。

我們先看看刪除方法：

刪除方法的邏輯有點復雜，如果要靠我的描述給你說清楚的話有點費解。

所以，我決定只給你看結果，你拿著結果去反推源碼吧。

首先，前面的注釋中說了：哥們，我推薦你使用小一點的 loadFactor。

那么我就偏不聽，直接給你把 loadFactor 拉滿到 1。

也就是說當這個 map 滿了之后，再往里面放東西才會觸發擴容。

比如，我這樣去初始化：

new IntObjectHashMap<>(8,1);

是不是說，當前這個 map 初始容量是可以放 9 個元素，當你放第 10 個元素的時候才會觸發擴容的操作。

誒，巧了，我就偏偏只想放 9 個元素，我不去觸發擴容。且我這 9 個元素都是存在 hash 沖突的。

代碼如下：

這些 value 本來都應該在下標為 8 的位置放下，但是經過線性探測之后，map 里面的數組應該是這個情況：

此時我們移除 8 這個 key，正常來說應該是這樣的：

但是實際上卻是這樣的：

會把前面因為 hash 沖突導致發生了位移的 value 全部往回移動。

這個過程，我理解就是注釋里面提到的“compaction”。

上面程序的實際輸出是這樣的：

符合我前面畫的圖片。

但是，我要說明的是，我的代碼進行了微調：

如果不做任何修改，輸出應該是這樣的：

key=8 并不在最后一個，因為在這個過程里面涉及到 rehash 的操作，如果在解釋 “compaction” 的時候加上 reHash ，就復雜了，會影響你對于 “compaction” 的理解。

另外在 removeAt 方法的注釋里面提到了這個東西：

這個算法，其實就是我前面解釋的 “compaction”。

我全局搜索關鍵字，發現在 IdentityHashMap 和 ThreadLocal 里面都提到了：

但是，你注意這個但是啊。

在 ThreadLocal 里面，用的是“unlike”。

ThreadLocal 針對 hash 沖突也用的是線性探測，但是細節處還是有點不一樣。

不細說了，有興趣的同學自己去探索一下，我只是想表達這部分可以對比學習。

這一部分的標題叫做“額外一個點”。因為我本來計劃中是沒有這部分內容的，但是我在翻提交記錄的時候看到了這個：

https://github.com/netty/netty/issues/2659

這個 issues 里面有很多討論，基于這次討論，相當于對 IntObjectHashMap 進行了一次很大的改造。

比如從這次提交記錄我可以知道，在之前 IntObjectHashMap 針對 hash 沖突用的是“雙重散列（Double hashing）”策略，之后才改成線性探測的。

包括使用較小的 loadFactor 這個建議、removeAt 里面采用的算法，都是基于這次改造出來的：

引用這個 issues 里面的一個對話：

這個哥們說：I've got carried away，我對這段代碼進行了重大改進。

在我看來，這都不算是“重大改進”了，這已經算是推翻重寫了。

另外，這個“I've got carried away”啥意思？

英語教學，雖遲但到：

這個短語要記住，托福口語考試的時候可能會考。

Netty 4.1

文章開始的地方，我說在 Netty 4.1 里面，我沒有找到 IntObjectHashMap 這個東西。

其實我是騙你的，我找到了，只是藏的有點深。

其實我這篇文章只寫了 int，但是其實基本類型都可以基于這個思想去改造，且它們的代碼都應該是大同小異的。

所以在 4.1 里面用了一個騷操作，基于 groovy 封裝了一次：

要編譯這個模板之后：

才會在 target 目錄里面看到我們想找的東西：

但是，你仔細看編譯出來的 IntObjectHashMap，又會發現一點不一樣的地方。

比如構造方法里面調整 capacity 的方法變成了這樣：

從方法名稱我們也知道這里是找一個當前 value 的最近的 2 的倍數。

等等，2 的倍數，不是一個偶數嗎？

在 4.0 分支的代碼里面，調整容量還非得要個奇數：

還記得我前面提到的一個問題嗎：我并沒有考慮明白為什么偶數的容量會破壞線性探測？

但是從這里又可以看出其實偶數的容量也是可以的嘛。

這就把我給搞懵了。

要是在 4.0 分支的代碼中，adjustCapacity 方法上沒有這一行特意寫下的注釋：

Adjusts the given capacity value to ensure that it's odd. Even capacities can break probing.

我會毫不猶豫的覺得這個地方奇偶都可以。但是他刻意強調了要“奇數”，就讓我有點拿不住了。

算了，學不動了，存疑存疑！

好了，那本文的技術部分就到這里啦。

完

往期推薦

避開10個面試大坑，接offer成功率提升至99%

噢，老天爺！ 屬于Java的協程終于來了！

6 個 Java 工具，輕松分析定位 JVM 問題！

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的一不小心节约了 591 台机器！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。