java jvm調優

我已經花了幾個月的時間考慮審查有關性能調優，JVM，Java中的GC，Mechanical Sympathy等主題的文章和視頻的緩存，并最終花了點時間–也許這就是重點我什么時候才需要做我的智力進步！

感謝Attila-Mihaly給我提供了為其年度時事通訊Java Advent Calendar撰寫帖子的機會，因此，對各種Java相關主題進行評論非常合適！ 視頻和文章的選擇純粹是隨機的，并且基于我了解的順序。 我隱藏的議程是主要通過他們來理解和擴展我自己的知識，同時與他人分享任何見解。

我將介紹Attila Szegedi（1個演講）和Ben Evans（2個演講）的三篇演講評論。 他們談論Java性能和GC的主題。 Attila的首次演講涵蓋了他在Twitter上擔任工程師的豐富經驗-因此，其大量信息來自生產系統領域的現場經驗。 在他的演講中，用薄物體代替胖物體是流行語之一。

Ben在他的兩個演講中深入討論了性能，JVM和GC。 他指出了人們對性能，JVM和GC的誤解，以及人們在生產中未啟用某些運行時標志的事情。 基礎機械如何工作，為什么以其工作方式工作，機械的效率如何，如何最好地做而不是為了從中獲得好的吞吐量呢？

在這里，我附上我的評論，我決定從Attila Szegedi的演講開始，因為我非常喜歡標題.....

演講時的Attila在Twitter上工作，他從中學到了許多有關JVM和Java語言本身的內部知識– Twitter是一個組織，在其中進行調優，優化JVM，低延遲是事實。

他涵蓋了有趣的主題，例如：

• 延遲的貢獻者
• 完成的代碼尚未準備好用于生產
• 性能調整的區域（主要是內存調整和鎖爭用調整）
• 內存占用調整（OOME，低效調整，FAT數據）
• FAT數據-由他創造的新術語，以及如何解決由它產生的問題（非常深入和有趣）-了解有關Java / JVM語言中數據類型的字節分配。

這些建議之一（包括陷阱）是一些深入的潛水主題，例如壓縮對象指針。 正如JVM分析器所揭示的那樣，Scala 2.7.7中的某些類型效率很低。 不要使用Thrift –因為它不是低延遲的朋友，因為它們很沉重–每個對象增加52到72字節的開銷，不支持32位浮點數，等等…注意線程局部變量–堅持使用并且使用了比預期更多的資源。

在表演三角上，Attila分享了他對這一概念的見識。 GC是JVM的最大威脅。 老一代使用ConcCollector，而新一代則通過STW流程，并爭取了許多吞吐量和低暫停時間的收集器。

通過利用“自適應大小調整”策略來改進GC，并為其制定目標。 使用帶有或不帶有自適應策略的吞吐量收集器，并對結果進行基準測試。 他帶領我們完成了各種-XX：+ Print ...標志，并解釋了其用法。 保持碎片少并避免GC完全停止。 有關GC工作原理的詳細信息，以及如何改進GC（調整新舊基因）。

與GC不相關的延遲–線程協調優化。 當使用線程來改善延遲時，可以使用屏障和半屏障；在使用Atomic值和AtomicReferences時，可以使用一些技巧。 Cassandra平板分配器–幫助提高效率和性能–無需編寫自己的內存管理器。 Attila不再是“軟參考”的粉絲–盡管理論上很棒，但實際上卻不行，但需要更多的GC周期來清除它們！

結論：

經常了解您的代碼，這可能是導致問題的根源-框架可能多次成為性能問題的原因。 如果人們知道如何最好地利用開發環境的數據結構的基本構建塊，則可以做很多事情來降低所編寫程序的性能。 要保持最佳的吞吐量并從JVM中獲得最佳性能，這是一項艱巨的任務。

-建議觀看視頻，內容比上面的摘要要多得多-

