這是以前的文章（第3部分，共1部分）的繼續：有關性能調優，Java中的JVM，GC，Mechanical Sympathy等的文章和視頻的提要 。

事不宜遲，讓我們開始使用我們的下一組博客和視頻，印章……印章……！ 這次是Martin Thompson的博客文章和討論。 馬丁關于Java垃圾收集的第一篇文章基本上是精簡了GC流程及其底層組件，其中包括對許多有趣的GC標志（ -XX：… ）投光。 在他的下一次演講中，他講述了機械同情，人們正確相信的東西以及誤解的神話。 在性能測試的討論中，Martin進一步完善了Java，OS和硬件的融合，以展示對所有這些方面的理解如何有助于編寫更好的程序。

Martin Thompson

標志太多，無法調整GC以實現應用程序所需的吞吐量和延遲。 關于鈴鐺和口哨聲的細節有很多文檔，但是沒有文檔可以指導您完成這些操作。

權衡

吞吐量（ -XX：GCTimeRatio = 99 ），延遲（ -XX：MaxGCPauseMillis = <n> ）和內存（ -Xmx <n> ）是收集器所依賴的關鍵變量。 重要的是要注意，熱點通常無法實現上述目標。 如果低延遲應用程序幾秒鐘沒有響應，則可能會造成災難。 權衡取舍

• 為GC算法提供更多內存
• 可以通過包含活動集并減小堆大小來減少GC
• 通過管理堆和生成大小以及控制應用程序的對象分配率，可以減少暫停的頻率
• 可以通過同時運行GC來減少大暫停的頻率

對象壽命

GC算法通常經過優化，期望大多數對象的生存期很短，而很少有對象生存期很長。 實驗表明，與非代垃圾收集器相比，代垃圾收集器支持的吞吐量要好得多，因此可以在服務器JVM中使用。

世界停止活動

為了使GC發生，有必要使正在運行的應用程序的所有線程都必須暫停–垃圾收集器通過發信號通知線程在到達安全點時停止來實現此目的。 到達安全點的時間是低延遲應用程序中的重要考慮因素，除了其他GC標志外，還可以使用?XX：+ PrintGCApplicationStoppedTime標志來找到安全點時間。
當發生STW事件時，隨著線程從安全點釋放時恢復，系統將承受很大的調度壓力，因此更少的 STW會使應用程序更高效。

熱點堆組織

Java堆被劃分為多個區域，在伊甸園中創建了一個對象，并將其移入幸存者空間，并最終移交給了有期限的人。 PermGen用于存儲運行時對象，例如類和靜態字符串。 收集器利用虛擬空間來滿足吞吐量和延遲目標，并調整區域大小以達到目標。

對象分配

TLAB（線程本地分配緩沖區）用于在Java中分配對象，這比使用malloc便宜（在大多數平臺上需要10條指令）。 次要收集率與對象分配率成正比。 大型對象（ -XX：PretenureSizeThreshold = n ）可能必須在Old Gen中分配，但是如果將閾值設置為低于TLAB大小，則將不會在Old gen中創建它們-（請注意）不適用于G1 收集器 。

小型收藏

當Eden變滿時，將進行次要收集，一旦對象變舊，即超過閾值（ -XX：MaxTenuringThreshold ），對象就會從eden提升到占位空間 。 在次要收集中，將具有已知GC根的活動的可到達對象復制到幸存者空間。 熱點使用卡片表維護跨代引用。 因此，老一代的規模也是次要收藏成本的一個因素。 通過將Eden的大小調整為要提升的對象數，可以提高收集效率。 這些很容易發生STW，因此在最近時期成問題。

主要收藏

主要藏品收集了老一代，以便可以推廣年輕一代的物品。 收集器跟蹤舊一代的填充閾值，并在超過閾值時開始收集。 為避免升級失敗，您將需要調整舊版本允許容納升級的填充（ -XX：PromotedPadding = <n> ）。 使用– Xms和-Xmx標志可以避免堆大小調整。 老一代的壓縮會導致應用程序可能遇到的最大STW暫停之一，并直接與老一代中的活動對象數量成比例。 通過調整幸存者空間的大小和任期閾值，可以更慢地填補保有權空間，但這又會導致更長的次要收集暫停時間，這是因為幸存者空間之間的復制成本增加。

串行收集器

它是具有最小占用空間（ -XX：+ UseSerialGC ）的最簡單的收集器，并且對次要和主要收集都使用單個線程。

并聯收集器

有兩種形式（ -XX：+ UseParallelGC ）和（ -XX：+ UseParallelOld GC ），對于次要集合使用多個線程，對于主要集合使用單個線程-因為Java 7u4對這兩種類型的集合都使用多個線程。 Parallel Old在多處理器系統上的性能非常好，適用于批處理應用程序。 提供更多的內存，更大但更少的收集暫停可以幫助此收集器。 根據您的應用程序可以承受的暫停時間，在Parallel Old和Concurrent收集器之間進行權衡（在壓縮舊一代后，現代硬件上每GB實時數據的暫停時間應為1到5秒）。

