你好呀,我是歪歪。
前段時間,我在 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.
我會毫不猶豫的覺得這個地方奇偶都可以。但是他刻意強調了要“奇數”,就讓我有點拿不住了。
算了,學不動了,存疑存疑!
文章首發於公眾號[why技術],歡迎大家關注,第一時間看到最新文章。