深刻理解JVM虛擬機10：JVM經常使用參數以及調優實踐

時間  2019-11-13
標籤 深刻 理解 jvm 虛擬機 經常 使用 參數 以及 實踐 欄目 Java 简体版
原文   原文鏈接

轉自http://www.rowkey.me/blog/2016/11/02/java-profile/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

 

 

 

JVM經常使用參數選項

 

jvm 可配置的參數選項能夠參考 Oracle 官方網站給出的相關信息：http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html 
下面只列舉其中的幾個經常使用和容易掌握的配置選項html

配置參數 功能
-Xms 初始堆大小。如：-Xms256m
-Xmx 最大堆大小。如：-Xmx512m
-Xmn 新生代大小。一般爲 Xmx 的 1/3 或 1/4。新生代 = Eden + 2 個 Survivor 空間。實際可用空間爲 = Eden + 1 個 Survivor，即 90%
-Xss JDK1.5+ 每一個線程堆棧大小爲 1M，通常來講若是棧不是很深的話， 1M 是絕對夠用了的。
-XX:NewRatio 新生代與老年代的比例，如 –XX:NewRatio=2，則新生代佔整個堆空間的1/3，老年代佔2/3
-XX:SurvivorRatio 新生代中 Eden 與 Survivor 的比值。默認值爲 8。即 Eden 佔新生代空間的 8/10，另外兩個 Survivor 各佔 1/10
-XX:PermSize 永久代(方法區)的初始大小
-XX:MaxPermSize 永久代(方法區)的最大值
-XX:+PrintGCDetails 打印 GC 信息
-XX:+HeapDumpOnOutOfMemoryError 讓虛擬機在發生內存溢出時 Dump 出當前的內存堆轉儲快照，以便分析用

注意：PermSize永久代的概念在jdk1.8中已經不存在了，取而代之的是metaspace元空間，當認爲執行永久代的初始大小以及最大值是jvm會給出如此下提示： 
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=30m; support was removed in 8.0 
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=30m; support was removed in 8.0java

 

GC調優參數總結

從前面的3篇文章中，咱們分析了5個垃圾收集器，還有一些 GC 的算法，那麼，在 GC 調優中，咱們確定會先判斷哪裏出現的問題，而後再根據出現的問題進行調優，而調優的手段就是 JVM 提供給咱們的那些參數或者說選項，這些參數將會改變 GC 的運行方式。所以，他們顯得極爲重要。ios

咱們將每個垃圾收集器相關的參數一個一個娓娓道來，注意，樓主推薦一個小程序：前阿里 JVM 大神寒泉子的公衆號裏面有個小程序------JVM Pocket，這個小程序介紹了全部的 JVM 參數的做用，你能夠在裏面搜索你想知道的參數，也能夠把你瞭解的參數寫上去供你們參考。公衆號：lovestblog。git

值得注意的一點是，這些參數可能會重複，還記得咱們以前的那張圖嗎，樓主以爲有必要再發一次：程序員

能夠看到，這些收集器會有一些重複，並且，某些參數也是會做用於全部的處理器，所以，咱們下面的介紹可能會有一些重複。github

還有一點就是，JVM 爲咱們設置了不少默認的參數，可是，若是能夠的話，仍是建議使用顯式的聲明，這樣更能表達意圖。不然，別人不必定知道咱們是否知道這些默認值。web

咱們開始咱們的參數之旅吧！面試

# 1. Serial 收集器參數

串行收集器，client 的默認收集器，分爲年輕代 Serial 和老年代 Serial Old 收集器。正則表達式

  1. -XX:+UseSerialGC 這個參數就是能夠指定使用新生代串行收集器和老年代串行收集器， 「+」 號的意思是ture，開啓，反之，若是是 「-」號，則是關閉。redis

  2. -XX:+UseParNewGC 新生代使用 ParNew 回收器，老年代使用串行收集器。

  3. -XX:+UseParallelGC 新生代私用 ParallelGC 回收器，老年代使用串行收集器。

而 Serial 收集器出現的日誌爲 DefNew .

# 2. ParNew 收集器參數

並行收集器是 Serial 的多線程版本，在 CPU 並行能力強大的計算機上有很大優點。

其中：

  1. -XX:+UseParNewGC 上面說過了，新生代使用 ParNew 收集器，老年代使用串行收集器。

  2. -XX:+UseConcMarkSweepGC: 新生代使用 ParNew 回收器，老年代使用 CMS。

  3. -XX:ParallelGCThreads={value} 這個參數是指定並行 GC 線程的數量，通常最好和 CPU 核心數量至關。默認狀況下，當 CPU 數量小於8， ParallelGCThreads 的值等於 CPU 數量，當 CPU 數量大於 8 時，則使用公式：3+（（5*CPU）/ 8）；同時這個參數只要是並行 GC 均可以使用，不僅是 ParNew。

而 ParNew 的 GC 日誌則表吸納出 ParNew。

# 3. PS 收集器參數

全稱 Parallel Scavenge 收集器，該收集器是 Java 8 的默認收集器，由於它可以根據系統當前狀態給出吞吐量最高的GC 配置。因此，在一些手工調優複雜的場合或者對實時性要求不高的場合，可使用該處理器。