并發標記掃描（CMS）收集器

CMS（ -XX：+ UseConcMarkSweepGC ）收集器在舊版本中運行，以收集在大型收集期間不再可訪問的使用期限對象。 CMS不是壓縮收集器，隨著時間的推移會導致Old gen的碎片化。 當較大的對象無法放入Old gen時，升級失敗將觸發FullGC。 CMS與您的應用程序一起運行會占用CPU時間。 CMS如果無法以足夠的速度跟上升級的速度，就會遭受“并發模式故障”。

垃圾優先（G1）收集器

G1（ -XX：+ UseG1GC ）是Java 6中引入的新收集器，現已在Java 7中得到正式支持。它是具有部分并發收集算法的分代收集器，它以較小的增量STW暫停壓縮了Old gen。 它將堆劃分為可變大小的固定大小區域。 G1是由延遲驅動的目標驅動器（ –XX：MaxGCPauseMillis = <n> ，默認值= 200ms）。 在龐大的地區收集物品可能會非常昂貴。 它使用“記憶集”來跟蹤對其他區域對象的引用。 記賬和維護“記憶套”涉及很多成本。 與CMS相似，G1可能會發生疏散失敗（空間溢出）。

替代并行收集器

Oracle JRockit Real Time，IBM Websphere Real Time和Azul Zing是替代的并發收集器。 根據作者的說法，Zing是唯一在收集，壓縮之間保持平衡的Java收集器，并為所有世代??保持高吞吐量。 不論堆大小如何，在所有階段（包括次要回收期間），Zing都是并行的。 對于所有針對延遲的并發收集器，您必須放棄吞吐量并增加占用空間。 堆大小的預算至少為有效設置的活動集的2到3倍。

垃圾收集監控和調整

始終啟用以收集最佳GC詳細信息的重要標志：

-verbose:gc -Xloggc:<filename> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime

使用Chewiebug ， JVisualVM之類的應用程序（帶有Visual GC插件）來研究由于GC動作導致的應用程序行為。 運行可以重復執行的代表性負載測試（當您了解各種收集器時），繼續嘗試不同的配置，直到達到吞吐量和延遲目標。 jHiccup幫助跟蹤JVM中的暫停。 我們都知道，要在等待時間要求，高對象分配和提升率之間取得平衡，這是一個艱巨的挑戰，有時選擇商業解決方案來實現這一目標可能是一個更明智的想法。

結論： GC本身就是一個很大的主題，它包含許多組件，其中一些組件不斷被替換，因此重要的是要知道每個組件代表什么。 GC標志與其相關的組件同樣重要，并且了解它們以及如何使用它們也很重要。 啟用某些標準GC標志來記錄GC日志不會對JVM的性能產生任何重大影響。 只要您遵循作者的方法，就可以使用第三方免費軟件或商業工具。

—多次閱讀該文章，因為Martin涵蓋了許多有關GC和收集器的細節，需要仔細檢查并充分理解。 -

馬丁·湯普森（Martin Thompson）：神話般的現代硬件獲得“機械同情”

他將神話分為三類- 可能的 ， 合理的和失敗的 ！ 為了充分利用您擁有的硬件，您需要了解硬件。 進行權衡，改變旋鈕，這并不像您想的那樣可怕。

好問題：普通開發人員是否了解他們編程的硬件？ 還是不知道發生了什么？ 還是我們有紀律并努力了解我們使用的平臺？

神話1

CPU并沒有變得越來越快–時鐘速度還不是全部，Sandy Bridge體系結構才是更快的品種。 6個端口支持并行（6個操作/周期）。 Haswell有8個端口！ 代碼除法運算的執行速度比任何其他算術運算都要慢。 CPU具有前端和后端周期。 隨著我們更快地喂食它們，它變得越來越快– 可能

神話2

內存為我們提供了隨機訪問權限 -CPU寄存器和緩沖區，內部緩存（L1，L2，L3）和內存-分別以對這些區域的訪問速度增加的順序提到。 CPU一直在通過執行直接訪問操作來降低其運行溫度。 寫比讀少麻煩-緩沖區丟失代價高昂。 L1被組織為包含處理器將執行的代碼的高速緩存行–通過沒有高速緩存行未命中來提高效率。 預取器有助于減少延遲，并有助于讀取流和可預測的數據。 TLB丟失也可以提高成本效益（4K =內存頁面大小）。 簡而言之，由于底層硬件的工作方式，讀取內存并非接近隨機讀取，而是逐次讀取。 編寫高度分支的代碼可能會導致程序執行速度變慢–將具有凝聚力的內容放在一起是提高效率的關鍵。 – 破產

