Java 鎖粗化與循環(huán)問題

1. 寫在前面

“JVM 解剖公園”是一個持續(xù)更新的系列迷你博客，閱讀每篇文章一般需要5到10分鐘。限于篇幅，僅對某個主題按照問題、測試、基準(zhǔn)程序、觀察結(jié)果深入講解。因此，這里的數(shù)據(jù)和討論可以當(dāng)軼事看，并沒有做一致性、寫作風(fēng)格、句法和語義錯誤、重復(fù)或一致性檢查。如果選擇采信文中內(nèi)容，風(fēng)險(xiǎn)自負(fù)。

Aleksey Shipilёv，JVM 性能極客

推特 @shipilev

問題、評論、建議發(fā)送到 aleksey@shipilev.net

譯注：鎖粗化（Lock Coarsening）。鎖粗化是合并使用相同鎖對象的相鄰?fù)綁K的過程。如果編譯器不能使用鎖省略（Lock Elision）消除鎖，那么可以使用鎖粗化來減少開銷。

2. 問題

眾所周知，Hotspot 確實(shí)進(jìn)行了鎖粗化優(yōu)化，可以有效合并幾個相鄰?fù)綁K，從而降低鎖開銷。能夠把下面的代碼

synchronized (obj) {
 // 語句 1
}
synchronized (obj) {
 // 語句 2
}

轉(zhuǎn)化為

synchronized (obj) {
 // 語句 1
 // 語句 2
}

問題來了，Hotspot 能否對循環(huán)進(jìn)行這種優(yōu)化？例如，把

for (...) {
 synchronized (obj) {
  // 一些操作
 }
}

優(yōu)化成下面這樣？

synchronized (this) {
 for (...) {
   // 一些操作
 }
}

理論上，沒有什么能阻止我們這樣做，甚至可以把這種優(yōu)化看作只針對鎖的優(yōu)化，像 loop unswitching 一樣。然而，缺點(diǎn)是可能把鎖優(yōu)化后變得過粗，線程在執(zhí)行循環(huán)時(shí)會占據(jù)所有的鎖。

譯注：Loop unswitching 是一種編譯器優(yōu)化技術(shù)。通過復(fù)制循環(huán)主體，在 if 和 else 語句中放一份循環(huán)體代碼，實(shí)現(xiàn)將條件句的內(nèi)部循環(huán)移到循環(huán)外部，進(jìn)而提高循環(huán)的并行性。由于處理器可以快速運(yùn)算矢量，因此執(zhí)行速度得到提升。

3. 實(shí)驗(yàn)

要回答這個問題，最簡單的辦法就是找到 Hotspot 優(yōu)化的證據(jù)。幸運(yùn)的是，有了 JMH 幫助這項(xiàng)工作變得非常簡單。JMH 不僅在構(gòu)建基準(zhǔn)測試時(shí)有用，并且在分析基準(zhǔn)測試方面同樣好用。讓我們從一個簡單的基準(zhǔn)測試開始：

@Fork(..., jvmArgsPrepend = {"-XX:-UseBiasedLocking"})
@State(Scope.Benchmark)
public class LockRoach {
  int x;
  @Benchmark
  @CompilerControl(CompilerControl.Mode.DONT_INLINE)
  public void test() {
    for (int c = 0; c < 1000; c++) {
      synchronized (this) {
        x += 0x42;
      }
    }
  }
}

（完整的源代碼參見這里 ，請查看原文鏈接）

這里有一些重要的技巧：

使用 -XX:-UseBiasedLocking 禁用偏向鎖（Biased Lock）可以避免啟動時(shí)間過長。由于偏向鎖不會立即啟動，在初始化階段要等待5秒鐘（參見 BiasedLockingStartupDelay 選項(xiàng)）
禁用 @Benchmark 方法內(nèi)聯(lián)操作可以幫助我們從反匯編中分離相關(guān)內(nèi)容
加上“魔數(shù)” 0x42 有助于快速從反匯編中定位加法操作

譯注：偏向鎖（Biased Locking）。盡管 CAS 原子指令相對于重量級鎖來說開銷比較小，但還是存在非常可觀的本地延遲，為了在無鎖競爭的情況下避免取鎖獲過程中執(zhí)行不必要的 CAS 原子指令提出了偏向鎖技術(shù)。
論文 Quickly Reacquirable Locks ，作者 Dave Dice、Mark Moir、William Scherer III。

運(yùn)行環(huán)境 i7 4790K、Linux x86_64、JDK EA 9b156：

Benchmark            Mode  Cnt      Score    Error  Units
LockRoach.test       avgt    5   5331.617 ± 19.051  ns/op

從上面運(yùn)行數(shù)據(jù)能分析出什么結(jié)果？什么都看不出來，對吧？我們需要調(diào)查背后到底發(fā)生了什么。這時(shí) -prof perfasm 配置可以派上用場，它能顯示生成代碼中的熱點(diǎn)區(qū)域。用默認(rèn)設(shè)置運(yùn)行，能夠發(fā)現(xiàn)最熱的指令是加鎖 lock cmpxchg（CAS），而且只打印指令附近的代碼。-prof perfasm:mergeMargin=1000 配置可以將這些熱點(diǎn)區(qū)域合并保存為輸出片段，乍看之下可能覺得有點(diǎn)恐怖。