有哪些參數呢？

  1. -XX:MaxGCPauseMillis 設置最大垃圾收集停頓時間，他的值是一個大於0的整數。ParallelGC 工做時，會調整 Java 堆大小或者其餘的一些參數，儘量的把停頓時間控制在 MaxGCPauseMillis 之內。若是爲了將停頓時間設置的很小，將此值也設置的很小，那麼 PS 將會把堆設置的也很小，這將會到值頻繁 GC ，雖然系統停頓時間小了，但總吞吐量降低了。

  2. -XX:GCTimeRatio 設置吞吐量大小，他的值是一個0 到100之間的整數，假設 GCTimeRatio 的值是 n ，那麼系統將花費不超過 1/(1+n) 的時間用於垃圾收集，默認 n 是99，即不超過1% 的時間用於垃圾收集。

  3. -XX:+UseParallelGC 新生代使用 ParallelGC 回收器，老年代使用串行回收器。

  4. -XX:+UseParallelOldGC 新生代使用 ParallelGC 回收器，老年代使用 ParallelOldGC 回收器。

  5. -XX:UseAdaptiveSizePolicy: 打開自適應策略。在這種模式下，新生代的大小，eden 和 Survivor 的比例，晉升老年代的對象年齡等參數會被自動調整。以達到堆大小，吞吐量，停頓時間的平衡點。

聰明的同窗相比看出來了，1 和 2 兩個參數是矛盾的。由於吞吐量和停頓時間就是矛盾的。因此，要根據應用的特性來進行設置，以達到最優水平。

同時，Parallel Old 收集器也是一種關注吞吐量的並行的老年代回收器。

  1. -XX:+UseParallelOldGC 新生代使用 ParallelGC 回收器，老年代使用 ParallelOldGC 回收器。該參數能夠啓用 ParallelOldGC。

  2. -XX:ParallelGCGThreads 同時能夠指定該參數設置並行線程數量。

而 PS 處理器的 GC 日誌則是 PSYoungGen。

# 4. CMS 收集器參數

CMS 處理器關注的是停頓時間。全稱 Concurrent Mark Sweep。由於該處理器較爲複雜，所以可使用較多參數。

  1. -XX:-CMSPrecleaningEnabled 不進行預清理，度過咱們以前的文章的都知道，CMS 在併發標記和從新標記的這段時間內，會有一個預清理的工做，而這個經過會嘗試5秒以內等待來一次 YGC。以避免在後面的從新標記階段耗費大量時間來標記新生代的對象。

  2. -XX:+UseConcMarkSweepGC 此參數將啓動 CMS 回收器。默認新生代是 ParNew，也能夠設置 Serial 爲新生代收集器。該參數等價於 -Xconcgc。

  3. -XX:ParallelGCThreads 因爲是並行處理器，固然也能夠指定線程數。默認併發線程數是：（ParallelGCThreads + 3）/ 4）。

  4. -XX:ConcGCThreads 或者 -XX:ParallelCMSThreads ；除了上面設置線程的方式，你也能夠經過這個兩個參數任意一個手工設定 CMS 併發線程數。

  5. -XX:CMSInitiatingOccupancyFraction 因爲 CMS 回收器不是獨佔式的，在垃圾回收的時候應用程序仍在工做，因此須要留出足夠的內存給應用程序，不然會觸發 FGC。而何時運行 CMS GC 呢？經過該參數便可設置，該參數表示的是老年代的內存使用百分比。當達到這個閾值就會執行 CMS。默認是68。 若是老年代內存增加很快，建議下降閾值，避免 FGC，若是增加慢，則能夠加大閾值，減小 CMS GC 次數。提升吞吐量。

  6. -XX：+UseCMSCompactAtFullCollection 因爲 CMS 使用標記清理算法，內存碎片沒法避免。該參數指定每次 CMS 後進行一次碎片整理。

  7. -XX:CMSFullGCsBeforeCompaction 因爲每次進行碎片整理將會影響性能，你可使用該參數設定多少次 CMS 後才進行一次碎片整理，也就是內存壓縮。

  8. -XX:+CMSClassUnloadingEnabled 容許對類元數據進行回收。

  9. -XX:CMSInitiatingPermOccupancyFraction 當永久區佔用率達到這一百分比時，啓動 CMS 回收（前提是 -XX:+CMSClassUnloadingEnabled 激活了）。

  10. -XX:UseCMSInitiatingOccupancyOnly 表示只在到達閾值的時候才進行 CMS 回收。

  11. XX:CMSWaitDuration=2000 因爲CMS GC 條件比較簡單，JVM有一個線程定時掃描Old區，時間間隔能夠經過該參數指定（毫秒單位），默認是2s。

CMS 的 GC 日誌 就是 CMS。

# 5. G1 收集器參數