注意： TLAB和TLB是兩個不同的概念！

神話3

HDD提供了隨機訪問權限–旋轉的磁盤和手臂在讀取數據時移動。 與內部軌道（區域位記錄）相比，外部軌道中放置的扇區更多。 更快地旋轉光盤并不是提高HDD性能的方法。 最小讀寫量為4K。 最佳光盤中的搜索時間為3-6毫秒，筆記本電腦驅動器的速度較慢（15毫秒）。 旋轉延遲需要一些時間。 數據傳輸需要100-220 MB /秒。 添加緩存可以改善將數據寫入磁盤的功能，而不能改善從磁盤讀取數據的速度。 – 破產

神話4

SSD提供隨機訪問–讀寫很棒，工作非常快（一次4K）。 刪除與真正的刪除不同，它被標記為已刪除而不是真正被刪除-因為您無法以高分辨率擦除，因此需要一次擦除整個塊（因此標記為已刪除）。 所有這些都會導致碎片，因此需要進行GC和壓縮。 讀取是平滑的，寫入會受到碎片，GC，壓縮等的阻礙，也要提防寫入放大。 使用SSD時有一些缺點，但總體上還是不錯的。 – 可能

我們能理解所有這些并編寫更好的代碼嗎？

結論：不要僅僅因為一切都在表面上就把所有東西都視為理所當然，而是在考慮可能的內部條件之前，對自己的內部結構進行檢查，檢查和調查，以便編寫良好的代碼并充分利用這些優勢特征。

—很好地談論了話題，并以很好的幽默感很好地涵蓋了機械同情主題，請觀看視頻以獲取針對上述每個硬件組件收集的性能統計信息—

Martin Thompson的

我們使用諸如“如何使用探查器？”之類的東西。 或“如何使用調試器？”

什么是性能？ 可能意味著兩件事，例如吞吐量或帶寬（可以通過多少）和延遲（系統響應的速度）。

響應時間隨我們在系統上施加更多負載而變化。 在設計任何系統之前，我們需要性能要求，即系統的吞吐量是多少或您希望系統響應的速度（延遲）如何？ 您的系統是否可以隨著業務進行經濟擴展？

開發者時間很昂貴，硬件也很便宜！ 對于任何事情，您都需要一個交易預算（對系統要經歷或要經歷的不同組件和流程進行很好的分解）。

我們如何進行性能測試？ 向系統施加負載，看看吞吐量是上升還是下降？ 當我們施加負載時，系統的響應時間是多少？ 壓力測試不同于負載測試（請參閱負載測試 ）， 壓力測試 （請參閱壓力測試 ）是發生故障（系統崩潰）的一個點，理想的系統將以一條平線繼續。 同樣重要的是，不僅要從一個點執行負載測試，而且要同時從多個點執行負載測試。 最重要的是，高持續時間測試非常重要–這會給表面帶來很多異常，例如內存泄漏等。

建立一個測試套件是一個好主意，它由較小的部分組成。 我們需要知道我們使用的系統的基本構建模塊以及我們可以從中獲得什么。 我們是否知道系統的不同閾值點以及它的組件可以處理多少？ 了解我們使用的算法，知道如何測量它們并相應地使用它非常重要–使用真實數據進行反向操作。

我們什么時候應該測試性能？

“過早的優化是萬惡之源” –唐納德·努斯/托尼·霍爾

優化是什么意思？ 知道并選擇您的數據，并圍繞它進行工作以提高性能。 新的開發實踐：我們需要經常進行早期測試！

從性能的角度來看，“首先測試”實踐非常重要，然后逐步設計系統，因為將來更改可能會花費很多。

紅色–綠色– 調試 – 配置文件 –重構，這是一種“測試優先”性能方法的新方法，而不是僅是“紅色-綠色重構”方法！ 反饋周期更早，更短比將來發現問題要好。

如果您在Performance空間工作，則使用“像實時”配對工作站一樣，Mac是一個不好的例子-linux機器是一個更好的選擇。

性能測試可能會導致構建失敗–并且它會導致CI系統中的構建失敗！ 微型基準測試儀（即游標卡尺）應該是什么樣？ 在代碼中進行分割可能會非常昂貴，請改用mask操作符 ！

并發測試呢？ 僅僅是性能嗎？ 不變量？ 爭論？

系統性能測試如何？ 我們是否應該能夠測試不同范圍的大型和小型客戶。 了解您使用的系統的深入細節很有趣。 業務問題是要解決的核心和最重要的問題，而不是討論要使用什么框架來構建它 。 請不要使用Java序列化，因為它不是為在線協議設計的！ 使用觀察者來衡量系統的性能，而不是從系統內部來衡量它。

