讓Java應用程序運行是一回事，但讓他們跑得快就是另外一回事了。在面對對象的環(huán)境中，性能問題就像來勢兇猛的野獸。但JVM的復雜性將性能調(diào)整的復雜程度增加了一個級別。這里Refcard涵蓋了JVM internals、class loading（Java8中更新以映射最新的元空間）、垃圾回收、故障診斷、檢測、并發(fā)性，等等。

介紹

Java是目前軟件開發(fā)領(lǐng)域中使用最廣泛的編程語言之一。Java應用程序在許多垂直領(lǐng)域（銀行、電信、醫(yī)療保健等）中都有廣泛使用。Refcard的目的是，幫助開發(fā)者通過專注于JVM內(nèi)部，性能調(diào)整原則和最佳實踐，以及利用現(xiàn)有監(jiān)測和故障診斷工具，來提升應用程序在商業(yè)環(huán)境中的性能。

它能以不同的方式定義“optimal performance（最佳性能）”，但基本要素是：Java程序在業(yè)務響應時間要求內(nèi)執(zhí)行計算任務的能力，程序在高容量下執(zhí)行業(yè)務功能的能力，并具有可靠性高和延遲低的特點。有時,數(shù)字本身變得模式化：對于一些大型網(wǎng)站，優(yōu)秀的頁面響應時間應該在500ms以下。在適當?shù)臅r候，Refcard包括目標數(shù)字。但在大多數(shù)情況下，您需要根據(jù)業(yè)務需求和現(xiàn)有的性能基準自己決定這些。

JVM Internals

基礎(chǔ)知識

代碼編譯和JIT

編譯Java字節(jié)碼顯然沒有直接從主機執(zhí)行本機代碼那么快。為了提高性能，Hotspot JVM找出最繁忙的字節(jié)碼區(qū)域，然后將其編譯成更高效地原生、機器代碼（自適應優(yōu)化）。然后這種本地代碼就會存儲在非堆內(nèi)存中的代碼緩存中。

注意：多數(shù)的JVM是通過禁用JIT編譯器實現(xiàn)的(Djava.compiler=NONE)。您只需要考慮禁用的關(guān)鍵性優(yōu)化，比如JVM崩潰。

下圖說明了Java源代碼，即時編譯流程和生命周期。

內(nèi)存空間

HotSpot Java Virtual Machine是由以下的存儲空間組成。

類加載

Java的另一個重要特點是，在JVM啟動之后，它能夠加載編譯的Java類（字節(jié)碼）。根據(jù)程序的大小，在剛剛重啟之后，程序在類加載過程中性能會顯著降低。這種現(xiàn)象是因為內(nèi)部JIT編譯器在重啟之后需要重新開始優(yōu)化。

自JDK 1.7版本之后，有一些改進值得大家重視。例如默認的JDK class loader具有更好的裝在類并發(fā)能力。

熱點

故障診斷和監(jiān)視

目標	建議
跟蹤那些加載到不同的類加載器的Java類。	配置程序選擇使用的Java profiler，例如JProfiler或Java VisualVM。將重點放在類加載器的操作和內(nèi)存占用上。可以通過–verbose:class. for the IBM JVM，生成多個Java核心快照跟蹤活動的類加載器和加載類。
調(diào)查類元數(shù)據(jù)的內(nèi)存泄露的可以來源。	配置程序和定義可能的culprit(s)。生成并分析JVmheap dump快照，專注于類加載器和java.lang.Class中的實例。
確保適當?shù)腜ermanent Generation / Metaspace和本地內(nèi)存大小。	密切監(jiān)視你的PermGen、元空間和本機內(nèi)存利用率，并調(diào)整到適合的最大容量。 分析程序類加載器的大小，并尋找機會適當?shù)販p少元數(shù)據(jù)足跡。

垃圾回收

Java垃圾回收流程對于程序性能是至關(guān)重要的。為了提供有效的垃圾回收，Heap（堆）本質(zhì)上是劃分在子區(qū)域中。

堆區(qū)域

GC Collectors

選擇正確的collector或GC policy可以將程序的性能、可擴展性和可靠性優(yōu)化到最佳狀態(tài)。許多應用程序?qū)τ陧憫獣r間延遲都很敏感，因此大多需要使用并發(fā)的回收器，例如HotSpot CMS或IBM GC policy balanced。

我們強烈建議您通過適當?shù)男阅芎拓撦d測試確定最合適的GC策略。應該在生產(chǎn)環(huán)境中執(zhí)行全面監(jiān)控策略，以跟蹤整體的JVM性能，并確定在之后需要改進的領(lǐng)域。