做爲 Java 9 的默認垃圾收集器，該收集器和以前的收集器大不相同，該收集器能夠工做在young 區，也能夠工做在 old 區。有哪些參數呢？

  1. -XX:+UseG1GC 開啓 G1 收集器。

  2. -XX:MaxGCPauseMillis 用於指定最大停頓時間，若是任何一次停頓超過這個設置值時，G1 就會嘗試調整新生代和老年代的比例，調整堆大小，調整晉升年齡的手段，試圖達到目標。和 PS 同樣，停頓時間小了，對應的吞吐量也會變小。這點值得注意。

  3. -XX:ParallelGCThreads 因爲是並行併發的，能夠指定GC 工做線程數量。

  4. -XX:InitiatingHeapOccupancyPercent 該參數能夠指定當整個堆使用率達到多少時，觸發併發標記週期的執行。默認值時45，即當堆的使用率達到45%，執行併發標記週期，該值一旦設置，始終都不會被 G1修改。也就是說，G1 就算爲了知足 MaxGCPauseMillis 也不會修改此值。若是該值設置的很大，致使併發週期遲遲得不到啓動，那麼引發 FGC 的概率將會變大。若是太小，則會頻繁標記，GC 線程搶佔應用程序CPU 資源，性能將會降低。

  5. -XX:GCPauseIntervalMillis 設置停頓時間間隔。

# 6. 一些通用參數

在 GC 調優中，還有一些通用的參數。一般是咱們的好幫手。

  1. -XX:-+DisableExplicitGC 禁用 System.gc()，因爲該方法默認會觸發 FGC，而且忽略參數中的 UseG1GC 和 UseConcMarkSweepGC，所以必要時能夠禁用該方法。

  2. -XX:+ExplicitGCInvokesConcurrent 該參數能夠改變上面的行爲，也就是說，System.gc() 後不使用 FGC ，而是使用配置的併發收集器進行併發收集。注意：使用此選項就不要 使用 上面的選項。

  3. -XX:-ScavengeBeforeFullGC 因爲大部分 FGC 以前都會 YGC，減輕了 FGC 的壓力，縮短了 FGC 的停頓時間，但也可能你不須要這個特性，那麼你可使用這個參數關閉，默認是 ture 開啓。

  4. -XX:MaxTenuringThreshold={value} 新生代 to 區的對象在通過屢次 GC 後，若是尚未死亡，則認爲他是一個老對象，則能夠晉升到老年代，而這個年齡（GC 次數）是能夠設置的，有就是這個參數。默認值時15。超過15 則認爲是無限大(由於age變量時4個 bit，超過15沒法表達)。但該參數不是惟一決定對象晉升的條件。當 to 區不夠或者改對象年齡已經達到了平均晉升值或者大對象等等條件。

  5. -XX:TargetSurvivorRatio={value} 決定對什麼時候晉升的不只只有 XX:MaxTenuringThreshold 參數，若是在 Survivor 空間中相同年齡全部對象大小的總和大魚 Survivor 空間的一半（默認50%），年齡大於或等於該年齡的對象就能夠直接進入老年代。無需在意 XX:MaxTenuringThreshold參數。所以，MaxTenuringThreshold 只是對象晉升的最大年齡。若是將 TargetSurvivorRatio 設置的很小，對象將晉升的很快。

  6. -XX:PretenureSizeThresholds={value} 除了年齡外，對象的體積也是影響晉升的一個關鍵，也就是大對象。若是一個對象新生代放不下，只能直接經過分配擔保機制進入老年代。該參數是設置對象直接晉升到老年代的閾值，單位是字節。只要對象的大小大於此閾值，就會直接繞過新生代，直接進入老年代。注意：這個參數只對 Serial 和 ParNew 有效，ParallelGC 無效，默認狀況下該值爲0，也就是不指定最大的晉升大小，一切有運行狀況決定。

  7. -XX:-UseTLAB 禁用線程本地分配緩存。TLAB 的全稱是 Thread LocalAllocation Buffer ，即線程本地線程分配緩存，是一個線程私有的內存區域。該設計是爲了加速對象分配速度。因爲對象通常都是分配在堆上，而對是線程共享的。所以確定有鎖，雖然使用 CAS 的操做，但性能仍有優化空間。經過爲每個線程分配一個 TLAB 的空間（在 eden 區），能夠消除多個線程同步的開銷。默認開啓。

  8. -XX:TLABSize 指定 TLAB 的大小。

  9. -XX:+PrintTLAB 跟蹤 TLAB 的使用狀況。用以肯定是用多大的 TLABSize。

  10. -XX:+ResizeTLAB 自動調整 TLAB 大小。

同時，對象也可能會在棧上分配，棧上分配，TLAB 分配，堆分配，他們的流程以下：

對象分配流程

還有一些開啓 GC 日誌的參數，是 GC 調優不可或缺的工具。

  1. -XX:+PrintGCDateStamps 打印 GC 日誌時間戳。

  2. -XX:+PrintGCDetails 打印 GC 詳情。

  3. -XX:+PrintGCTimeStamps: 打印這次垃圾回收距離jvm開始運行的所耗時間。

  4. -Xloggc:<filename> 將垃圾回收信息輸出到指定文件

  5. -verbose:gc 打印 GC 日誌

  6. -XX:+PrintGCApplicationStopedTime 查看 gc 形成的應用暫停時間

  7. XX:+PrintTenuringDistribution, 對象晉升的日誌

  8. -XX:+HeapDumpOnOutOfMemoryError 內存溢出時輸出 dump 文件。

# 總結