性能測試課程–很多技術知識和文化知識。 技術課程–學習如何進行測量，查看直方圖！ 不要對系統進行采樣，當系統變得奇怪，離群值等等時，我們會漏掉一些東西–直方圖有幫助！ 了解系統需要長時間的區域周圍發生的事情很重要！ 從操作系統捕獲時間也非常重要。

隨著時間的流逝，您將獲得–準確性，精度和分辨率，大多數人將所有這些混合在一起。 在具有雙插槽的機器上， 時間可能不同步。 時間信息的質量在很大程度上取決于您所使用的操作系統。 在虛擬化系統上或兩臺不同的計算機之間，時間可能是個問題。 這個問題可以解決，就是在兩個系統之間往返操作（注意啟動和停止時鐘時間），然后將它們的一半來獲得更準確的時間。

了解您的系統及其底層組件–獲取指標并進行研究！ 使用像perstat這樣的linux工具，將在您的CPU和OS上提供大量與性能和統計相關的信息-分支預測和緩存丟失！

RDTSC不是命令指令執行系統，x86是命令指令系統，并且操作不會以無序方式發生。

約束理論！ –始終以數字1開頭，該數字會花費大部分時間–系統的瓶頸，其余的問題序列可能取決于數字1，而不是單獨的問題！

嘗試創建績效團隊是一種反模式–讓專家幫助將技能帶給團隊的其他成員，并擴展他們的能力！

提防YAGNI –關于執行性能測試–找借口！

提交構建> 3.40分鐘=令人擔憂，對于驗收測試構建> 15分鐘=降低團隊信心。

測試環境應該等于生產環境！ 這些天容易獲得完全相似的硬件！

結論：在編寫依賴于低延遲的應用程序時，從“測試優先”性能測試方法開始。 了解您的目標并朝著目標努力。 從硬件到開發環境，全面了解您的基礎系統。 在性能測試中，不僅重要的技術問題，文化的問題也同樣重要。 在團隊中共享和傳播知識，而不是將知識隔離給一兩個人，即所謂的團隊專家。 每個人的責任不只是團隊中的幾個前輩。 詳細了解跨各種硬件和操作系統以及系統之間的時間。

由于查看所有此類視頻和文章不切實際，因此在下面的鏈接中提供了許多視頻和文章以供進一步研究。 在許多情況下，我已經解釋或直接引用了作者為保留信息和希望傳達的意思而不得不說的話。

有用的資源

• 您的GC日志對您說話嗎，柯克·佩珀丁（Kirk Pepperdine）的G1GC版– 幻燈片 – 視頻
• 表演特別興趣小組的討論 –由Richard Warburton主持 （視頻）
• 緩存： @RichardWarburto提供的“更有效地理解，衡量和使用CPU緩存” （視頻和幻燈片）
• Jonathan Corbet撰寫的有關原子I / O操作（Linux）的文章
• Gil Tene的有關Azul Zing，低延遲GC和OpenJDK的文章和演示 （視頻和幻燈片）
• Martin Thompson的無鎖算法實現終極性能
• Performance Java User's Group –“面向想要將系統推向新高度的專業Java開發人員”
• 通過Kirk Pepperdine 調整線程池的大小
• Gil Tene 如何不衡量延遲
• 理解Java垃圾收集及其處理方法作者：Gil Tene
• Vanilla #Java了解Core Java的真正工作原理可以幫助您編寫更簡單，更快的應用程序 ，作者Peter Lawrey
• 在生產中對Java進行性能分析 – Kaushik Srenevasan撰寫
• Alexey Ragozin的HotSpot JVM垃圾回收選項備忘單（v3）
• 優化Google的倉庫規模計算機：NUMA體驗 – Univ的作者。 Cal（SD）和Google的資料！
• MegaPipe：多位作者的可擴展網絡I / O的新編程接口 ！
• 每個程序員應該了解的關于內存的知識Ulrich Drepper
• 內存壁壘：針對軟件黑客的硬件視圖 – Paul E. McKenney（Linux技術中心– IBM Beaverton）

參考：（ 第2部分，共3部分）： Java來歷日歷博客上來自JCG合作伙伴 Attila Mihaly Balazs的有關性能調優，Java中的JVM，GC，Mechanical Sympathy等的文章和視頻的摘要 。

翻譯自: https://www.javacodegeeks.com/2013/12/part-2-of-3-synopsis-of-articles-videos-on-performance-tuning-jvm-gc-in-java-mechanical-sympathy-et-al.html

總結

以上是生活随笔為你收集整理的（第2部分，共3部分）：有关性能调优，Java中的JVM，GC，Mechanical Sympathy等的文章和视频的摘要...的全部內容，希望文章能夠幫你解決所遇到的問題。

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