國慶的時候閑來無事，就隨手寫了一點之前說的比賽的代碼，目標(biāo)就是保住前 100 混個大賽的文化衫就行了。現(xiàn)在還混在前 50 的隊伍里面，穩(wěn)的一比。
其實我覺得大家做柔性負(fù)載均衡那題的思路其實都不會差太多，就看誰能把關(guān)鍵的信息收集起來并利用上了。由于是基于 Dubbo 去做的嘛，調(diào)試的過程中，寫著寫著我看到了這個地方：
org.apache.dubbo.rpc.protocol.AbstractInvoker#waitForResultIfSync 先看我框起來的這一行代碼，aysncResult 的里面有有個 CompletableFuture ，它調(diào)用的是帶超時時間的 get() 方法，超時時間是 Integer.MAX_VALUE，理論上來說效果也就等同于 get() 方法了。
從我直觀上來說，這里用 get() 方法也應(yīng)該是沒有任何毛病的，甚至更好理解一點。 但是，為什么沒有用 get() 方法呢？其實方法上的注釋已經(jīng)寫到原因了，就怕我這樣的人產(chǎn)生了這樣的疑問：
抓住我眼球的是這這幾個單詞：have serious performance drop。
性能嚴(yán)重下降。 大概就是說我們必須要調(diào)用
java.util.concurrent.CompletableFuture#get(long, java.util.concurrent.TimeUnit) 而不是 get() 方法，因為 get 方法被證明會導(dǎo)致性能嚴(yán)重的下降。對于 Dubbo 來說， waitForResultIfSync 方法，是主鏈路上的方法。我個人覺得保守一點說，可以說 90% 以上的請求都會走到這個方法來，阻塞等待結(jié)果。所以如果該方法如果有問題，則會影響到 Dubbo 的性能。
Dubbo 作為中間件，有可能會運行在各種不同的 JDK 版本中，對于特定的 JDK 版本來說，這個優(yōu)化確實是對于性能的提升有很大的幫助。 就算不說 Dubbo ，我們用到 CompletableFuture 的時候，get() 方法也算是我們常常會用到的一個方法。另外，這個方法的調(diào)用鏈路我可太熟悉了。因為我兩年前寫的第一篇公眾號文章就是探討 Dubbo 的異步化改造的。當(dāng)年，這部分代碼肯定不是這樣的，至少沒有這個提示。因為如果有這個提示的話，我肯定第一次寫的時候就注意到了。果然，我去翻了一下，雖然圖片已經(jīng)很模糊了，但是還是能隱約看到，之前確實是調(diào)用的 get() 方法：
我還稱之為最“騷”的一行代碼。
因為這一行的代碼就是 Dubbo 異步轉(zhuǎn)同步的關(guān)鍵代碼。
前面只是一個引子，本文不會去寫 Dubbo 相關(guān)的知識點。主要寫寫 CompletableFuture 的 get() 到底有啥問題。
放心，這個點面試肯定不考。 只是你知道這個點后，恰好你的 JDK 版本是沒有修復(fù)之前的，寫代碼的時候可以稍微注意一下。學(xué) Dubbo 在方法調(diào)用的地方加上一樣的 NOTICE，直接把逼格拉滿。等著別人問起來的時候，你再娓娓道來。或者不經(jīng)意間看到別人這樣寫的時候，輕飄飄的說一句：這里有可能會有性能問題，可以去了解一下。
啥性能問題？ 根據(jù) Dubbo 注釋里面的這點信息，我也不知道啥問題，但是我知道去哪里找問題。這種問題肯定在 openJDK 的 bug 列表里面記錄有案，所以第一站就是來這里搜索一下關(guān)鍵字：
https://bugs.openjdk.java.net/projects/JDK/issues/ 一般來說，都是一些陳年老 BUG，需要搜索半天才能找到自己想要的信息。但是，這次運氣好到爆棚，彈出來的第一個就是我要找的東西，簡直是搞的我都有點不習(xí)慣了，這難道是傳說中的國慶獻(xiàn)禮嗎，不敢想不敢想。
標(biāo)題就是：對CompletableFuture的性能改進(jìn)。里面提到了編號為 8227019 的 BUG。
https://bugs.openjdk.java.net/browse/JDK-8227019 我們一起看看這個 BUG 描述的是啥玩意。
標(biāo)題翻譯過來，大概意思就是說 CompletableFuture.waitingGet 方法里面有一個循環(huán)，這個循環(huán)里面調(diào)用了 Runtime.availableProcessors 方法。且這個方法被調(diào)用的很頻繁，這樣不好。在詳細(xì)描述里面，它提到了另外的一個編號為 8227006 的 BUG，這個 BUG 描述的就是為什么頻繁調(diào)用 availableProcessors 不太好，但是這個我們先按下不表。先研究一下他提到的這樣一行代碼：
?spins?=?(Runtime.getRuntime().availableProcessors()?>?1)??他說位于 waitingGet 里面，我們就去看看到底是怎么回事嘛。但是我本地的 JDK 的版本是 1.8.0_271，其 waitingGet
源碼 是這樣的：
java.util.concurrent.CompletableFuture#waitingGet 先不管這幾行代碼是啥意思吧，反正我發(fā)現(xiàn)沒有看到 bug 中提到的代碼，只看到了
spins=SPINS ，雖然 SPINS 調(diào)用了
Runtime.getRuntime().availableProcessors() 方法，但是該字段被 static 和 final 修飾了，也就不存在 BUG 中描述的“頻繁調(diào)用”了。于是我意識到我的版本是不對的，這應(yīng)該是被修復(fù)之后的代碼，所以去下載了幾個之前的版本。最終在 JDK 1.8.0_202 版本中找到了這樣的代碼：
和前面截圖的源碼的差異就在于前者多了一個 SPINS 字段，把
Runtime.getRuntime().availableProcessors() 方法的返回緩存了起來。我一定要找到這行代碼的原因就是要證明這樣的代碼確實是在某些 JDK 版本中出現(xiàn)過。好了，現(xiàn)在我們看一下 waitingGet 方法是干啥的。首先，調(diào)用 get() 方法的時候，如果 result 還是 null 那么說明異步線程執(zhí)行的結(jié)果還沒就緒，則調(diào)用 waitingGet 方法：
而來到 waitingGet 方法，我們只關(guān)注 BUG 相關(guān)這兩個分支判斷：
首先把 spins 的值初始化為 -1。然后當(dāng) result 為 null 的時候，就一直進(jìn)行 while 循環(huán)。所以，如果進(jìn)入循環(huán)，第一次一定會調(diào)用 availableProcessors 方法。然后發(fā)現(xiàn)是多處理器的運行環(huán)境，則把 spins 置為 1<<8 ，即 256。然后再次進(jìn)行循環(huán)，走入到 spins>0 的分支判斷，接著做一個隨機運算，隨機出來的值如果大于等于 0 ，則對 spins 進(jìn)行減一操作。只有減到 spins 為 0 的時候才會進(jìn)入到后面的這些被我框起來的邏輯中：
也就是說這里就是把 spins 從 256 減到 0，且由于隨機函數(shù)的存在，循環(huán)次數(shù)一定是大于 256 次的。但是還有一個大前提，那就是每次循環(huán)的時候都會去判斷循環(huán)條件是否還成立。即判斷 result 是否還是 null。為 null 才會繼續(xù)往下減。所以，你說這段代碼是在干什么事兒？其實注釋上已經(jīng)寫的很清楚了：
Use brief spin-wait on multiprocessors。brief，這是一個四級詞匯哈，得記住，要考的。就是“短暫”的意思，是一個不規(guī)則動詞，其最高級是 briefest。對了，spin 這個單詞大家應(yīng)該認(rèn)識吧，前面忘記給大家教單詞了，就一起講了，看小黑板：
所以注釋上說的就是：如果是多處理器，則使用短暫的自旋等待一下。從 256 減到 0 的過程，就是這個“brief spin-wait”。但是仔細(xì)一想，在自旋等待的這個過程中，availableProcessors 方法只是在第一次進(jìn)入循環(huán)的時候調(diào)用了一次。那為什么說它耗費性能呢？
是的，確實是調(diào)用 get() 方法的只調(diào)用了一次，但是你架不住 get() 方法被調(diào)用的次數(shù)多啊。 就拿 Dubbo 舉例，絕大部分情況下的大家的調(diào)用方式都用的是默認(rèn)的同步調(diào)用的方案。所以每一次調(diào)用都會到異步轉(zhuǎn)同步這里阻塞等待結(jié)果，也就說每次都會調(diào)用一次 get() 方法，即 availableProcessors 方法就會被調(diào)用一次。那么解決方案是什么呢？在前面我已經(jīng)給大家看了，就是把 availableProcessors 方法的返回值找個字段給緩存起來：
但是后面跟了一個“problem”。這個“problem”就是說如果我們把多處理器這個值緩存起來了，假設(shè)程序運行的過程中出現(xiàn)了從多處理器到單處理器的運行環(huán)境變化這個值就不準(zhǔn)確了，雖然這是一個不太可能的變化。但是即使這個“problem”真的發(fā)生了也沒有關(guān)系，它只是會導(dǎo)致一個小小的性能損失。所以就出現(xiàn)了前面大家看到的這樣的代碼，這就是 “we can cache this value in a field”：
而體現(xiàn)到具體的代碼變更是這樣的：
http://cr.openjdk.java.net/~shade/8227018/webrev.01/src/share/classes/java/util/concurrent/CompletableFuture.java.udiff.html 所以，當(dāng)你去看這部分源碼的時候，你會看到 SPINS 字段上其實還有很長一段話，是這樣的：
給大家翻譯一下：1.在 waitingGet 方法中，進(jìn)行阻塞操作前，進(jìn)行旋轉(zhuǎn)。2.沒有必要在單處理器上進(jìn)行旋轉(zhuǎn)。3.調(diào)用 Runtime.availableProcessors 方法的成本是很高的，所以在此緩存該值。但是這個值是首次初始化時可用的 CPU 的數(shù)量。如果某系統(tǒng)在啟動時只有一個 CPU 可以用，那么 SPINS 的值會被初始化為 0，即使后面再使更多的 CPU 在線，也不會發(fā)生變化。
當(dāng)你有了前面的 BUG 的描述中的鋪墊之后，你就明白了為什么這里寫上了這么一大段話。 有的同學(xué)就真的去翻代碼，也許你看到的是這樣的：
什么情況？根本就看不到 SPINS 相關(guān)的代碼啊，這不是欺騙老實人嗎？
你別慌啊，猴急猴急的，我這不是還沒說完嘛？
我們再把目光放到圖片中的這句話上：
只需要在 JDK 8 中進(jìn)行這個修復(fù)即可，因為 JDK 9 和更高版本的代碼都不是這樣的寫的了。比如在 JDK 9 中，直接拿掉了整個 SPINS 的邏輯，不要這個短暫的自旋等待了：
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f3af17da360b 雖然，拿掉了這個短暫的自旋等待，但是其實也算是學(xué)習(xí)了一個騷操作。
比如怎么在不引入時間的前提下，做出一個自旋等待的效果？ 答案就是被拿掉的這段代碼。但是有一說一，我第一次看到這個代碼的時候我就覺得別扭。這一個短短的自旋能延長多少時間呢？加入這個自旋，是為了稍晚一點執(zhí)行后續(xù)邏輯中的 park 代碼，這個稍重一點的操作。但是我覺得這個 “brief spin-wait” 的收益其實是微乎其微的。所以我也理解為什么后續(xù)直接把這一整坨代碼拿掉了。而拿掉這一坨代碼的時候，其實作者并沒有意識到這里有 BUG。這里提到的作者，其實就是 Doug Lea 老爺子。我為什么敢這樣說呢？那必然是有證據(jù)的呀。
依據(jù)就在這個 BUG 鏈接里面提到的編號為 8227018 的 BUG 中，它們其實描述的是同一個事情：
這里面有這樣一段對話，出現(xiàn)了 David Holmes 和 Doug Lea：
Holmes 在這里面提到了 “cache this value in a field” 的解決方案，并得到了 Doug 的同意。
Doug 說：JDK 9 已經(jīng)不用 spin 了。 所以，我個人理解是 Doug 在不知道這個地方有 BUG 的情況下，拿掉了 SPIN 的邏輯。至于是出于什么考慮，我猜測是收益確實不大，且代碼具有一定的迷惑性。還不如拿掉之后，理解起來直觀一點。Doug Lea 大家都耳熟能詳， David Holmes 是誰呢？
《Java 并發(fā)編程實戰(zhàn)》的作者之一，端茶就完事了。
而你要是對我以前的文章印象足夠深刻，那么你會發(fā)現(xiàn)早在《Doug Lea在J.U.C包里面寫的BUG又被網(wǎng)友發(fā)現(xiàn)了。》這篇文章里面，他就已經(jīng)出現(xiàn)過了：
老朋友又出現(xiàn)了，建議鐵汁們把夢幻聯(lián)動打在公屏上。
到底啥原因？ 前面噼里啪啦的說了這么大一段，核心思想其實就是 Runtime.availableProcessors 方法的調(diào)用成本高，所以在 CompletableFuture.waitingGet 方法中不應(yīng)該頻繁調(diào)用這個方法。但是 availableProcessors 為什么調(diào)用成本就高了，依據(jù)是啥，得拿出來看看??！這一小節(jié)，就給大家看看依據(jù)是什么。依據(jù)就在這個 BUG 描述中：
https://bugs.openjdk.java.net/browse/JDK-8157522 標(biāo)題上說：在 linux 環(huán)境下，Runtime.availableProcessors 執(zhí)行時間增加了 100 倍。增加了 100 倍，肯定是有兩個不同的版本的對比，那么是哪兩個版本呢？
在 1.8b191 之前的 JDK 版本上，下面的示例程序可以實現(xiàn)每秒 400 多萬次對 Runtime.availableProcessors 的調(diào)用。但在 JDK build 1.8b191 和所有后來的主要和次要版本（包括11）上，它能實現(xiàn)的最大調(diào)用量是每秒4萬次左右，性能下降了100倍。這就導(dǎo)致了 CompletableFuture.waitingGet 的性能問題，它在一個循環(huán)中調(diào)用了 Runtime.availableProcessors。因為我們的應(yīng)用程序在異步代碼中表現(xiàn)出明顯的性能問題，waitingGet 就是我們最初發(fā)現(xiàn)問題的地方。測試代碼是這樣的：
??public?static?void?main(String[]?args)?throws?Exception?{while ?(!stop.get())?{while ?(true )?{"%s?calls/sec%n" ,?thisCount?-?lastCount);true );按照 BUG 提交者的描述，如果你在 64 位的 Linux 上，分別用 JDK 1.8b182 和 1.8b191 版本去跑，你會發(fā)現(xiàn)有近 100 倍的差異。 至于為什么有 100 倍的性能差異，一位叫做 Fairoz Matte 的老哥說他調(diào)試了一下，定位到問題出現(xiàn)在調(diào)用 “OSContainer::is_containerized()” 方法的時候：
而且他也定位到了問題出現(xiàn)的最開始的版本號是 8u191 b02，在這個版本之后的代碼都會有這樣的問題。 帶來問題的那次版本升級干的事是改進(jìn) docker 容器檢測和資源配置的使用。所以，如果你的 JDK 8 是 8u191 b02 之前的版本，且系統(tǒng)調(diào)用并發(fā)非常高，那么恭喜你，有機會踩到這個坑。然后，下面幾位大佬基于這個問題給出了很多解決方案，并針對各種解決方案進(jìn)行討論。有的解決方案，聽起來就感覺很麻煩，需要編寫很多的代碼，我就不一一解讀了。最終，大道至簡，還是選擇了實現(xiàn)起來比較簡單的 cache 方案，雖然這個方案也有一點瑕疵，但是出現(xiàn)的概率非常低且是可以接受的。
再看get方法 現(xiàn)在我們知道了這個沒有卵用的知識點之后，我們再看看為什么調(diào)用帶超時時間的 get() 方法，沒有這個問題。
java.util.concurrent.CompletableFuture#get(long, java.util.concurrent.TimeUnit) 首先可以看到內(nèi)部調(diào)用的方法都不一樣了：
有超時時間的 get() 方法，內(nèi)部調(diào)用的是 timedGet 方法，入?yún)⒕褪浅瑫r時間。點進(jìn) timedGet 方法就知道為什么調(diào)用帶超時時間的 get() 方法沒有問題了：
在代碼的注釋里面已經(jīng)把答案給你寫好了：我們故意不在這里旋轉(zhuǎn)（像waitingGet那樣），因為上面對 nanoTime() 的調(diào)用很像一個旋轉(zhuǎn)。可以看到在該方法內(nèi)部，根本就沒有對 Runtime.availableProcessors 的調(diào)用，所以也就不存在對應(yīng)的問題。現(xiàn)在，我們回到最開始的地方：
那么你說，下面的
asyncResult.get(Integer.MAX_VALUE, TimeUnit.MILLISECONDS) 如果我們改成
asyncResult.get() 效果還是一樣的嗎？肯定是不一樣的。再說一次：Dubbo 作為開源的中間件，有可能會運行在各種不同的 JDK 版本中，且該方法是它主鏈路上的核心代碼，對于特定的 JDK 版本來說，這個優(yōu)化確實是對于性能的提升有很大的幫助。所以寫中間件還是有點意思哈。最后，再送你一個為 Dubbo 提交源碼的機會。在其下面的這個類中：
org.apache.dubbo.rpc.AsyncRpcResult 還是存在這兩個方法：
但是上面的 get() 方法只有測試類在調(diào)用了：
完全可以把它們?nèi)扛牡粽{(diào)用 get(long timeout, TimeUnit unit) 方法，然后把 get() 方法直接刪除了。我覺得肯定是能被 merge 的。如果你想為開源項目做貢獻(xiàn)，熟悉一下流程，那么這是一個不錯的小機會。被 merge 后你就可以去吹牛了，畢竟是為 Apache 頂級開源項目貢獻(xiàn)過
源碼 的人，說話音調(diào)都可以加高點。
好了，本文的技術(shù)部分就到這里啦。下面這個環(huán)節(jié)叫做[荒腔走板]，技術(shù)文章后面我偶爾會記錄、分享點生活相關(guān)的事情，和技術(shù)毫無關(guān)系。我知道看起來很突兀，但是我喜歡，因為這是一個普通博主的生活氣息。
下載文檔