好了，咱們已經將一些經常使用的 GC 參數介紹了，固然會有遺漏的，若有遺漏或者介紹有誤的，請告知本人。這些參數不只僅是爲了服務你們，同時也是本身作的一個總結，之後就不用處處找了。說白了這就是寫博客的好處：總結了本身，也作了備份，同時也可能幫助了別人。

 


做者：莫那一魯道
連接：https://www.jianshu.com/p/74d126dd5544
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

 

 

Java調優經驗談

Nov 2nd, 2016 Posted by 颯然Hang in java

目錄

對於調優這個事情來講，通常就是三個過程：

  • 性能監控：問題沒有發生，你並不知道你須要調優什麼。此時須要一些系統、應用的監控工具來發現問題。
  • 性能分析：問題已經發生，可是你並不知道問題到底出在哪裏。此時就須要使用工具、經驗對系統、應用進行瓶頸分析，以求定位到問題緣由。
  • 性能調優：通過上一步的分析定位到了問題所在，須要對問題進行解決，使用代碼、配置等手段進行優化。

Java調優也不外乎這三步。

此外，本文所講的性能分析、調優等是拋開如下因素的：

  • 系統底層環境：硬件、操做系統等
  • 數據結構和算法的使用
  • 外部系統如數據庫、緩存的使用

調優準備

調優是須要作好準備工做的，畢竟每個應用的業務目標都不盡相同，性能瓶頸也不會總在同一個點上。在業務應用層面，咱們須要：

  • 須要瞭解系統的整體架構，明確壓力方向。好比系統的哪個接口、模塊是使用率最高的，面臨高併發的挑戰。
  • 須要構建測試環境來測試應用的性能，使用ab、loadrunner、jmeter均可以。
  • 對關鍵業務數據量進行分析，這裏主要指的是對一些數據的量化分析，如數據庫一天的數據量有多少；緩存的數據量有多大等
  • 瞭解系統的響應速度、吞吐量、TPS、QPS等指標需求，好比秒殺系統對響應速度和QPS的要求是很是高的。
  • 瞭解系統相關軟件的版本、模式和參數等，有時候限於應用依賴服務的版本、模式等，性能也會受到必定的影響。

此外，咱們還須要瞭解Java相關的一些知識：

  1. Java內存相關：這一部分能夠參見談談Java內存管理一文
  2. 對Java代碼進行基準性能測試：可使用JMH來進行，[譯]使用JMH進行微基準測試：不要猜，要測試！。
  3. HotSpot VM相關知識：http://www.oracle.com/technetwork/cn/java/javase/tech/index-jsp-136373-zhs.html
  4. jdk自帶各類java工具：http://www.rowkey.me/blog/2016/11/03/jdk-tools/

性能分析

在系統層面可以影響應用性能的通常包括三個因素：CPU、內存和IO，能夠從這三方面進行程序的性能瓶頸分析。

CPU分析

當程序響應變慢的時候，首先使用top、vmstat、ps等命令查看系統的cpu使用率是否有異常，從而能夠判斷出是不是cpu繁忙形成的性能問題。其中，主要經過us（用戶進程所佔的%）這個數據來看異常的進程信息。當us接近100%甚至更高時，能夠肯定是cpu繁忙形成的響應緩慢。通常說來，cpu繁忙的緣由有如下幾個：

  • 線程中有無限空循環、無阻塞、正則匹配或者單純的計算
  • 發生了頻繁的gc
  • 多線程的上下文切換

肯定好cpu使用率最高的進程以後就可使用jstack來打印出異常進程的堆棧信息：

jstack [pid]

jstack

接下來須要注意的一點是，Linux下全部線程最終仍是以輕量級進程的形式存在系統中的，而使用jstack只能打印出進程的信息，這些信息裏面包含了此進程下面全部線程（輕量級進程-LWP）的堆棧信息。所以，進一步的須要肯定是哪個線程耗費了大量CPU，此時可使用top -p [processId] -H來查看，也能夠直接經過ps -Le來顯示全部進程,包括LWP的資源耗費信息。最後，經過在jstack的輸出文件中查找對應的LWP的id便可以定位到相應的堆棧信息。其中須要注意的是線程的狀態：RUNNABLE、WAITING等。對於Runnable的進程須要注意是否有耗費cpu的計算。對於Waiting的線程通常是鎖的等待操做。

也可使用jstat來查看對應進程的gc信息，以判斷是不是gc形成了cpu繁忙。

jstat -gcutil [pid]

jstat

還能夠經過vmstat，經過觀察內核狀態的上下文切換(cs)次數，來判斷是不是上下文切換形成的cpu繁忙。

vmstat 1 5

jstat

此外，有時候可能會由jit引發一些cpu飈高的情形，如大量方法編譯等。這裏可使用-XX:+PrintCompilation這個參數輸出jit編譯狀況，以排查jit編譯引發的cpu問題。

內存分析