Ben在本文中介紹了有關Java，其性能，GC等的古老神話和假設……涉及的領域包括：

1） Java速度很慢； 2）單行Java意味著任何孤立的事物； 3）微型基準意味著您認為它可以做什么，
4）算法緩慢是造成性能問題的最常見原因； 5）緩存解決了所有問題； 6）所有應用都需要關注世界停止狀態； 7）手動滾動對象池適用于各種應用， 8） CMS總是比Parallel Old，GC更好的選擇GC ）9）增加堆大小將解決您的內存問題

• 在許多情況下，JIT編譯的代碼與C ++一樣快
• JIT編譯器甚至可以在分析數據的基礎上優化掉無效和未使用的代碼。 在JRockit之類的JVM中，JIT可以分解對象操作。
• 為了獲得最佳結果，請不要過早優化，而要糾正性能熱點。
• 理查德·費曼（Richard Feynman）曾經說過：“第一個原則是，您不能欺騙自己-并且您是最容易欺騙的人” –在考慮編寫Java微基準測試時要牢記的一點。

人們對Java的想法是觀點，但與事實相反。 基本上是建議群眾重新審視思想，根據純粹的事實而不是假設或舊的信念做出結論。

• 與算法相比，GC，數據庫訪問，配置錯誤等都可能導致應用程序運行緩慢。
• 測量，不要猜測！ 使用經驗生產數據來發現性能問題的真正原因。
• 不要只是添加緩存以將問題重定向到其他地方并增加系統的復雜性，而是要收集基本使用情況統計信息（未命中率，命中率等）以證明緩存層確實在增加價值。
• 如果用戶沒有抱怨，或者您不在低延遲堆棧中，則不必擔心STOP-THE-WORLD暫停（大約200毫秒，具體取決于堆大小）。
• 對象池非常困難，只有在GC暫停不可接受且調優和重構的智能嘗試無法將暫停降低到可接受的水平時才應使用對象池。
• 檢查CMS是否是正確的GC策略，首先應確定Parallel Old的STW暫停是不可接受的，無法進行調整。 Ben強調要確保所有指標都是在等同于生產的系統上獲得的 。
• 在更改堆大小或調整其他參數之前，了解對象分配和生存期的動態至關重要。 不加估量行事會使事情變得更糟。 來自垃圾收集器的權屬分配信息在這里尤為重要。

結論：

由GC子系統具有用于調諧和用于產生數據，以指導調諧，然后使用一個工具來分析日志令人難以置信的潛力-無論是手寫腳本和某些圖形的產生，或作為（開源）的可視化工具，例如GCViewer 或商業產品 。

人們對GC的理解有誤解或不足。 它不僅是Mark＆Sweep。 如今，許多運行時都具有GC！ 兩種思想流派– GC和參考計數！ 與需要高精度的機器相比，人類會犯錯誤。 True GC是Java率先開發的，效率極高，引用計數非常昂貴。

分配列表是所有對象都源自的列表。 在不停止應用程序的情況下，您無法在正在運行的實時應用程序的任何給定時間點上獲得運行對象的所有對象的準確圖片，這就是我們擁有STW（停止世界）的原因！

GC的黃金法則

• 必須收集所有垃圾（敏感規則）
• 絕不能收集活物

（絕招：但是他們永遠都不會平等）

熱點是C / C ++ / Assembly應用程序。 堆是具有不同內存池（Young Gen，Old Gen和PermGen池）的連續內存塊。 對象由應用程序（變量）線程創建，并由GC刪除。 由于GC始終導致應用程序運行緩慢。

PermG –不理想，在Java 8中消失了（已知問題：導致OOME異常），被堆（本機內存）之外的Metaspace代替。

GC基于“弱世代假設”（即對象過早死亡或過時死亡），是通過經驗研究發現的。

保有期限閾值是您移至“舊一代”（保有期限）之前可以生存的GC數量。 JavaFX與jdk7u6及更高版本捆綁在一起。

