讓Java應用程序運行是一回事，但讓他們跑得快就是另外一回事了。在面對對象的環境中，性能問題就像來勢兇猛的野獸。但JVM的復雜性將性能調整的復雜程度增加了一個級別。這里Refcard涵蓋了JVM internals、class loading（Java8中更新以映射最新的元空間）、垃圾回收、故障診斷、檢測、并發性，等等。
介紹
Java是目前軟件開發領域中使用最廣泛的編程語言之一。Java應用程序在許多垂直領域（銀行、電信、醫療保健等）中都有廣泛使用。Refcard的目的是，幫助開發者通過專注于JVM內部，性能調整原則和最佳實踐，以及利用現有監測和故障診斷工具，來提升應用程序在商業環境中的性能。
它能以不同的方式定義“optimal performance（最佳性能）”，但基本要素是：Java程序在業務響應時間要求內執行計算任務的能力，程序在高容量下執行業務功能的能力，并具有可靠性高和延遲低的特點。有時,數字本身變得模式化：對于一些大型網站，優秀的頁面響應時間應該在500ms以下。在適當的時候，Refcard包括目標數字。但在大多數情況下，您需要根據業務需求和現有的性能基準自己決定這些。
JVM Internals
基礎知識
代碼編譯和JIT
編譯Java字節碼顯然沒有直接從主機執行本機代碼那么快。為了提高性能，Hotspot JVM找出最繁忙的字節碼區域，然后將其編譯成更高效地原生、機器代碼（自適應優化）。然后這種本地代碼就會存儲在非堆內存中的代碼緩存中。
注意：多數的JVM是通過禁用JIT編譯器實現的(Djava.compiler=NONE)。您只需要考慮禁用的關鍵性優化，比如JVM崩潰。
下圖說明了Java源代碼，即時編譯流程和生命周期。
內存空間
HotSpot Java Virtual Machine是由以下的存儲空間組成。
| 存儲空間 |
描述 |
| Java Heap |
Java程序類實例和數組的主存儲器。 |
|
Permanent Generation(JDK 1.7及以下版本）
Metaspace (JDK 1.8及以上版本）
|
Java類元數據的主存儲器。
注意：從Java 8開始，PermGen空間就由元空間和使用本地存儲器替換了，類似于IBM J9 JVM。
|
| Native Heap(C-Heap) |
本地內存存儲線程、棧、包括對象的代碼緩存，如MMAP文件和第三方本機庫。 |
類加載
Java的另一個重要特點是，在JVM啟動之后，它能夠加載編譯的Java類（字節碼）。根據程序的大小，在剛剛重啟之后，程序在類加載過程中性能會顯著降低。這種現象是因為內部JIT編譯器在重啟之后需要重新開始優化。
自JDK 1.7版本之后，有一些改進值得大家重視。例如默認的JDK class loader具有更好的裝在類并發能力。
熱點
| 關注的區域 |
建議 |
| JVM重啟后的性能下降 |
避免部署過量的Java類到一個單一的應用程序類加載器（例如：非常大的WAR文件） |
| 運行時發現過多的類加載爭奪(thread lock, JAR file searches...) ，降低了整體性能。 |
分析您的應用程序并識別代碼模塊進行動態類加載操作過于頻繁。積極尋找非一站式類加載錯誤，如ClassNotFoundException和NoClassDefFoundError。
再訪Java映射API和適用情況下優化的過度使用。
|
|
java.lang.OutOfMemoryError: PermGen space （JDK 1.7及以下版本）
java.lang.OutOfMemoryError：元空間（JDK 1.8及以上版本）
|
再訪JVM Permanent Generation、Metaspace (MaxMetaSpaceSize)和本地內存容量在適用情況下的尺寸。
分析應用程序類加載器和識別元數據的內存泄漏的源頭。
|
故障診斷和監視
| 目標 |
建議 |
| 跟蹤那些加載到不同的類加載器的Java類。 |
配置程序選擇使用的Java profiler，例如JProfiler或Java VisualVM。將重點放在類加載器的操作和內存占用上。可以通過–verbose:class. for the IBM JVM，生成多個Java核心快照跟蹤活動的類加載器和加載類。 |
| 調查類元數據的內存泄露的可以來源。 |
配置程序和定義可能的culprit(s)。生成并分析JVmheap dump快照，專注于類加載器和java.lang.Class中的實例。
|
| 確保適當的Permanent Generation / Metaspace和本地內存大小。 |
密切監視你的PermGen、元空間和本機內存利用率，并調整到適合的最大容量。
分析程序類加載器的大小，并尋找機會適當地減少元數據足跡。
|
垃圾回收
Java垃圾回收流程對于程序性能是至關重要的。為了提供有效的垃圾回收，Heap（堆）本質上是劃分在子區域中。
堆區域
| 區域 |
描述 |
| 最新一代-Young Generation (nursery space) |
新的或短暫的對象分配保留堆的一部分。
垃圾被一個fast but stop-the-world YG的收集器進行回收。
在young space中呆了足夠久的對象就會提升到old space。
注意：YG space的尺寸和GC頻率過高將會顯著影響程序的響應時間，從而導致JVM的暫停時間增加。
|
| 老一代-Old Generation (tenured space) |
heap的一部分留給了long-lived對象。
垃圾通常通過平行或并發（多數時候）進行收集，諸如CMS或gencon (IBM JVM)。
性能提示：根據應用程序的需求選擇并測試最佳的GC策略是非常重要的。例如，當切換到并發GC收集（如CMS或G1）可以顯著提高應用程序的平均響應時間（減少延遲）。
|
GC Collectors
選擇正確的collector或GC policy可以將程序的性能、可擴展性和可靠性優化到最佳狀態。許多應用程序對于響應時間延遲都很敏感，因此大多需要使用并發的回收器，例如HotSpot CMS或IBM GC policy balanced。
我們強烈建議您通過適當的性能和負載測試確定最合適的GC策略。應該在生產環境中執行全面監控策略，以跟蹤整體的JVM性能，并確定在之后需要改進的領域。
| GC |
論據 |
描述 |
| 串行回收器 |
-XX:+UseSerialGC (Oracle HotSpot) |
無論新舊回收器都使用單獨CPU，像是一種stop the world的時尚。
|
|
并行回收器
（吞吐量回收器）
|
-XX:+UseParallelGC
-XX:+UseParallelOldGC
(Oracle Hotspot)
-Xgcpolicy:optthruput
(IBmJ9, single space, stop-the-world)
|
旨在利用CPU的內核優勢。無論新舊回收器都使用多個Gcthreads(via –XX:ParallelGCThreads=n)，從而更好地利用來自主機的可用的CPU內核來完成。
注意：雖然回收時間可以顯著減少，但是有著大尺寸堆的程序面臨著large、stop-the-world、old回收，并且響應時間也受到影響。
|
| 確保適當的Permanent Generation / Metaspace和本地內存大小。 |
密切監視你的PermGen、元空間和本機內存利用率，并調整到適合的最大容量。
分析程序類加載器的大小，并尋找機會適當地減少元數據足跡。
|
旨在最大限度地減少舊一代stop-the-world回收器對程序響應時間的影響。
大多數使用CMS collector的老一代回收器與所述應用程序的執行同時進行。
注意：YoungGen collections仍然有stop-the-world事件，因此需要適當的微調，以減少總JVM暫停時間。
|
Garbage First (G1) Collector
HotSpot G1 collector是專為是專為滿足用戶定義的垃圾回收（GC）高概率暫停時間設計的，同時實現高吞吐量。
最新的HotSpot collector將heap基本劃分到一組大小相等的堆區域，虛擬內存的每個區域連續范圍。它將回收壓縮的活動集中在heap區域，那里充滿了可回收的對象（garbage first）。換句話說就是，這個區域有最低限度的“live”對象。
Oracle建議在以下例子和情況下使用G1 collector，尤其是對于目前正在使用CMS或parallel collectors的：
- 專為large heaps(>= 6 GB)，并限制GC延遲（暫停時間<= 0.5秒)的應用程序設計。
- 超過50%的Java heap被實時數據占用（對象不能被GC回收）。
- 對象分析率和促進作用顯著變化。
- 不期望過長的垃圾回收或壓縮停頓（超過0.5至1秒）。
Java Heap尺寸
你一定要知道沒有GC策略可以挽救Java Heap尺寸不足的現象。這些演習涉及到為不同的存儲空間（包括新舊不同的版本）配置最大和最小的容量，包括元數據和本地內存容量。這里有一些建議準則：
- 在32-bit或64-bit JVM之間進行明智的選擇。如果程序運行需要超過2GB內存，并且JVM暫停時間在可接受范圍內，可以考慮使用64-bit JVM。
- 永遠將應用程序放在第一考慮。確保將其配置好，并根據程序的內存占用量調整heap尺寸。建議通過性能和負載測試來衡量實時數據占有量。
- larger heap并不總是表現得更好、更快，因此不需要過度調整Java heap。并行中的JVM性能調優，找準機會減少或“spread”程序的內存占有量，以保證JVM的平均響應時間＜1%。
- 對于32-bit JVM，為了從元數據和本地heap中留出一些內存，考慮2GB的最大heap尺寸。
- 對于64-bit JVM，我們要想辦法在垂直和水平層面進行擴展，而不是試圖將Java heap尺寸增加到15GB以上。這種做法往往提供更好的吞吐量，更好地利用硬件，提高應用程序的故障切換功能。
- 不許重復開發：充分利用開源以及商業故障排除的優勢和監控工具，使這些變成可能。APM（應用性能管理）產品在過去十年里發展迅猛。
JDK 1.8 Metaspace指南
| 目標 |
建議 |
|
內存大小
GC調整
監控和故障排除
|
默認情況下，元空間內存空間是無界的，并使用可用于動態擴展的process或OS native memory。內存空間分成快并通過mmap被JVM進行存儲。我們建議保持默認設置，以動態調整模式為出發點，將簡化的尺寸與密切監測的應用程序元數據占有量相結合，從而進行更好的容量規劃。
新增一個JVM選項(-XX:MaxMetaspaceSize=<NNN>)，可以讓您限制分配給class metadata的本地內存。當面臨物理資源（RAM）緊張或類似于內存泄露的情況時，建議將它作為一個保障機制。
對那種具有larger class metadata footprint或dynamic classloading的Java應用程序，我們建議通過新的JVM選項調整初始元空間大小 ：-XX:MetaspaceSize=<NNN>，例如：1GB。這種調整方法將有助于避免包括class metadata在內的早期垃圾回收，尤其是在Java應用程序的 “warm-up”期。
|
Hot Spots
故障診斷和監視
| 目標 |
建議 |
|
測量和監視應用程序YoungGen和OldGen內存占用，包括GC活動。
為您的應用程序決定正確的GC策略和Java堆大小。
調整應用程序的內存占用量，如live對象。
|
分析、監控您所使用的Java分析工具，如JProfiler、Java VisualVM或其他商業APM產品。
允許通過–verbose:gc記錄JVM GC活動。您也可以使用類似GCMV（GC Memory Visualizer）的工具查看JVM的暫停時間和內存分配率。
性能提示：過多的內存分配率可能意味著需要進行垂直和橫向擴展，或從多個JVM進程中分離出實時數據。
為了long-lived對象或long-term實時數據考慮，可以生成并分析JVM heap dump快照。Heap dump分析對于程序內存占用(retention)的優化是非常有幫助的。
性能提示：由于從32位到64位，Java應用程序對heap 的需求會比原來高1.5倍。所以，在Java 1.7及以下的版本(這是默認的)中使用 -XX:+UseCompressedOops是非常重要的。這樣的參數調整大大減輕了64位JVM的性能壓力。
|
| 調查OutOfMemoryError 問題，尋找OldGen內存泄露的根源。 |
使用類似Java VisualVM、Plumbr的工具（Java內存泄漏檢測器），分析可能存在的內容泄露。
性能提示：要著重分析最大的Java對象上。要意識到降低內存占有量就意味著提升性能，并降低GC活動。
使用類似 Memory Analyzer的工具生成并分析JVM heap dump快照。
|
Java并發性
Java并發性可以定義為程序同時執行多個任務的能力。對于大型的Java EE系統，這意味著執行多個用戶的業務功能的同時，實現最佳的吞吐量和性能的能力。
無論是硬件能力還是JVM穩定狀況，Java并發性問題可能引起程序的癱瘓，嚴重影響程序的整體性能和可用性。
Thread Lock Contention
當您評估Java應用程序的并發線程的穩定狀況時，你會經常遇到Thread lock contention的問題，這是目前最常見的Java并發問題。
例如：Thread lock contention會觸發non-stop，它會嘗試將一個缺少Java類（ClassNotFoundException的）加載到默認的JDK 1.7 ClassLoader。
如果您在成熟的技術環境中遇見像Thread Dump analysis這樣的問題，我們強烈建議您積極面對它。這個問題的根源通常不同于之前的Java synchronization to legitimate IO blocking或者其他的non-thread safe calls。Lock contention問題往往是另一個問題的“癥狀”。
Java-level Deadlocks
真正的Java-level deadlocks是不太常見的，它同樣可以極大程度地影響應用程序的性能和穩定性。當遇到兩個或多個線程永遠阻塞的時候，就會觸發這樣的問題。這種情況不同于其他常見的那種“day-to-day”線程問題，例如 lock contention、threads waiting on blocking IO calls等等。真正的lock-ordering deadlock問題可以被看做如下：
Oracle HotSpot 和IBM JVM為大多數的deadlock detectors情況提供了解決方案，幫助您快速找出造成這種狀況的罪魁禍首的線程。遇到類似lock contention troubleshooting的問題，建議從諸如線程轉儲分析為出發點來解決該問題。
一旦找到造成問題的代碼根源，解決方案涉及lock-ordering條件尋址和來自JDK其他可用的并發編程技術，如java.util.concurrent.locks.ReentrantLock，提供了諸如tryLock()的方法。這種方法給予開發人員更大的靈活性，也為防止deadlock和thread lock “starvation”提供了更多方式。
Clock Time和CPU Burn
在進行JVM調優的同時，也有必要檢查應用程序的行為，更確切地說是最高clock time和CPU burn的貢獻者。
當Java垃圾回收和線程并發不再是壓力點，深入到你的應用程序代碼的執行模式，并專注于頂級響應時間貢獻者（也叫作clock time）是很重要的。檢查應用程序代碼的消CPU耗和Java 線程(CPU burn)也同樣至關重要。CPU使用率較高（＞75%）是不正常的（良好的物理資源的利用率）。因為這往往意味著效率低下和容量問題。對于大型的Java EE企業應用，保持安全的CPU緩沖區是必要的，以應對突發的負載沖擊情況。
摒棄那些傳統的跟蹤方法，如在代碼中加入響應時間“日志”。Java剖析工具和APM解決方案恰恰可以幫助您分析這類型的問題。這種方式更加高效、可靠。對于Java生產環境缺乏一個強大的APM解決方案。您仍然可以依賴諸如Java VisualVM的工具，通過多個快照進行thread dump分析，并使用OS CPU分析每個線程。
最后的建議是，不要妄圖同時解決所有的問題。列出排在最前面的5個clock time和CPU burn問題，然后尋找解決方案。
Application預算
其他關于Java應用程序性能的重要方面是穩定性和可靠性。在有著99.9%典型可用目標的SLA umbrella下，穩定和可靠對于程序的操作尤為重要。這些系統應該具有高容錯級別，并對應用和資源進行嚴格的預算，以防止發生多米諾效應。用這種方法可以防止一些這樣的情況，例如，一個業務流程使用所有可用的物理，中間件或JVM資源。
Hot Spots
超時管理
Java application與外部系統之間缺乏合理的超時時間，由于中間件和JVM線程消耗(blocking IO calls)，可能導致嚴重的性能下降和中斷。合理的超時時間可以避免在遇到外部服務提供商速度緩慢的時候，Java線程等待太久。
工具
| 目標 |
建議工具 |
| 自動、實時地性能監控、調節、預警、趨勢分析、容量管理，等等 |
Enterprise APM solutions（企業級APM解決方案）
注意：APM解決方案提供了工具，這些現成的功能讓您實現以下大部分的Java性能目標。
|
| 性能和負載測試 |
商業性能測試解決方案
Apache JMeter
|
| JVM垃圾回收評估，內存分配率和故障排除 |
Oracle Java VisualVM
Oracle Java Mission Control
IBM Monitoring and Diagnostic Tools for Java (via IBM Support Assistant tool)
JVM verbose:gc logs
JVM argument : -verbose:gc
IBM GCMV
|
| JVM堆和類的元數據的內存泄漏分析 |
Oracle Java VisualVM and Oracle Java Mission Control
IBM Monitoring and Diagnostic Tools for Java
Memory Analyzer (heap dump analysis, hprof and phd formats)
|
| JVM內存分析和堆容量評估 |
Oracle Java VisualVM and Java Mission Control
IBM Monitoring and Diagnostic Tools for Java
Java profilers (JProfiler, YourKit)
Memory Analyzer (heap dump and application memory footprint analysis)
|
| JVM和中間件并發故障，如thread lock contention和deadlocks |
Oracle Java VisualVM and Oracle Java Mission Control (threads monitoring, thread dump snapshots)
jstack, native OS signal such as kill -3 (thread dump snapshots)
IBM Monitoring and Diagnostic Tools for Java
注意：強烈推薦大家關注如何執行一個JVM線程轉儲分析的相關知識。
|
| Java應用程序clock time分析和評測 |
Oracle Java VisualVM and Oracle Java Mission Control (build-in profiler, sampler and recorder)
Java profilers (JProfiler, YourKit)
|
| Java應用程序和線程CPU burn分析 |
Oracle Java VisualVM and Oracle Java Mission Control (CPU profiler)
Java profilers (JProfiler, YourKit)
注意：必要的時候，您還可以依賴JVM線程轉儲和OS CPU每個線程分析。
|
| Java IO和remoting contention分析，包括超時管理評估和調整 |
Oracle Java VisualVM and Oracle Java Mission Control
(threads monitoring, thread dump snapshots)
jstack, native OS signal such as kill -3 (thread dump snapshots)
IBM Monitoring and Diagnostic Tools for Java
注意：強烈推薦大家關注如何執行一個JVM線程轉儲分析的相關知識。
|
| 中間件，Java EE容器調整，如線程、JDBC數據源，等等 |
Oracle Java VisualVM and Oracle Java Mission Control (extra focus on exposed Java EE container runtime MBeans)
Java EE container administration and management console
|
原文翻譯自：
轉載請注明：evget
標簽：
Java數據分析
本站文章除注明轉載外，均為本站原創或翻譯。歡迎任何形式的轉載，但請務必注明出處、不得修改原文相關鏈接，如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
金喜正規買球 
16次
相關產品
正式授權
最新文章 
金喜正規買球相關的文章 
微信
在線咨詢
渝公網安備
50010702500608號
客服熱線