對Java應用來講，內存主要是由堆外內存和堆內內存組成。

  1. 堆外內存

    堆外內存主要是JNI、Deflater/Inflater、DirectByteBuffer（nio中會用到）使用的。對於這種堆外內存的分析，仍是須要先經過vmstat、sar、top、pidstat(這裏的sar,pidstat以及iostat都是sysstat軟件套件的一部分，須要單獨安裝)等查看swap和物理內存的消耗情況再作判斷的。此外，對於JNI、Deflater這種調用能夠經過Google-preftools來追蹤資源使用情況。

  2. 堆內內存

    此部份內存爲Java應用主要的內存區域。一般與這部份內存性能相關的有：

    • 建立的對象：這個是存儲在堆中的，須要控制好對象的數量和大小，尤爲是大的對象很容易進入老年代
    • 全局集合：全局集合一般是生命週期比較長的，所以須要特別注意全局集合的使用
    • 緩存：緩存選用的數據結構不一樣，會很大程序影響內存的大小和gc
    • ClassLoader：主要是動態加載類容易形成永久代內存不足
    • 多線程：線程分配會佔用本地內存，過多的線程也會形成內存不足

    以上使用不當很容易形成：

    • 頻繁GC -> Stop the world，使你的應用響應變慢
    • OOM，直接形成內存溢出錯誤使得程序退出。OOM又能夠分爲如下幾種：
      • Heap space：堆內存不足
      • PermGen space：永久代內存不足
      • Native thread：本地線程沒有足夠內存可分配

    排查堆內存問題的經常使用工具是jmap，是jdk自帶的。一些經常使用用法以下：

    • 查看jvm內存使用情況：jmap -heap
    • 查看jvm內存存活的對象：jmap -histo:live
    • 把heap裏全部對象都dump下來，不管對象是死是活：jmap -dump:format=b,file=xxx.hprof
    • 先作一次full GC，再dump，只包含仍然存活的對象信息：jmap -dump:format=b,live,file=xxx.hprof

    此外，無論是使用jmap仍是在OOM時產生的dump文件，可使用Eclipse的MAT(MEMORY ANALYZER TOOL)來分析，能夠看到具體的堆棧和內存中對象的信息。固然jdk自帶的jhat也可以查看dump文件(啓動web端口供開發者使用瀏覽器瀏覽堆內對象的信息)。此外，VisualVM也可以打開hprof文件，使用它的heap walker查看堆內存信息。

IO分析

一般與應用性能相關的包括：文件IO和網絡IO。

  1. 文件IO

    可使用系統工具pidstat、iostat、vmstat來查看io的情況。這裏能夠看一張使用vmstat的結果圖。

    這裏主要注意bi和bo這兩個值，分別表示塊設備每秒接收的塊數量和塊設備每秒發送的塊數量，由此能夠斷定io繁忙情況。進一步的能夠經過使用strace工具定位對文件io的系統調用。一般，形成文件io性能差的緣由不外乎：

    • 大量的隨機讀寫
    • 設備慢
    • 文件太大

  2. 網絡IO

    查看網絡io情況，通常使用的是netstat工具。能夠查看全部鏈接的情況、數目、端口信息等。例如：當time_wait或者close_wait鏈接過多時，會影響應用的相應速度。

     netstat -anp

    此外，還可使用tcpdump來具體分析網絡io的數據。固然，tcpdump出的文件直接打開是一堆二進制的數據，可使用wireshark閱讀具體的鏈接以及其中數據的內容。

     tcpdump -i eth0 -w tmp.cap -tnn dst port 8080 #監聽8080端口的網絡請求並打印日誌到tmp.cap中

    還能夠經過查看/proc/interrupts來獲取當前系統使用的中斷的狀況。

    各個列依次是：

     irq的序號， 在各自cpu上發生中斷的次數，可編程中斷控制器，設備名稱（request_irq的dev_name字段）

    經過查看網卡設備的終端狀況能夠判斷網絡io的情況。

其餘分析工具

上面分別針對CPU、內存以及IO講了一些系統/JDK自帶的分析工具。除此以外，還有一些綜合分析工具或者框架能夠更加方便咱們對Java應用性能的排查、分析、定位等。

  • VisualVM

    這個工具應該是Java開發者們很是熟悉的一款java應用監測工具，原理是經過jmx接口來鏈接jvm進程，從而可以看到jvm上的線程、內存、類等信息。若是想進一步查看gc狀況，能夠安裝visual gc插件。此外，visualvm也有btrace的插件，能夠可視化直觀的編寫btrace代碼並查看輸出日誌。 與VisualVm相似的，jconsole也是經過jmx查看遠程jvm信息的一款工具，更進一步的，經過它還能夠顯示具體的線程堆棧信息以及內存中各個年代的佔用狀況，也支持直接遠程執行MBEAN。固然，visualvm經過安裝jconsole插件也能夠擁有這些功能。但因爲這倆工具都是須要ui界面的，所以通常都是經過本地遠程鏈接服務器jvm進程。服務器環境下，通常並不用此種方式。

  • Java Mission Control(jmc)

    此工具是jdk7 u40開始自帶的，原來是JRockit上的工具，是一款採樣型的集診斷、分析和監控與一體的很是強大的工具: https://docs.oracle.com/javacomponents/jmc-5-5/jmc-user-guide/toc.htm。可是此工具是基於JFR(jcmd JFR.start name=test duration=60s settings=template.jfc filename=output.jfr)的，而開啓JFR須要商業證書：jcmdVM.unlock_commercial_features。

  • Btrace

    這裏不得不提的是btrace這個神器，它使用java attach api+ java agent + instrument api可以實現jvm的動態追蹤。在不重啓應用的狀況下能夠加入攔截類的方法以打印日誌等。具體的用法能夠參考Btrace入門到熟練小工徹底指南。

  • Jwebap

    Jwebap是一款JavaEE性能檢測框架，基於asm加強字節碼實現。支持：http請求、jdbc鏈接、method的調用軌跡跟蹤以及次數、耗時的統計。由此能夠獲取最耗時的請求、方法，並能夠查看jdbc鏈接的次數、是否關閉等。但此項目是2006年的一個項目，已經將近10年沒有更新。根據筆者使用，已經不支持jdk7編譯的應用。若是要使用，建議基於原項目二次開發，同時也能夠加入對redis鏈接的軌跡跟蹤。固然，基於字節碼加強的原理，也能夠實現本身的JavaEE性能監測框架。

    上圖來自筆者公司二次開發過的jwebap，已經支持jdk8和redis鏈接追蹤。

  • useful-scripts

    這裏有一個本人蔘與的開源的項目：https://github.com/superhj1987/useful-scripts，封裝了不少經常使用的性能分析命令，好比上文講的打印繁忙java線程堆棧信息，只須要執行一個腳本便可。