用Java編寫的JavaFX Memory Visualizer的源代碼取代了使用FlexML（FXML）編寫的Flash版本– https://github.com/kittylyst/jfx-mem 。 關于如何用一種不錯的編程語言FlexML編寫程序的廣泛解釋–將構建器模式與類似DSL的表達式結合使用。 該程序模擬了GC的工作方式以及如何在不同的池中創建，銷毀和移動對象。

強制性標志列表，對性能沒有任何影響

• 詳細：gc
• Xloggc：<路徑文件>
• XX：+ PrintGCDetails
• XX：+ PrintTenuringDistribution

上面記錄了有關正在執行的應用程序和GC的所有信息。 還介紹了基本的堆大小調整標志。 自從JDK的最新版本以來，將堆標志設置為相等就不再適用。 另外，GC和VM有200多個標志，其中不包括所有未記錄的標志。

GC日志文件對于后處理很有用，但有時記錄不正確。 MXBeans會影響正在運行的應用程序，但不會提供比日志文件更多的信息。

GC日志文件具有通用格式，可提供有關分配更改，占用率，任期信息，收集信息等信息的信息– GC日志文件格式的爆炸性增長，并且工具不多。 許多免費工具涵蓋了某種儀表板，例如顯示各種與GC相關的指標的輸出，而商業版本通常具有更好的方法和有用的信息。 過早推廣 –在創建新對象的壓力下，對象直接從YG移到OG，而無需經過Survivor空間。

使用工具，進行測量，不要猜測！

結論：

了解事實并找出細節（如果不知道但不要猜測或假設）。 錯誤的概念有時會導致假設和對JVM和GC進程的錯誤理解。 不要只是更改標志或使用工具，不知道為什么以及它們做什么。 例如，打開GC日志記錄（啟用了適當的標志）不會對JVM的性能產生明顯影響，但從中長期來看是一個福音。

—強烈建議您觀看視頻，其內容比上面的提要要多，Ben以一種最簡單的方式解釋了GC，其中涵蓋了許多重要的細節—

由于查看所有此類視頻和文章不切實際，因此在下面的鏈接中提供了許多視頻和文章以供進一步研究。 在許多情況下，我已經解釋或直接引用了作者為保留信息和希望傳達的意思而不得不說的話。 此博客文章的后續內容將出現在標題為（第2部分，共3部分）的同一空格處： 2013年12月19日 有關性能優化，JVM，Java中的GC，Mechanical Sympathy等的文章和視頻的摘要 。

有用的資源

• 是您的GC日志對您說話嗎，G1GC版– 幻燈片 – 視頻
• Java應用程序性能調優的原理
• 表演特殊興趣小組討論 –由Richard Warburton主持 （視頻）
• 緩存： @RichardWarburto提供的“更有效地理解，衡量和使用CPU緩存” （視頻和幻燈片）
• 關于原子I / O操作的文章（Linux）
• 有關Azul Zing，低延遲GC和OpenJDK的文章和演示文稿 （視頻和幻燈片）
• Martin Thompson的無鎖算法實現終極性能
• Performance Java用戶小組–“面向希望將系統推向新高度的專業Java開發人員”
• 優化Google的倉庫規模計算機：NUMA體驗 – Univ的作者。 Cal（SD）和Google的資料！
• MegaPipe：多位作者的可擴展網絡I / O的新編程接口 ！
• 每個程序員應該了解的關于內存的知識Ulrich Drepper
• 內存壁壘：針對軟件黑客的硬件視圖 – Paul E. McKenney（Linux技術中心– IBM Beaverton）
• Vanilla #Java了解Core Java的真正工作原理可以幫助您編寫更簡單，更快的應用程序 ，作者Peter Lawrey
• 通過Kirk Pepperdine 調整線程池的大小

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

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

java jvm調優

總結

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

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