1. 編譯閾值

1.1. 一旦代碼執行到一定次數，就達到了它的編譯閾值，編譯器就會認為它有足夠的信息來編譯代碼

1.2. 在當前的JVM中，優化閾值的意義不大

1.2.1. 從JDK 7以及更早期遺留下來的

1.3. -XX:CompileThreshold=N

1.3.1. 當禁用分層編譯時有效

1.3.2. 預設值是10 00

1.3.3. 降低這個標誌的值可以改善使用C2編譯器的應用程式的啟動時間

1.3.3.1. 可能會導致一些方法被編譯，而這些方法本來是永遠都不會被編譯的

1.4. 編譯器使用的計數器會隨著方法和迴圈的執行增加計數，但是它們也會隨著時間的推移而減少

1.4.1. 計數器只是方法或迴圈最近熱度的相對度量

1.4.2. 有些頻繁執行的代碼可能永遠不會被C2編譯器編譯，即使這個程式永遠運行

1.5. -XX:Tier3InvocationThreshold=N

1.5.1. 預設值200

1.5.2. 讓C1編譯器更快地編譯方法

1.6. -XX:Tier4InvocationThreshold=N

1.6.1. 預設值5000

1.6.2. 讓C2編譯器更快地編譯方法

2. 編譯線程

2.1. 調用次數更多的方法有更高的優先順序

2.1.1. 可以確保最重要的方法先被編譯

2.2. 需要編譯的代碼會放在編譯隊列中

2.2.1. 隊列中的代碼越多，應用程式達到最佳性能需要的時間就越長

2.3. C1編譯器和C2編譯器有不同的隊列

2.3.1. 對於放在編譯隊列中的方法，編譯是非同步進行的

2.4. -XX:CICompilerCount=N

2.4.1. JVM用來處理隊列的匯流排程數

2.4.2. 三分之一（至少一個）用來處理C1編譯器隊列

2.4.3. 剩下的線程（也是至少一個）用來處理C2編譯器隊列

2.4.4. 如果分層編譯被禁用，則只啟動給定數量的C2編譯器線程

2.5. 在Docker容器中運行舊版本的JDK 8會導致自動優化出問題

2.5.1. 需要手動將此標誌設置為需要的值

2.6. 可用的CPU有限，較少的線程競爭系統資源對性能有益

2.6.1. 減少線程數量可以幫助提升整體吞吐量

2.6.2. 代價是預熱期會持續更長時間

2.7. -XX:+BackgroundCompilation

2.7.1. 預設值為true

2.7.1.1. 意味著隊列會進行非同步處理

2.7.2. 設置為false

2.7.2.1. 一旦方法可以被編譯，想要執行它的代碼就會等待，直到方法實際上完成編譯，而不是繼續在解釋器中執行

2.8. -Xbatch

2.8.1. 可以禁用後臺編譯

3. 內聯

3.1. 對性能提升非常重要

3.1.1. 編譯器能做的最有利的優化，特別是對於屬性封裝良好的面向對象代碼

3.1.2. 不要害怕小方法，特別是getter和setter，因為它們很容易被內聯

3.2. -XX:-Inline

3.2.1. 預設啟用

3.3. -XX:MaxFreqInlineSize=N

3.3.1. 頻繁內聯

3.3.2. 預設325位元組

3.3.3. 一個方法因為調用得很頻繁而可以被內聯，那麼只有在它的位元組碼小於325位元組時

3.4. -XX:MaxInlineSize=N

3.4.1. 正常內聯

3.4.2. 預設35位元組

3.4.3. 只有在位元組碼小於35位元組時，方法才會被內聯

3.4.4. 它可能會縮短測試所需的預熱時間，但是不太可能對一個長期運行的應用程式產生很大影響

3.5. 註意事項

3.5.1. 將MaxInlineSize的值設置為大於35位元組，意味著一個方法在首次調用時可能就被內聯了

3.5.2. 如果方法經常被調用，就說明它的性能重要得多，它總歸是會被內聯的（假設它小於325位元組）

4. 逃逸分析

4.1. 編譯器能夠進行的最複雜的優化

4.1.1. 常導致微基準測試出錯

4.1.2. 可以產生更快的代碼，但複雜迴圈結構和大型方法限制了有效性

4.2. -XX:+DoEscapeAnalysis

4.2.1. 預設值是true

4.2.2. C2編譯器會進行大幅度的優化

4.2.3. 在極少數情況下，它會出錯

4.2.4. 禁用這個特性可能會帶來更穩定的代碼