性能調優

與性能分析相對應，性能調優一樣分爲三部分。

CPU調優

  • 不要存在一直運行的線程(無限while循環)，可使用sleep休眠一段時間。這種狀況廣泛存在於一些pull方式消費數據的場景下，當一次pull沒有拿到數據的時候建議sleep一下，再作下一次pull。
  • 輪詢的時候可使用wait/notify機制
  • 避免循環、正則表達式匹配、計算過多，包括使用String的format、split、replace方法(可使用apache的commons-lang裏的StringUtils對應的方法)，使用正則去判斷郵箱格式(有時候會形成死循環)、序列/反序列化等。
  • 結合jvm和代碼，避免產生頻繁的gc，尤爲是full GC。

此外，使用多線程的時候，還須要注意如下幾點：

  • 使用線程池，減小線程數以及線程的切換
  • 多線程對於鎖的競爭能夠考慮減少鎖的粒度(使用ReetrantLock)、拆分鎖(相似ConcurrentHashMap分bucket上鎖), 或者使用CAS、ThreadLocal、不可變對象等無鎖技術。此外，多線程代碼的編寫最好使用jdk提供的併發包、Executors框架以及ForkJoin等，此外Discuptor和Actor在合適的場景也可使用。

內存調優

內存的調優主要就是對jvm的調優。

  • 合理設置各個代的大小。避免新生代設置太小(不夠用，常常minor gc並進入老年代)以及過大(會產生碎片)，一樣也要避免Survivor設置過大和太小。
  • 選擇合適的GC策略。須要根據不一樣的場景選擇合適的gc策略。這裏須要說的是，cms並不是全能的。除非特別須要再設置，畢竟cms的新生代回收策略parnew並不是最快的，且cms會產生碎片。此外，G1直到jdk8的出現也並無獲得普遍應用，並不建議使用。
  • jvm啓動參數配置-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:[log_path]，以記錄gc日誌，便於排查問題。

其中，對於第一點，具體的還有一點建議：

  • 年輕代大小選擇：響應時間優先的應用，儘量設大，直到接近系統的最低響應時間限制（根據實際狀況選擇）。在此種狀況下，年輕代收集發生gc的頻率是最小的。同時，也可以減小到達年老代的對象。吞吐量優先的應用，也儘量的設置大，由於對響應時間沒有要求，垃圾收集能夠並行進行，建議適合8CPU以上的應用使用。
  • 年老代大小選擇：響應時間優先的應用，年老代通常都是使用併發收集器，因此其大小須要當心設置，通常要考慮併發會話率和會話持續時間等一些參數。若是堆設置小了，會形成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；若是堆大了，則須要較長的收集時間。最優化的方案，通常須要參考如下數據得到：
    • 併發垃圾收集信息
    • 持久代併發收集次數
    • 傳統GC信息
    • 花在年輕代和年老代回收上的時間比例

    通常吞吐量優先的應用都應該有一個很大的年輕代和一個較小的年老代。這樣能夠儘量回收掉大部分短時間對象，減小中期的對象，而年老代存放長期存活對象。

此外，較小堆引發的碎片問題：由於年老代的併發收集器使用標記、清除算法，因此不會對堆進行壓縮。當收集器回收時，會把相鄰的空間進行合併，這樣能夠分配給較大的對象。可是，當堆空間較小時，運行一段時間之後，就會出現「碎片」，若是併發收集器找不到足夠的空間，那麼併發收集器將會中止，而後使用傳統的標記、清除方式進行回收。若是出現「碎片」，可能須要進行以下配置：-XX:+UseCMSCompactAtFullCollection，使用併發收集器時，開啓對年老代的壓縮。同時使用-XX:CMSFullGCsBeforeCompaction=xx設置多少次Full GC後，對年老代進行壓縮。

其他對於jvm的優化問題可見後面JVM參數進階一節。