GC	論據(jù)	描述
串行回收器	-XX:+UseSerialGC (Oracle HotSpot)	無論新舊回收器都使用單獨CPU，像是一種stop the world的時尚。
并行回收器 （吞吐量回收器）	-XX:+UseParallelGC -XX:+UseParallelOldGC (Oracle Hotspot) -Xgcpolicy:optthruput (IBmJ9, single space, stop-the-world)	旨在利用CPU的內(nèi)核優(yōu)勢。無論新舊回收器都使用多個Gcthreads(via –XX:ParallelGCThreads=n)，從而更好地利用來自主機的可用的CPU內(nèi)核來完成。 注意：雖然回收時間可以顯著減少，但是有著大尺寸堆的程序面臨著large、stop-the-world、old回收，并且響應時間也受到影響。
確保適當?shù)腜ermanent Generation / Metaspace和本地內(nèi)存大小。	密切監(jiān)視你的PermGen、元空間和本機內(nèi)存利用率，并調(diào)整到適合的最大容量。 分析程序類加載器的大小，并尋找機會適當?shù)販p少元數(shù)據(jù)足跡。	旨在最大限度地減少舊一代stop-the-world回收器對程序響應時間的影響。 大多數(shù)使用CMS collector的老一代回收器與所述應用程序的執(zhí)行同時進行。 注意：YoungGen collections仍然有stop-the-world事件，因此需要適當?shù)奈⒄{(diào)，以減少總JVM暫停時間。

Garbage First (G1) Collector

 HotSpot G1 collector是專為是專為滿足用戶定義的垃圾回收（GC）高概率暫停時間設(shè)計的，同時實現(xiàn)高吞吐量。

最新的HotSpot collector將heap基本劃分到一組大小相等的堆區(qū)域，虛擬內(nèi)存的每個區(qū)域連續(xù)范圍。它將回收壓縮的活動集中在heap區(qū)域，那里充滿了可回收的對象（garbage first）。換句話說就是，這個區(qū)域有最低限度的“live”對象。

Oracle建議在以下例子和情況下使用G1 collector，尤其是對于目前正在使用CMS或parallel collectors的：

• 專為large heaps(>= 6 GB)，并限制GC延遲（暫停時間<= 0.5秒)的應用程序設(shè)計。
• 超過50%的Java heap被實時數(shù)據(jù)占用（對象不能被GC回收）。
• 對象分析率和促進作用顯著變化。
• 不期望過長的垃圾回收或壓縮停頓（超過0.5至1秒）。

Java Heap尺寸

你一定要知道沒有GC策略可以挽救Java Heap尺寸不足的現(xiàn)象。這些演習涉及到為不同的存儲空間（包括新舊不同的版本）配置最大和最小的容量，包括元數(shù)據(jù)和本地內(nèi)存容量。這里有一些建議準則：

• 在32-bit或64-bit JVM之間進行明智的選擇。如果程序運行需要超過2GB內(nèi)存，并且JVM暫停時間在可接受范圍內(nèi)，可以考慮使用64-bit JVM。
• 永遠將應用程序放在第一考慮。確保將其配置好，并根據(jù)程序的內(nèi)存占用量調(diào)整heap尺寸。建議通過性能和負載測試來衡量實時數(shù)據(jù)占有量。
• larger heap并不總是表現(xiàn)得更好、更快，因此不需要過度調(diào)整Java heap。并行中的JVM性能調(diào)優(yōu)，找準機會減少或“spread”程序的內(nèi)存占有量，以保證JVM的平均響應時間＜1%。
• 對于32-bit JVM，為了從元數(shù)據(jù)和本地heap中留出一些內(nèi)存，考慮2GB的最大heap尺寸。
• 對于64-bit JVM，我們要想辦法在垂直和水平層面進行擴展，而不是試圖將Java heap尺寸增加到15GB以上。這種做法往往提供更好的吞吐量，更好地利用硬件，提高應用程序的故障切換功能。
• 不許重復開發(fā)：充分利用開源以及商業(yè)故障排除的優(yōu)勢和監(jiān)控工具，使這些變成可能。APM（應用性能管理）產(chǎn)品在過去十年里發(fā)展迅猛。

JDK 1.8 Metaspace指南

Hot Spots

故障診斷和監(jiān)視

目標	建議
測量和監(jiān)視應用程序YoungGen和OldGen內(nèi)存占用，包括GC活動。 為您的應用程序決定正確的GC策略和Java堆大小。 調(diào)整應用程序的內(nèi)存占用量，如live對象。	分析、監(jiān)控您所使用的Java分析工具，如JProfiler、Java VisualVM或其他商業(yè)APM產(chǎn)品。 允許通過–verbose:gc記錄JVM GC活動。您也可以使用類似GCMV（GC Memory Visualizer）的工具查看JVM的暫停時間和內(nèi)存分配率。 性能提示：過多的內(nèi)存分配率可能意味著需要進行垂直和橫向擴展，或從多個JVM進程中分離出實時數(shù)據(jù)。 為了long-lived對象或long-term實時數(shù)據(jù)考慮，可以生成并分析JVM heap dump快照。Heap dump分析對于程序內(nèi)存占用(retention)的優(yōu)化是非常有幫助的。 性能提示：由于從32位到64位，Java應用程序?qū)eap 的需求會比原來高1.5倍。所以，在Java 1.7及以下的版本(這是默認的)中使用 -XX:+UseCompressedOops是非常重要的。這樣的參數(shù)調(diào)整大大減輕了64位JVM的性能壓力。
調(diào)查OutOfMemoryError 問題，尋找OldGen內(nèi)存泄露的根源。	使用類似Java VisualVM、Plumbr的工具（Java內(nèi)存泄漏檢測器），分析可能存在的內(nèi)容泄露。 性能提示：要著重分析最大的Java對象上。要意識到降低內(nèi)存占有量就意味著提升性能，并降低GC活動。 使用類似 Memory Analyzer的工具生成并分析JVM heap dump快照。