進(jìn)一步分析得出連續(xù)的跳轉(zhuǎn)指令是鎖定或解鎖，注意循環(huán)次數(shù)最多的代碼（第一列），可以看到最熱的循環(huán)像下面這樣：

↗ 0x00007f455cc708c1: lea  0x20(%rsp),%rbx
 │     < 省略若干代碼，進(jìn)入 monitor >   ; <--- coarsened（粗化）!
 │ 0x00007f455cc70918: mov  (%rsp),%r10    ; 加載 $this
 │ 0x00007f455cc7091c: mov  0xc(%r10),%r11d  ; 加載 $this.x
 │ 0x00007f455cc70920: mov  %r11d,%r10d    ; ...hm...
 │ 0x00007f455cc70923: add  $0x42,%r10d    ; ...hmmm...
 │ 0x00007f455cc70927: mov  (%rsp),%r8     ; ...hmmmmm!...
 │ 0x00007f455cc7092b: mov  %r10d,0xc(%r8)   ; LOL Hotspot，冗余存儲，下面省略兩行
 │ 0x00007f455cc7092f: add  $0x108,%r11d    ; 加 0x108 = 0x42 * 4 <-- 展開4次
 │ 0x00007f455cc70936: mov  %r11d,0xc(%r8)   ; 把 $this.x 回省略若干代碼，退出 monitor >   ; <--- coarsened（粗化）!
 │ 0x00007f455cc709c6: add  $0x4,%ebp     ; c += 4  <--- 展開4次
 │ 0x00007f455cc709c9: cmp  $0x3e5,%ebp    ; c < 1000?
 ╰ 0x00007f455cc709cf: jl   0x00007f455cc708c1

哈哈。循環(huán)似乎被展開了4次，然后這4個迭代中實(shí)現(xiàn)鎖粗化！為了排除循環(huán)展開對鎖粗化的影響，我們可以通過-XX:LoopUnrollLimit=1 配置裁剪循環(huán)展開，再次量化受限后的粗化性能。

譯注：Loop unrolling（循環(huán)展開），也稱 Loop unwinding，是一種循環(huán)轉(zhuǎn)換技術(shù)。它試圖以犧牲二進(jìn)制大小為代價(jià)優(yōu)化程序的執(zhí)行速度，這種方法被稱為時(shí)空折衷。轉(zhuǎn)換可以由程序員手動執(zhí)行，也可以由編譯器優(yōu)化。

Benchmark      Mode Cnt   Score  Error Units
# Default
LockRoach.test    avgt  5  5331.617 ± 19.051 ns/op
# -XX:LoopUnrollLimit=1
LockRoach.test    avgt  5 20679.043 ± 3.133 ns/op

哇，性能提升了4倍！顯而易見的，因?yàn)槲覀円呀?jīng)觀察到最熱的指令是加鎖 lock cmpxchg。當(dāng)然，4倍后的粗化鎖意味著4倍吞吐量。非?？幔覀兪遣皇强梢孕汲晒?，然后繼續(xù)前進(jìn)？還沒有。我們必須驗(yàn)證禁用循環(huán)展開真正提供了我們想要進(jìn)行比較的內(nèi)容。perfasm 的結(jié)果似乎表明它含有類似的熱點(diǎn)循環(huán)，只是跨了一大步。

↗ 0x00007f964d0893d2: lea  0x20(%rsp),%rbx
 │     < 省略若干代碼，進(jìn)入 monitor >
 │ 0x00007f964d089429: mov  (%rsp),%r10    ; 加載 $this
 │ 0x00007f964d08942d: addl  $0x42,0xc(%r10)  ; $this.x += 0x42
 │     < 省略若干代碼，退出 monitor >
 │ 0x00007f964d0894be: inc  %ebp        ; c++
 │ 0x00007f964d0894c0: cmp  $0x3e8,%ebp    ; c < 1000?
 ╰ 0x00007f964d0894c6: jl   0x00007f964d0893d2 ;

一切都檢查 OK。

4. 觀察結(jié)果

當(dāng)鎖粗化在整個循環(huán)中不起作用時(shí)，一旦中間看起來好像存在 N 個相鄰的加鎖解鎖操作，另一種循環(huán)優(yōu)化——循環(huán)展開會提供常規(guī)鎖粗化。這將提高性能，并有助于限制粗化的范圍，以避免長循環(huán)過度粗化。

總結(jié)

以上所述是小編給大家介紹的Java 鎖粗化與循環(huán)問題,希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時(shí)回復(fù)大家的。在此也非常感謝大家對億速云網(wǎng)站的支持！

如果你覺得本文對你有幫助，歡迎轉(zhuǎn)載，煩請注明出處，謝謝！