代碼上，也須要注意：

  • 避免保存重複的String對象，同時也須要當心String.subString()與String.intern()的使用，尤爲是後者其底層數據結構爲StringTable，當字符串大量不重複時，會使得StringTable很是大(一個固定大小的hashmap，能夠由參數-XX:StringTableSize=N設置大小)，從而影響young gc的速度。在jackson和fastjson中使用了此方法，某些場景下會引發gc問題: YGC愈來愈慢，爲何。
  • 儘可能不要使用finalizer
  • 釋放沒必要要的引用：ThreadLocal使用完記得釋放以防止內存泄漏，各類stream使用完也記得close。
  • 使用對象池避免無節制建立對象，形成頻繁gc。但不要隨便使用對象池，除非像鏈接池、線程池這種初始化/建立資源消耗較大的場景，
  • 緩存失效算法，能夠考慮使用SoftReference、WeakReference保存緩存對象
  • 謹慎熱部署/加載的使用，尤爲是動態加載類等

  • 不要用Log4j輸出文件名、行號，由於Log4j經過打印線程堆棧實現，生成大量String。此外，使用log4j時，建議此種經典用法，先判斷對應級別的日誌是否打開，再作操做，不然也會生成大量String。

      if (logger.isInfoEnabled()) {
      logger.info(msg);
  }

IO調優

文件IO上須要注意：

  • 考慮使用異步寫入代替同步寫入，能夠借鑑redis的aof機制。
  • 利用緩存，減小隨機讀
  • 儘可能批量寫入，減小io次數和尋址
  • 使用數據庫代替文件存儲

網絡IO上須要注意：

  • 和文件IO相似，使用異步IO、多路複用IO/事件驅動IO代替同步阻塞IO
  • 批量進行網絡IO,減小IO次數
  • 使用緩存，減小對網絡數據的讀取
  • 使用協程: Quasar

其餘優化建議

  • 算法、邏輯上是程序性能的首要，遇到性能問題，應該首先優化程序的邏輯處理
  • 優先考慮使用返回值而不是異常表示錯誤
  • 查看本身的代碼是否對內聯是友好的: 你的Java代碼對JIT編譯友好麼？

此外，jdk七、8在jvm的性能上作了一些加強：

  • 經過-XX:+TieredCompilation開啓JDK7的多層編譯（tiered compilation）支持。多層編譯結合了客戶端C1編譯器和服務端C2編譯器的優勢(客戶端編譯可以快速啓動和及時優化，服務器端編譯能夠提供更多的高級優化)，是一個很是高效利用資源的切面方案。在開始時先進行低層次的編譯，同時收集信息，在後期再進一步進行高層次的編譯進行高級優化。須要注意的一點：這個參數會消耗比較多的內存資源，由於同一個方法被編譯了屢次，存在多份native內存拷貝，建議把code cache調大一點兒（-XX:+ReservedCodeCacheSize，InitialCodeCacheSize）。不然有可能因爲code cache不足，jit編譯的時候不停的嘗試清理code cache，丟棄無用方法，消耗大量資源在jit線程上。
  • Compressed Oops：壓縮指針在jdk7中的server模式下已經默認開啓。
  • Zero-Based Compressed Ordinary Object Pointers：當使用了上述的壓縮指針時，在64位jvm上，會要求操做系統保留從一個虛擬地址0開始的內存。若是操做系統支持這種請求，那麼就開啓了Zero-Based Compressed Oops。這樣可使得無須在java堆的基地址添加任何地址補充便可把一個32位對象的偏移解碼成64位指針。
  • 逃逸分析(Escape Analysis): Server模式的編譯器會根據代碼的狀況，來判斷相關對象的逃逸類型，從而決定是否在堆中分配空間，是否進行標量替換(在棧上分配原子類型局部變量)。此外，也能夠根據調用狀況來決定是否自動消除同步控制，如StringBuffer。這個特性從Java SE 6u23開始就默認開啓。
  • NUMA Collector Enhancements：這個重要針對的是The Parallel Scavenger垃圾回收器。使其可以利用NUMA (Non Uniform Memory Access，即每個處理器核心都有本地內存，可以低延遲、高帶寬訪問) 架構的機器的優點來更快的進行gc。能夠經過-XX:+UseNUMA開啓支持。

此外，網上還有不少過期的建議，不要再盲目跟隨:

  • 變量用完設置爲null，加快內存回收，這種用法大部分狀況下並無意義。一種狀況除外：若是有個Java方法沒有被JIT編譯但裏面仍然有代碼會執行比較長時間，那麼在那段會執行長時間的代碼前顯式將不須要的引用類型局部變量置null是可取的。具體的能夠見R大的解釋：https://www.zhihu.com/question/48059457/answer/113538171
  • 方法參數設置爲final，這種用法也沒有太大的意義，尤爲在jdk8中引入了effective final，會自動識別final變量。

JVM參數進階

jvm的參數設置一直是比較理不清的地方，不少時候都搞不清都有哪些參數能夠配置，參數是什麼意思，爲何要這麼配置等。這裏主要針對這些作一些常識性的說明以及對一些容易讓人進入陷阱的參數作一些解釋。

 