Java并發(fā)性

Java并發(fā)性可以定義為程序同時執(zhí)行多個任務的能力。對于大型的Java EE系統(tǒng)，這意味著執(zhí)行多個用戶的業(yè)務功能的同時，實現(xiàn)最佳的吞吐量和性能的能力。

無論是硬件能力還是JVM穩(wěn)定狀況，Java并發(fā)性問題可能引起程序的癱瘓，嚴重影響程序的整體性能和可用性。

Thread Lock Contention

當您評估Java應用程序的并發(fā)線程的穩(wěn)定狀況時，你會經(jīng)常遇到Thread lock contention的問題，這是目前最常見的Java并發(fā)問題。

例如：Thread lock contention會觸發(fā)non-stop，它會嘗試將一個缺少Java類（ClassNotFoundException的）加載到默認的JDK 1.7 ClassLoader。

如果您在成熟的技術(shù)環(huán)境中遇見像Thread Dump analysis這樣的問題，我們強烈建議您積極面對它。這個問題的根源通常不同于之前的Java synchronization to legitimate IO blocking或者其他的non-thread safe calls。Lock contention問題往往是另一個問題的“癥狀”。

Java-level Deadlocks

真正的Java-level deadlocks是不太常見的，它同樣可以極大程度地影響應用程序的性能和穩(wěn)定性。當遇到兩個或多個線程永遠阻塞的時候，就會觸發(fā)這樣的問題。這種情況不同于其他常見的那種“day-to-day”線程問題，例如 lock contention、threads waiting on blocking IO calls等等。真正的lock-ordering deadlock問題可以被看做如下：

Oracle HotSpot 和IBM JVM為大多數(shù)的deadlock detectors情況提供了解決方案，幫助您快速找出造成這種狀況的罪魁禍首的線程。遇到類似lock contention troubleshooting的問題，建議從諸如線程轉(zhuǎn)儲分析為出發(fā)點來解決該問題。

一旦找到造成問題的代碼根源，解決方案涉及l(fā)ock-ordering條件尋址和來自JDK其他可用的并發(fā)編程技術(shù)，如java.util.concurrent.locks.ReentrantLock，提供了諸如tryLock()的方法。這種方法給予開發(fā)人員更大的靈活性，也為防止deadlock和thread lock “starvation”提供了更多方式。

Clock Time和CPU Burn

在進行JVM調(diào)優(yōu)的同時，也有必要檢查應用程序的行為，更確切地說是最高clock time和CPU burn的貢獻者。

當Java垃圾回收和線程并發(fā)不再是壓力點，深入到你的應用程序代碼的執(zhí)行模式，并專注于頂級響應時間貢獻者（也叫作clock time）是很重要的。檢查應用程序代碼的消CPU耗和Java 線程(CPU burn)也同樣至關(guān)重要。CPU使用率較高（＞75%）是不正常的（良好的物理資源的利用率）。因為這往往意味著效率低下和容量問題。對于大型的Java EE企業(yè)應用，保持安全的CPU緩沖區(qū)是必要的，以應對突發(fā)的負載沖擊情況。

摒棄那些傳統(tǒng)的跟蹤方法，如在代碼中加入響應時間“日志”。Java剖析工具和APM解決方案恰恰可以幫助您分析這類型的問題。這種方式更加高效、可靠。對于Java生產(chǎn)環(huán)境缺乏一個強大的APM解決方案。您仍然可以依賴諸如Java VisualVM的工具，通過多個快照進行thread dump分析，并使用OS CPU分析每個線程。

最后的建議是，不要妄圖同時解決所有的問題。列出排在最前面的5個clock time和CPU burn問題，然后尋找解決方案。

Application預算

其他關(guān)于Java應用程序性能的重要方面是穩(wěn)定性和可靠性。在有著99.9%典型可用目標的SLA umbrella下，穩(wěn)定和可靠對于程序的操作尤為重要。這些系統(tǒng)應該具有高容錯級別，并對應用和資源進行嚴格的預算，以防止發(fā)生多米諾效應。用這種方法可以防止一些這樣的情況，例如，一個業(yè)務流程使用所有可用的物理，中間件或JVM資源。

Hot Spots

超時管理

Java application與外部系統(tǒng)之間缺乏合理的超時時間，由于中間件和JVM線程消耗(blocking IO calls)，可能導致嚴重的性能下降和中斷。合理的超時時間可以避免在遇到外部服務提供商速度緩慢的時候，Java線程等待太久。

工具

原文翻譯自：

轉(zhuǎn)載請注明：evget