轉自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
下面隻列舉其中的幾個常用和容易掌握的配置選項
| 配置參數 | 功能 |
|---|---|
| -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.0
GC調優參數總結
從前面的3篇文章中，我們分析了5個垃圾收集器，還有一些 GC 的算法，那麼，在 GC 調優中，我們肯定會先判斷哪裡出現的問題，然後再根據出現的問題進行調優，而調優的手段就是 JVM 提供給我們的那些參數或者說選項，這些參數将會改變 GC 的運作方式。是以，他們顯得極為重要。
我們将每一個垃圾收集器相關的參數一個一個娓娓道來，注意，樓主推薦一個小程式：前阿裡 JVM 大神寒泉子的公衆号裡面有個小程式------JVM Pocket，這個小程式介紹了所有的 JVM 參數的作用，你可以在裡面搜尋你想知道的參數，也可以把你了解的參數寫上去供大家參考。公衆号：lovestblog。
值得注意的一點是，這些參數可能會重複，還記得我們之前的那張圖嗎，樓主覺得有必要再發一次：
可以看到，這些收集器會有一些重複，而且，某些參數也是會作用于所有的處理器，是以，我們下面的介紹可能會有一些重複。
還有一點就是，JVM 為我們設定了很多預設的參數，但是，如果可以的話，還是建議使用顯式的聲明，這樣更能表達意圖。否則，别人不一定知道我們是否知道這些預設值。
我們開始我們的參數之旅吧！
# 1. Serial 收集器參數
串行收集器，client 的預設收集器，分為年輕代 Serial 和老年代 Serial Old 收集器。
- -XX:+UseSerialGC 這個參數就是可以指定使用新生代串行收集器和老年代串行收集器， “+” 号的意思是ture，開啟，反之，如果是 “-”号，則是關閉。
- -XX:+UseParNewGC 新生代使用 ParNew 回收器，老年代使用串行收集器。
- -XX:+UseParallelGC 新生代私用 ParallelGC 回收器，老年代使用串行收集器。
而 Serial 收集器出現的日志為 DefNew .
# 2. ParNew 收集器參數
并行收集器是 Serial 的多線程版本，在 CPU 并行能力強大的計算機上有很大優勢。
其中：
- -XX:+UseParNewGC 上面說過了，新生代使用 ParNew 收集器，老年代使用串行收集器。
- -XX:+UseConcMarkSweepGC: 新生代使用 ParNew 回收器，老年代使用 CMS。
- -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 配置。是以，在一些手工調優複雜的場合或者對實時性要求不高的場合，可以使用該處理器。
有哪些參數呢？
- -XX:MaxGCPauseMillis 設定最大垃圾收集停頓時間，他的值是一個大于0的整數。ParallelGC 工作時，會調整 Java 堆大小或者其他的一些參數，盡可能的把停頓時間控制在 MaxGCPauseMillis 以内。如果為了将停頓時間設定的很小，将此值也設定的很小，那麼 PS 将會把堆設定的也很小，這将會到值頻繁 GC ，雖然系統停頓時間小了，但總吞吐量下降了。
- -XX:GCTimeRatio 設定吞吐量大小，他的值是一個0 到100之間的整數，假設 GCTimeRatio 的值是 n ，那麼系統将花費不超過 1/(1+n) 的時間用于垃圾收集，預設 n 是99，即不超過1% 的時間用于垃圾收集。
- -XX:+UseParallelGC 新生代使用 ParallelGC 回收器，老年代使用串行回收器。
- -XX:+UseParallelOldGC 新生代使用 ParallelGC 回收器，老年代使用 ParallelOldGC 回收器。
- -XX:UseAdaptiveSizePolicy: 打開自适應政策。在這種模式下，新生代的大小，eden 和 Survivor 的比例，晉升老年代的對象年齡等參數會被自動調整。以達到堆大小，吞吐量，停頓時間的平衡點。
聰明的同學相比看出來了，1 和 2 兩個參數是沖突的。因為吞吐量和停頓時間就是沖突的。是以，要根據應用的特性來進行設定，以達到最優水準。
同時，Parallel Old 收集器也是一種關注吞吐量的并行的老年代回收器。
- -XX:+UseParallelOldGC 新生代使用 ParallelGC 回收器，老年代使用 ParallelOldGC 回收器。該參數可以啟用 ParallelOldGC。
- -XX:ParallelGCGThreads 同時可以指定該參數設定并行線程數量。
而 PS 處理器的 GC 日志則是 PSYoungGen。
# 4. CMS 收集器參數
CMS 處理器關注的是停頓時間。全稱 Concurrent Mark Sweep。因為該處理器較為複雜，是以可以使用較多參數。
- -XX:-CMSPrecleaningEnabled 不進行預清理，度過我們之前的文章的都知道，CMS 在并發标記和重新标記的這段時間内，會有一個預清理的工作，而這個通過會嘗試5秒之内等待來一次 YGC。以免在後面的重新标記階段耗費大量時間來标記新生代的對象。
- -XX:+UseConcMarkSweepGC 此參數将啟動 CMS 回收器。預設新生代是 ParNew，也可以設定 Serial 為新生代收集器。該參數等價于 -Xconcgc。
- -XX:ParallelGCThreads 由于是并行處理器，當然也可以指定線程數。預設并發線程數是：（ParallelGCThreads + 3）/ 4）。
- -XX:ConcGCThreads 或者 -XX:ParallelCMSThreads ；除了上面設定線程的方式，你也可以通過這個兩個參數任意一個手工設定 CMS 并發線程數。
- -XX:CMSInitiatingOccupancyFraction 由于 CMS 回收器不是獨占式的，在垃圾回收的時候應用程式仍在工作，是以需要留出足夠的記憶體給應用程式，否則會觸發 FGC。而什麼時候運作 CMS GC 呢？通過該參數即可設定，該參數表示的是老年代的記憶體使用百分比。當達到這個門檻值就會執行 CMS。預設是68。 如果老年代記憶體增長很快，建議降低門檻值，避免 FGC，如果增長慢，則可以加大門檻值，減少 CMS GC 次數。提高吞吐量。
- -XX：+UseCMSCompactAtFullCollection 由于 CMS 使用标記清理算法，記憶體碎片無法避免。該參數指定每次 CMS 後進行一次碎片整理。
- -XX:CMSFullGCsBeforeCompaction 由于每次進行碎片整理将會影響性能，你可以使用該參數設定多少次 CMS 後才進行一次碎片整理，也就是記憶體壓縮。
- -XX:+CMSClassUnloadingEnabled 允許對類中繼資料進行回收。
- -XX:CMSInitiatingPermOccupancyFraction 當永久區占用率達到這一百分比時，啟動 CMS 回收（前提是 -XX:+CMSClassUnloadingEnabled 激活了）。
- -XX:UseCMSInitiatingOccupancyOnly 表示隻在到達門檻值的時候才進行 CMS 回收。
- XX:CMSWaitDuration=2000 由于CMS GC 條件比較簡單，JVM有一個線程定時掃描Old區，時間間隔可以通過該參數指定（毫秒機關），預設是2s。
CMS 的 GC 日志 就是 CMS。
# 5. G1 收集器參數
作為 Java 9 的預設垃圾收集器，該收集器和之前的收集器大不相同，該收集器可以工作在young 區，也可以工作在 old 區。有哪些參數呢？
- -XX:+UseG1GC 開啟 G1 收集器。
- -XX:MaxGCPauseMillis 用于指定最大停頓時間，如果任何一次停頓超過這個設定值時，G1 就會嘗試調整新生代和老年代的比例，調整堆大小，調整晉升年齡的手段，試圖達到目标。和 PS 一樣，停頓時間小了，對應的吞吐量也會變小。這點值得注意。
- -XX:ParallelGCThreads 由于是并行并發的，可以指定GC 工作線程數量。
- -XX:InitiatingHeapOccupancyPercent 該參數可以指定當整個堆使用率達到多少時，觸發并發标記周期的執行。預設值時45，即當堆的使用率達到45%，執行并發标記周期，該值一旦設定，始終都不會被 G1修改。也就是說，G1 就算為了滿足 MaxGCPauseMillis 也不會修改此值。如果該值設定的很大，導緻并發周期遲遲得不到啟動，那麼引起 FGC 的幾率将會變大。如果過小，則會頻繁标記，GC 線程搶占應用程式CPU 資源，性能将會下降。
- -XX:GCPauseIntervalMillis 設定停頓時間間隔。
# 6. 一些通用參數
在 GC 調優中，還有一些通用的參數。通常是我們的好幫手。
- -XX:-+DisableExplicitGC 禁用 System.gc()，由于該方法預設會觸發 FGC，并且忽略參數中的 UseG1GC 和 UseConcMarkSweepGC，是以必要時可以禁用該方法。
- -XX:+ExplicitGCInvokesConcurrent 該參數可以改變上面的行為，也就是說，System.gc() 後不使用 FGC ，而是使用配置的并發收集器進行并發收集。注意：使用此選項就不要 使用 上面的選項。
- -XX:-ScavengeBeforeFullGC 由于大部分 FGC 之前都會 YGC，減輕了 FGC 的壓力，縮短了 FGC 的停頓時間，但也可能你不需要這個特性，那麼你可以使用這個參數關閉，預設是 ture 開啟。
- -XX:MaxTenuringThreshold={value} 新生代 to 區的對象在經過多次 GC 後，如果還沒有死亡，則認為他是一個老對象，則可以晉升到老年代，而這個年齡（GC 次數）是可以設定的，有就是這個參數。預設值時15。超過15 則認為是無限大(因為age變量時4個 bit，超過15無法表達)。但該參數不是唯一決定對象晉升的條件。當 to 區不夠或者改對象年齡已經達到了平均晉升值或者大對象等等條件。
- -XX:TargetSurvivorRatio={value} 決定對何時晉升的不僅隻有 XX:MaxTenuringThreshold 參數，如果在 Survivor 空間中相同年齡所有對象大小的總和大魚 Survivor 空間的一半（預設50%），年齡大于或等于該年齡的對象就可以直接進入老年代。無需在乎 XX:MaxTenuringThreshold參數。是以，MaxTenuringThreshold 隻是對象晉升的最大年齡。如果将 TargetSurvivorRatio 設定的很小，對象将晉升的很快。
- -XX:PretenureSizeThresholds={value} 除了年齡外，對象的體積也是影響晉升的一個關鍵，也就是大對象。如果一個對象新生代放不下，隻能直接通過配置設定擔保機制進入老年代。該參數是設定對象直接晉升到老年代的門檻值，機關是位元組。隻要對象的大小大于此門檻值，就會直接繞過新生代，直接進入老年代。注意：這個參數隻對 Serial 和 ParNew 有效，ParallelGC 無效，預設情況下該值為0，也就是不指定最大的晉升大小，一切有運作情況決定。
- -XX:-UseTLAB 禁用線程本地配置設定緩存。TLAB 的全稱是 Thread LocalAllocation Buffer ，即線程本地線程配置設定緩存，是一個線程私有的記憶體區域。該設計是為了加速對象配置設定速度。由于對象一般都是配置設定在堆上，而對是線程共享的。是以肯定有鎖，雖然使用 CAS 的操作，但性能仍有優化空間。通過為每一個線程配置設定一個 TLAB 的空間（在 eden 區），可以消除多個線程同步的開銷。預設開啟。
- -XX:TLABSize 指定 TLAB 的大小。
- -XX:+PrintTLAB 跟蹤 TLAB 的使用情況。用以确定是用多大的 TLABSize。
- -XX:+ResizeTLAB 自動調整 TLAB 大小。
同時，對象也可能會在棧上配置設定，棧上配置設定，TLAB 配置設定，堆配置設定，他們的流程如下：
對象配置設定流程
還有一些開啟 GC 日志的參數，是 GC 調優不可或缺的工具。
- -XX:+PrintGCDateStamps 列印 GC 日志時間戳。
- -XX:+PrintGCDetails 列印 GC 詳情。
- -XX:+PrintGCTimeStamps: 列印此次垃圾回收距離jvm開始運作的所耗時間。
- -Xloggc:<filename> 将垃圾回收資訊輸出到指定檔案
- -verbose:gc 列印 GC 日志
- -XX:+PrintGCApplicationStopedTime 檢視 gc 造成的應用暫停時間
- XX:+PrintTenuringDistribution, 對象晉升的日志
- -XX:+HeapDumpOnOutOfMemoryError 記憶體溢出時輸出 dump 檔案。
# 總結
好了，我們已經将一些常用的 GC 參數介紹了，當然會有遺漏的，如有遺漏或者介紹有誤的，請告知本人。這些參數不僅僅是為了服務大家，同時也是自己做的一個總結，以後就不用到處找了。說白了這就是寫部落格的好處：總結了自己，也做了備份，同時也可能幫助了别人。
作者：莫那一魯道
連結：https://www.jianshu.com/p/74d126dd5544
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
Java調優經驗談
Nov 2nd, 2016 Posted by 飒然Hang in java
目錄
- 調優準備
- 性能分析
- 性能調優
- 其他優化建議
- JVM參數進階
對于調優這個事情來說，一般就是三個過程：
- 性能監控：問題沒有發生，你并不知道你需要調優什麼。此時需要一些系統、應用的監控工具來發現問題。
- 性能分析：問題已經發生，但是你并不知道問題到底出在哪裡。此時就需要使用工具、經驗對系統、應用進行瓶頸分析，以求定位到問題原因。
- 性能調優：經過上一步的分析定位到了問題所在，需要對問題進行解決，使用代碼、配置等手段進行優化。
Java調優也不外乎這三步。
此外，本文所講的性能分析、調優等是抛開以下因素的：
- 系統底層環境：硬體、作業系統等
- 資料結構和算法的使用
- 外部系統如資料庫、緩存的使用
調優準備
調優是需要做好準備工作的，畢竟每一個應用的業務目标都不盡相同，性能瓶頸也不會總在同一個點上。在業務應用層面，我們需要：
- 需要了解系統的總體架構，明确壓力方向。比如系統的哪一個接口、子產品是使用率最高的，面臨高并發的挑戰。
- 需要建構測試環境來測試應用的性能，使用ab、loadrunner、jmeter都可以。
- 對關鍵業務資料量進行分析，這裡主要指的是對一些資料的量化分析，如資料庫一天的資料量有多少；緩存的資料量有多大等
- 了解系統的響應速度、吞吐量、TPS、QPS等名額需求，比如秒殺系統對響應速度和QPS的要求是非常高的。
- 了解系統相關軟體的版本、模式和參數等，有時候限于應用依賴服務的版本、模式等，性能也會受到一定的影響。
此外，我們還需要了解Java相關的一些知識：
- Java記憶體相關：這一部分可以參見談談Java記憶體管理一文
- 對Java代碼進行基準性能測試：可以使用JMH來進行，[譯]使用JMH進行微基準測試：不要猜，要測試！。
- HotSpot VM相關知識：http://www.oracle.com/technetwork/cn/java/javase/tech/index-jsp-136373-zhs.html
- 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]接下來需要注意的一點是，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]
還可以通過vmstat，通過觀察核心狀态的上下文切換(cs)次數，來判斷是否是上下文切換造成的cpu繁忙。
vmstat 1 5此外，有時候可能會由jit引起一些cpu飚高的情形，如大量方法編譯等。這裡可以使用-XX:+PrintCompilation這個參數輸出jit編譯情況，以排查jit編譯引起的cpu問題。
記憶體分析
對Java應用來說，記憶體主要是由堆外記憶體和堆内記憶體組成。
-
堆外記憶體
堆外記憶體主要是JNI、Deflater/Inflater、DirectByteBuffer（nio中會用到）使用的。對于這種堆外記憶體的分析，還是需要先通過vmstat、sar、top、pidstat(這裡的sar,pidstat以及iostat都是sysstat軟體套件的一部分，需要單獨安裝)等檢視swap和實體記憶體的消耗狀況再做判斷的。此外，對于JNI、Deflater這種調用可以通過Google-preftools來追蹤資源使用狀況。
-
堆内記憶體
此部分記憶體為Java應用主要的記憶體區域。通常與這部分記憶體性能相關的有：
- 建立的對象：這個是存儲在堆中的，需要控制好對象的數量和大小，尤其是大的對象很容易進入老年代
- 全局集合：全局集合通常是生命周期比較長的，是以需要特别注意全局集合的使用
- 緩存：緩存選用的資料結構不同，會很大程式影響記憶體的大小和gc
- ClassLoader：主要是動态加載類容易造成永久代記憶體不足
- 多線程：線程配置設定會占用本地記憶體，過多的線程也會造成記憶體不足
- 頻繁GC -> Stop the world，使你的應用響應變慢
- OOM，直接造成記憶體溢出錯誤使得程式退出。OOM又可以分為以下幾種：
- Heap space：堆記憶體不足
- PermGen space：永久代記憶體不足
- Native thread：本地線程沒有足夠記憶體可配置設定
- 檢視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
通常與應用性能相關的包括：檔案IO和網絡IO。
-
檔案IO
可以使用系統工具pidstat、iostat、vmstat來檢視io的狀況。這裡可以看一張使用vmstat的結果圖。
這裡主要注意bi和bo這兩個值，分别表示塊裝置每秒接收的塊數量和塊裝置每秒發送的塊數量，由此可以判定io繁忙狀況。進一步的可以通過使用strace工具定位對檔案io的系統調用。通常，造成檔案io性能差的原因不外乎： 深入了解JVM虛拟機10：JVM常用參數以及調優實踐 Java調優經驗談 - 大量的随機讀寫
- 裝置慢
- 檔案太大
-
網絡IO
檢視網絡io狀況，一般使用的是netstat工具。可以檢視所有連接配接的狀況、數目、端口資訊等。例如：當time_wait或者close_wait連接配接過多時，會影響應用的相應速度。
netstat -anp此外，還可以使用tcpdump來具體分析網絡io的資料。當然，tcpdump出的檔案直接打開是一堆二進制的資料，可以使用wireshark閱讀具體的連接配接以及其中資料的内容。 深入了解JVM虛拟機10：JVM常用參數以及調優實踐 Java調優經驗談
還可以通過檢視/proc/interrupts來擷取目前系統使用的中斷的情況。tcpdump -i eth0 -w tmp.cap -tnn dst port 8080 #監聽8080端口的網絡請求并列印日志到tmp.cap中各個列依次是： 深入了解JVM虛拟機10：JVM常用參數以及調優實踐 Java調優經驗談
通過檢視網卡裝置的終端情況可以判斷網絡io的狀況。irq的序号， 在各自cpu上發生中斷的次數，可程式設計中斷控制器，裝置名稱（request_irq的dev_name字段）
其他分析工具
上面分别針對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編譯友好麼？
此外，jdk7、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來講
-
啟動參數預設值
Java有很多的啟動參數，而且很多版本都并不一樣。但是現在網上充斥着各種資料，如果不加辨識的全部使用，很多是沒有效果或者本來就是預設值的。一般的，我們可以通過使用java -XX:+PrintFlagsInitial來檢視所有可以設定的參數以及其預設值。也可以在程式啟動的時候加入-XX:+PrintCommandLineFlags來檢視與預設值不相同的啟動參數。如果想檢視所有啟動參數(包括和預設值相同的)，可以使用-XX:+PrintFlagsFinal。
深入了解JVM虛拟機10：JVM常用參數以及調優實踐 Java調優經驗談 深入了解JVM虛拟機10：JVM常用參數以及調優實踐 Java調優經驗談 輸出裡“=”表示使用的是初始預設值，而“:=”表示使用的不是初始預設值，可能是指令行傳進來的參數、配置檔案裡的參數或者是ergonomics自動選擇了别的值。
此外，還可以使用jinfo指令顯示啟動的參數。
- jinfo -flags [pid] #檢視目前啟動使用的有效參數
- jinfo -flag [flagName] [pid] #檢視對應參數的值
-
動态設定參數
當Java應用啟動後，定位到了是GC造成的性能問題，但是你啟動的時候并沒有加入列印gc的參數，很多時候的做法就是重新加參數然後重新開機應用。但這樣會造成一定時間的服務不可用。最佳的做法是能夠在不重新開機應用的情況下，動态設定參數。使用jinfo可以做到這一點(本質上還是基于jmx的)。
對于上述的gc的情況，就可以使用以下指令打開heap dump并設定dump路徑。jinfo -flag [+/-][flagName] [pid] #啟用/禁止某個參數 jinfo -flag [flagName=value] [pid] #設定某個參數
同樣的也可以動态關閉。jinfo -flag +HeapDumpBeforeFullGC [pid] jinfo -flag +HeapDumpAfterFullGC [pid] jinfo -flag HeapDumpPath=/home/dump/dir [pid]
其他的參數設定類似。jinfo -flag -HeapDumpBeforeFullGC [pid] jinfo -flag -HeapDumpAfterFullGC [pid] -
-verbose:gc 與 -XX:+PrintGCDetails
很多gc推薦設定都同時設定了這兩個參數，其實，隻要打開了-XX:+PrintGCDetails，前面的選項也會同時打開，無須重複設定。
-
-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
-
MaxDirectMemorySize
此參數是設定的堆外記憶體的上限值。當不設定的時候為-1，此值為-Xmx減去一個survivor space的預留大小。
- 由于遺留原因，作用相同的參數
- -Xss 與 -XX:ThreadStackSize
- -Xmn 與 -XX:NewSize，此外這裡需要注意的是設定了-Xmn的話，NewRatio就沒作用了。
-
-XX:MaxTenuringThreshold
使用工具檢視此值預設值為15，但是選擇了CMS的時候，此值會變成4。當此值設定為0時，所有eden裡的活對象在經曆第一次minor GC的時候就會直接晉升到old gen，survivor space直接就沒用。還有值得注意的一點，當使用并行回收器時，此值是沒有作用的，并行回收器預設是自動調整這些參數以求達到吞吐量最大的。此外，即使是使用CMS等回收器，晉升到老年代的age也不是不變的，當某一age的對象的大小達到年輕代的50%時，這個age會被動态調整為晉升年齡。
-
-XX:HeapDumpPath
使用此參數可以指定-XX:+HeapDumpBeforeFullGC、-XX:+HeapDumpAfterFullGC、-XX:+HeapDumpOnOutOfMemoryError觸發heap dump檔案的存儲位置。
-
-XX:+UseAdaptiveSizePolicy
此參數在并行回收器時是預設開啟的，會根據應用運作狀況做自我調整，如MaxTenuringThreshold、survivor區大小等。其中第一次晉升老年代的年齡以InitialTenuringThreshold（預設為7）開始，後續會自動調整。如果希望跟蹤每次minor GC後新的存活周期的門檻值，可在啟動參數上增加：-XX:+PrintTenuringDistribution。如果想要可以配置這些參數，可以關閉此選項，但paralle的性能很難達到最佳。其他垃圾回收期則慎重開啟此開關。
微信公衆号
個人公衆号：程式員黃小斜
微信公衆号【程式員黃小斜】新生代青年聚集地，程式員成長充電站。作者黃小斜，職業是阿裡程式員，身份是斜杠青年，希望和更多的程式員交朋友，一起進步和成長！專注于分享技術、面試、職場等成長幹貨，這一次，我們一起出發。
關注公衆号後回複“2019”領取我這兩年整理的學習資料，涵蓋自學程式設計、求職面試、算法刷題、Java技術學習、計算機基礎和考研等8000G資料合集。
技術公衆号：Java技術江湖
微信公衆号【Java技術江湖】一位阿裡 Java 工程師的技術小站，專注于 Java 相關技術：SSM、SpringBoot、MySQL、分布式、中間件、叢集、Linux、網絡、多線程，偶爾講點Docker、ELK，同時也分享技術幹貨和學習經驗，緻力于Java全棧開發！
關注公衆号後回複“PDF”即可領取200+頁的《Java工程師面試指南》強烈推薦，幾乎涵蓋所有Java工程師必知必會的知識點。