如下全部都是針對Oracle/Sun JDK 6來說

 

  1. 啓動參數默認值

    Java有不少的啓動參數，並且不少版本都並不同。可是如今網上充斥着各類資料，若是不加辨別的所有使用，不少是沒有效果或者原本就是默認值的。通常的，咱們能夠經過使用java -XX:+PrintFlagsInitial來查看全部能夠設置的參數以及其默認值。也能夠在程序啓動的時候加入-XX:+PrintCommandLineFlags來查看與默認值不相同的啓動參數。若是想查看全部啓動參數(包括和默認值相同的)，可使用-XX:+PrintFlagsFinal。

    輸出裏「=」表示使用的是初始默認值，而「:=」表示使用的不是初始默認值，多是命令行傳進來的參數、配置文件裏的參數或者是ergonomics自動選擇了別的值。

    此外，還可使用jinfo命令顯示啓動的參數。

    • jinfo -flags [pid] #查看目前啓動使用的有效參數
    • jinfo -flag [flagName] [pid] #查看對應參數的值

    這裏須要指出的是，當你配置jvm參數時，最好是先經過以上命令查看對應參數的默認值再肯定是否須要設置。也最好不要配置你搞不清用途的參數，畢竟默認值的設置是有它的合理之處的。

  2. 動態設置參數

    當Java應用啓動後，定位到了是GC形成的性能問題，可是你啓動的時候並無加入打印gc的參數，不少時候的作法就是從新加參數而後重啓應用。但這樣會形成必定時間的服務不可用。最佳的作法是可以在不重啓應用的狀況下，動態設置參數。使用jinfo能夠作到這一點(本質上仍是基於jmx的)。

     jinfo -flag [+/-][flagName] [pid] #啓用/禁止某個參數
 jinfo -flag [flagName=value] [pid] #設置某個參數

    對於上述的gc的狀況，就可使用如下命令打開heap dump並設置dump路徑。

     jinfo -flag +HeapDumpBeforeFullGC [pid] 
 jinfo -flag +HeapDumpAfterFullGC [pid]
 jinfo -flag HeapDumpPath=/home/dump/dir [pid]

    一樣的也能夠動態關閉。

     jinfo -flag -HeapDumpBeforeFullGC [pid] 
 jinfo -flag -HeapDumpAfterFullGC [pid]

    其餘的參數設置相似。

  3. -verbose:gc 與 -XX:+PrintGCDetails

    不少gc推薦設置都同時設置了這兩個參數，其實，只要打開了-XX:+PrintGCDetails，前面的選項也會同時打開，無須重複設置。

  4. -XX:+DisableExplicitGC

    這個參數的做用就是使得system.gc變爲空調用，不少推薦設置裏面都是建議開啓的。可是，若是你用到了NIO或者其餘使用到堆外內存的狀況，使用此選項會形成oom。能夠用XX:+ExplicitGCInvokesConcurrent或XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses(配合CMS使用，使得system.gc觸發一次併發gc)代替。

    此外，還有一個比較有意思的地方。若是你不設置此選項的話，當你使用了RMI的時候，會週期性地來一次full gc。這個現象是因爲分佈式gc形成的，爲RMI服務。具體的可見此連接內容中與dgc相關的：http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/sunrmiproperties.html

  5. MaxDirectMemorySize

    此參數是設置的堆外內存的上限值。當不設置的時候爲-1，此值爲-Xmx減去一個survivor space的預留大小。

  6. 因爲遺留緣由，做用相同的參數

    • -Xss 與 -XX:ThreadStackSize
    • -Xmn 與 -XX:NewSize，此外這裏須要注意的是設置了-Xmn的話，NewRatio就沒做用了。

  7. -XX:MaxTenuringThreshold

    使用工具查看此值默認值爲15，可是選擇了CMS的時候，此值會變成4。當此值設置爲0時，全部eden裏的活對象在經歷第一次minor GC的時候就會直接晉升到old gen，survivor space直接就沒用。還有值得注意的一點，當使用並行回收器時，此值是沒有做用的，並行回收器默認是自動調整這些參數以求達到吞吐量最大的。此外，即便是使用CMS等回收器，晉升到老年代的age也不是不變的，當某一age的對象的大小達到年輕代的50%時，這個age會被動態調整爲晉升年齡。

  8. -XX:HeapDumpPath

    使用此參數能夠指定-XX:+HeapDumpBeforeFullGC、-XX:+HeapDumpAfterFullGC、-XX:+HeapDumpOnOutOfMemoryError觸發heap dump文件的存儲位置。

  9. -XX:+UseAdaptiveSizePolicy

    此參數在並行回收器時是默認開啓的，會根據應用運行情況作自我調整，如MaxTenuringThreshold、survivor區大小等。其中第一次晉升老年代的年齡以InitialTenuringThreshold（默認爲7）開始，後續會自動調整。若是但願跟蹤每次minor GC後新的存活週期的閾值，可在啓動參數上增長：-XX:+PrintTenuringDistribution。若是想要能夠配置這些參數，能夠關閉此選項，但paralle的性能很難達到最佳。其餘垃圾回收期則慎重開啓此開關。

 

微信公衆號【Java技術江湖】一位阿里 Java 工程師的技術小站。（關注公衆號後回覆」Java「便可領取 Java基礎、進階、項目和架構師等免費學習資料，更有數據庫、分佈式、微服務等熱門技術學習視頻，內容豐富，兼顧原理和實踐，另外也將贈送做者原創的Java學習指南、Java程序員面試指南等乾貨資源）

 

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程