java jvm調(diào)優(yōu)

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

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

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

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

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

演講時的Attila在Twitter上工作，他從中學到了許多有關(guān)JVM和Java語言本身的內(nèi)部知識– Twitter是一個組織，在其中進行調(diào)優(yōu)，優(yōu)化JVM，低延遲是事實。

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

• 延遲的貢獻者
• 完成的代碼尚未準備好用于生產(chǎn)
• 性能調(diào)整的區(qū)域（主要是內(nèi)存調(diào)整和鎖爭用調(diào)整）
• 內(nèi)存占用調(diào)整（OOME，低效調(diào)整，FAT數(shù)據(jù)）
• FAT數(shù)據(jù)-由他創(chuàng)造的新術(shù)語，以及如何解決由它產(chǎn)生的問題（非常深入和有趣）-了解有關(guān)Java / JVM語言中數(shù)據(jù)類型的字節(jié)分配。

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

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

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

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

結(jié)論：

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

-建議觀看視頻，內(nèi)容比上面的摘要要多得多-

Ben在本文中介紹了有關(guān)Java，其性能，GC等的古老神話和假設(shè)……涉及的領(lǐng)域包括：

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

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

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

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

結(jié)論：

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

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

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

GC的黃金法則

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

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

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

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

GC基于“弱世代假設(shè)”（即對象過早死亡或過時死亡），是通過經(jīng)驗研究發(fā)現(xiàn)的。

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

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

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

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

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

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

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

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

結(jié)論：

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

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

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

有用的資源

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

參考：（ 第1部分，共3部分）： Java出現(xiàn)日歷博客上來自JCG合作伙伴 Mani Sarkar的有關(guān)性能調(diào)優(yōu)，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調(diào)優(yōu)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。