一、jvm內存調優

主要的目的是減小GC的頻率和Full GC的次數。

1.Full GC

會對整個堆進行整理，包括Young、Tenured和Perm。Full GC由于須要對整個堆進行回收，因此比較慢，所以應該盡量減小Full GC的次數。數組

2.致使Full GC的緣由緩存

1)年老代（Tenured）被寫滿服務器
調優時盡可能讓對象在新生代GC時被回收、讓對象在新生代多存活一段時間和不要建立過大的對象及數組避免直接在舊生代建立對象 。并發
2)持久代Pemanet Generation空間不足jvm
增大Perm Gen空間，避免太多靜態對象 ， 控制好新生代和舊生代的比例高并發
3)System.gc()被顯示調用工具
垃圾回收不要手動觸發，盡可能依靠JVM自身的機制

在對JVM調優的過程當中，很大一部分工做就是對于FullGC的調節，下面詳細介紹對應JVM調優的方法和步驟。

二、jvm性能調優工具及思路(重要)—面試必看

2.1.JVM調優參數參考

1.針對JVM堆的設置，通常能夠經過-Xms -Xmx限定其最小、最大值，為了防止垃圾收集器在最小、最大之間收縮堆而產生額外的時間，一般把最大、最小設置為相同的值;
2.年輕代和年老代將根據默認的比例（1：2）分配堆內存， 能夠經過調整兩者之間的比率NewRadio來調整兩者之間的大小，也能夠針對回收代。
好比年輕代，經過 -XX:newSize -XX:MaxNewSize來設置其絕對大小。一樣，為了防止年輕代的堆收縮，咱們一般會把-XX:newSize -XX:MaxNewSize設置為一樣大小。
3.年輕代和年老代設置多大才算合理
1）更大的年輕代必然致使更小的年老代，大的年輕代會延長普通GC的周期，但會增長每次GC的時間；小的年老代會致使更頻繁的Full GC
2）更小的年輕代必然致使更大年老代，小的年輕代會致使普通GC很頻繁，但每次的GC時間會更短；大的年老代會減小Full GC的頻率
如何選擇應該依賴應用程序對象生命周期的分布狀況： 若是應用存在大量的臨時對象，應該選擇更大的年輕代；若是存在相對較多的持久對象，年老代應該適當增大。但不少應用都沒有這樣明顯的特性。
在抉擇時應該根 據如下兩點：
（1）本著Full GC盡可能少的原則，讓年老代盡可能緩存經常使用對象，JVM的默認比例1：2也是這個道理 。
（2）經過觀察應用一段時間，看其余在峰值時年老代會占多少內存，在不影響Full GC的前提下，根據實際狀況加大年輕代，好比能夠把比例控制在1：1。但應該給年老代至少預留1/3的增加空間。
4.在配置較好的機器上（好比多核、大內存），能夠為年老代選擇并行收集算法： -XX:+UseParallelOldGC 。
5.線程堆棧的設置：每一個線程默認會開啟1M的堆棧，用于存放棧幀、調用參數、局部變量等，對大多數應用而言這個默認值太了，通常256K就足用。
理論上，在內存不變的狀況下，減小每一個線程的堆棧，能夠產生更多的線程，但這實際上還受限于操做系統。

2.2.調優工具之jps(Java Virtual Machine Process Status Tool)

jps主要用來輸出JVM中運行的進程狀態信息。語法格式如下：

jps [options] [hostid]

如果不指定hostid就默認為當前主機或服務器。
命令行參數選項說明如下：

-q 不輸出類名、Jar名和傳入main方法的參數
-m 輸出傳入main方法的參數
-l 輸出main類或Jar的全限名
-v 輸出傳入JVM的參數

比如下面：

root@ubuntu:/# jps -m -l2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2.2.5/etc/jetty.xml29920 com.sun.tools.hat.Main -port 9998 /tmp/dump.dat3149 org.apache.catalina.startup.Bootstrap start30972 sun.tools.jps.Jps -m -l8247 org.apache.catalina.startup.Bootstrap start25687 com.sun.tools.hat.Main -port 9999 dump.dat21711 mrf-center.jar

2.3.調優工具之jstack

jstack主要用來查看某個Java進程內的線程堆棧信息。語法格式如下：

jstack [option] pid

jstack [option] executable core

jstack [option] [server-id@]remote-hostname-or-ip

命令行參數選項說明如下：

-l long listings，會打印出額外的鎖信息，在發生死鎖時可以用jstack -l pid來觀察鎖持有情況
-m mixed mode，不僅會輸出Java堆棧信息，還會輸出C/C++堆棧信息（比如Native方法）

jstack可以定位到線程堆棧，根據堆棧信息我們可以定位到具體代碼，所以它在JVM性能調優中使用得非常多。下面我們來一個實例找出某個Java進程中最耗費CPU的Java線程并定位堆棧信息，用到的命令有ps、top、printf、jstack、grep。

第一步先找出Java進程ID，我部署在服務器上的Java應用名稱為mrf-center：

root@ubuntu:/# ps -ef | grep mrf-center | grep -v grep

root     21711     1  1 14:47 pts/3    00:02:10 java -jar mrf-center.jar

得到進程ID為21711，第二步找出該進程內最耗費CPU的線程，可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid，我這里用第三個，輸出如下：

TIME列就是各個Java線程耗費的CPU時間，CPU時間最長的是線程ID為21742的線程，用

printf "%x/n" 21742

得到21742的十六進制值為54ee，下面會用到。

OK，下一步終于輪到jstack上場了，它用來輸出進程21711的堆棧信息，然后根據線程ID的十六進制值grep，如下：

root@ubuntu:/# jstack 21711 | grep 54ee

"PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000]

可以看到CPU消耗在PollIntervalRetrySchedulerThread這個類的Object.wait()，我找了下我的代碼，定位到下面的代碼：

// Idle waitgetLog().info("Thread [" + getName() + "] is idle waiting...");schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;long now = System.currentTimeMillis();long waitTime = now + getIdleWaitTime();long timeUntilContinue = waitTime - now;synchronized(sigLock) {    try {        if(!halted.get()) {            sigLock.wait(timeUntilContinue);        }    }    catch (InterruptedException ignore) {    }}

它是輪詢任務的空閑等待代碼，上面的sigLock.wait(timeUntilContinue)就對應了前面的Object.wait()。

2.4.調優工具之jmap(Memory Map)和jhat(Java Heap Analysis Tool)

jmap用來查看堆內存使用狀況，一般結合jhat使用。

jmap語法格式如下：

jmap [option] pid

jmap [option] executable core

jmap [option] [server-id@]remote-hostname-or-ip

如果運行在64位JVM上，可能需要指定-J-d64命令選項參數。

jmap -permstat pid

打印進程的類加載器和類加載器加載的持久代對象信息，輸出：類加載器名稱、對象是否存活（不可靠）、對象地址、父類加載器、已加載的類大小等信息，如下圖：

使用jmap -heap pid查看進程堆內存使用情況，包括使用的GC算法、堆配置參數和各代中堆內存使用情況。比如下面的例子：

root@ubuntu:/# jmap -heap 21711Attaching to process ID 21711, please wait...Debugger attached successfully.Server compiler detected.JVM version is 20.10-b01 using thread-local object allocation.Parallel GC with 4 thread(s) Heap Configuration:   MinHeapFreeRatio = 40   MaxHeapFreeRatio = 70   MaxHeapSize      = 2067791872 (1972.0MB)   NewSize          = 1310720 (1.25MB)   MaxNewSize       = 17592186044415 MB   OldSize          = 5439488 (5.1875MB)   NewRatio         = 2   SurvivorRatio    = 8   PermSize         = 21757952 (20.75MB)   MaxPermSize      = 85983232 (82.0MB) Heap Usage:PS Young GenerationEden Space:   capacity = 6422528 (6.125MB)   used     = 5445552 (5.1932830810546875MB)   free     = 976976 (0.9317169189453125MB)   84.78829520089286% usedFrom Space:   capacity = 131072 (0.125MB)   used     = 98304 (0.09375MB)   free     = 32768 (0.03125MB)   75.0% usedTo Space:   capacity = 131072 (0.125MB)   used     = 0 (0.0MB)   free     = 131072 (0.125MB)   0.0% usedPS Old Generation   capacity = 35258368 (33.625MB)   used     = 4119544 (3.9287033081054688MB)   free     = 31138824 (29.69629669189453MB)   11.683876009235595% usedPS Perm Generation   capacity = 52428800 (50.0MB)   used     = 26075168 (24.867218017578125MB)   free     = 26353632 (25.132781982421875MB)   49.73443603515625% used   ....

使用jmap -histo[:live] pid查看堆內存中的對象數目、大小統計直方圖，如果帶上live則只統計活對象，如下：

root@ubuntu:/# jmap -histo:live 21711 | more  num     #instances         #bytes  class name----------------------------------------------   1:         38445        5597736  <constMethodKlass>   2:         38445        5237288  <methodKlass>   3:          3500        3749504  <constantPoolKlass>   4:         60858        3242600  <symbolKlass>   5:          3500        2715264  <instanceKlassKlass>   6:          2796        2131424  <constantPoolCacheKlass>   7:          5543        1317400  [I   8:         13714        1010768  [C   9:          4752        1003344  [B  10:          1225         639656  <methodDataKlass>  11:         14194         454208  java.lang.String  12:          3809         396136  java.lang.Class  13:          4979         311952  [S  14:          5598         287064  [[I  15:          3028         266464  java.lang.reflect.Method  16:           280         163520  <objArrayKlassKlass>  17:          4355         139360  java.util.HashMap$Entry  18:          1869         138568  [Ljava.util.HashMap$Entry;  19:          2443          97720  java.util.LinkedHashMap$Entry  20:          2072          82880  java.lang.ref.SoftReference  21:          1807          71528  [Ljava.lang.Object;  22:          2206          70592  java.lang.ref.WeakReference  23:           934          52304  java.util.LinkedHashMap  24:           871          48776  java.beans.MethodDescriptor  25:          1442          46144  java.util.concurrent.ConcurrentHashMap$HashEntry  26:           804          38592  java.util.HashMap  27:           948          37920  java.util.concurrent.ConcurrentHashMap$Segment  28:          1621          35696  [Ljava.lang.Class;  29:          1313          34880  [Ljava.lang.String;  30:          1396          33504  java.util.LinkedList$Entry  31:           462          33264  java.lang.reflect.Field  32:          1024          32768  java.util.Hashtable$Entry  33:           948          31440  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;

class name是對象類型，說明如下：

B  byteC  charD  doubleF  floatI  intJ  longZ  boolean[  數組，如[I表示int[][L+類名 其他對象

還有一個很常用的情況是：用jmap把進程內存使用情況dump到文件中，再用jhat分析查看。jmap進行dump命令格式如下：

jmap -dump:format=b,file=dumpFileName pid

我一樣地對上面進程ID為21711進行Dump：

root@ubuntu:/# jmap -dump:format=b,file=/tmp/dump.dat 21711  

Dumping heap to /tmp/dump.dat ...

Heap dump file created

dump出來的文件可以用MAT、VisualVM等工具查看，這里用jhat查看：

root@ubuntu:/# jhat -port 9998 /tmp/dump.datReading from /tmp/dump.dat...Dump file created Tue Jan 28 17:46:14 CST 2014Snapshot read, resolving...Resolving 132207 objects...Chasing references, expect 26 dots..........................Eliminating duplicate references..........................Snapshot resolved.Started HTTP server on port 9998Server is ready

注意如果Dump文件太大，可能需要加上-J-Xmx512m這種參數指定最大堆內存，即jhat -J-Xmx512m -port 9998 /tmp/dump.dat。然后就可以在瀏覽器中輸入主機地址:9998查看了：

上面紅線框出來的部分大家可以自己去摸索下，最后一項支持OQL（對象查詢語言）

2.5.jstat（JVM統計監測工具）

語法格式如下：

jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

vmid是Java虛擬機ID，在Linux/Unix系統上一般就是進程ID。interval是采樣時間間隔。count是采樣數目。比如下面輸出的是GC信息，采樣時間間隔為250ms，采樣數為4：

root@ubuntu:/# jstat -gc 21711 250 4 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT  192.0  192.0   64.0   0.0    6144.0   1854.9   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649192.0  192.0   64.0   0.0    6144.0   2109.7   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

要明白上面各列的意義，先看JVM堆內存布局：

可以看出：

堆內存 = 年輕代 + 年老代 + 永久代
年輕代 = Eden區 + 兩個Survivor區（From和To）

現在來解釋各列含義：

S0C、S1C、S0U、S1U：Survivor 0/1區容量（Capacity）和使用量（Used）
EC、EU：Eden區容量和使用量
OC、OU：年老代容量和使用量
PC、PU：永久代容量和使用量
YGC、YGT：年輕代GC次數和GC耗時
FGC、FGCT：Full GC次數和Full GC耗時
GCT：GC總耗時

2.6.hprof（Heap/CPU Profiling Tool）

hprof能夠展現CPU使用率，統計堆內存使用情況。

語法格式如下：

java -agentlib:hprof[=options] ToBeProfiledClass

java -Xrunprof[:options] ToBeProfiledClass

javac -J-agentlib:hprof[=options] ToBeProfiledClass

完整的命令選項如下：

Option Name and Value  Description                    Default---------------------  -----------                    -------heap=dump|sites|all    heap profiling                 allcpu=samples|times|old  CPU usage                      offmonitor=y|n            monitor contention             nformat=a|b             text(txt) or binary output     afile=<file>            write data to file             java.hprof[.txt]net=<host>:<port>      send data over a socket        offdepth=<size>           stack trace depth              4interval=<ms>          sample interval in ms          10cutoff=<value>         output cutoff point            0.0001lineno=y|n             line number in traces?         ythread=y|n             thread in traces?              ndoe=y|n                dump on exit?                  ymsa=y|n                Solaris micro state accounting nforce=y|n              force output to <file>         yverbose=y|n            print messages about dumps     y

來幾個官方指南上的實例。

CPU Usage Sampling Profiling(cpu=samples)的例子：

java -agentlib:hprof=cpu=samples,interval=20,depth=3 Hello

上面每隔20毫秒采樣CPU消耗信息，堆棧深度為3，生成的profile文件名稱是java.hprof.txt，在當前目錄。

CPU Usage Times Profiling(cpu=times)的例子，它相對于CPU Usage Sampling Profile能夠獲得更加細粒度的CPU消耗信息，能夠細到每個方法調用的開始和結束，它的實現使用了字節碼注入技術（BCI）：

javac -J-agentlib:hprof=cpu=times Hello.java

Heap Allocation Profiling(heap=sites)的例子：

javac -J-agentlib:hprof=heap=sites Hello.java

Heap Dump(heap=dump)的例子，它比上面的Heap Allocation Profiling能生成更詳細的Heap Dump信息：

javac -J-agentlib:hprof=heap=dump Hello.java

雖然在JVM啟動參數中加入-Xrunprof:heap=sites參數可以生成CPU/Heap Profile文件，但對JVM性能影響非常大，不建議在線上服務器環境使用。

2.7.jconsole、jvisualvm

利用jconsole、jvisualvm分析內存信息(各個區如Eden、Survivor、Old等內存變化情況)，如果查看的是遠程服務器的JVM，程序啟動需要加上如下參數：

"-Dcom.sun.management.jmxremote=true" "-Djava.rmi.server.hostname=12.34.56.78" "-Dcom.sun.management.jmxremote.port=18181" "-Dcom.sun.management.jmxremote.authenticate=false" "-Dcom.sun.management.jmxremote.ssl=false"

下圖是jconsole界面，概覽選項可以觀測堆內存使用量、線程數、類加載數和CPU占用率；內存選項可以查看堆中各個區域的內存使用量和左下角的詳細描述（內存大小、GC情況等）；線程選項可以查看當前JVM加載的線程，查看每個線程的堆棧信息，還可以檢測死鎖；VM概要描述了虛擬機的各種詳細參數。（jconsole功能演示）

下圖是jvisualvm的界面，功能比jconsole略豐富一些，不過大部分功能都需要安裝插件。概述跟jconsole的VM概要差不多，描述的是jvm的詳細參數和程序啟動參數；監視展示的和jconsole的概覽界面差不多（CPU、堆/方法區、類加載、線程）；線程和jconsole的線程界面差不多；抽樣器可以展示當前占用內存的類的排行榜及其實例的個數；Visual GC可以更豐富地展示當前各個區域的內存占用大小及歷史信息（下圖）(jvisualvm功能演示）

工具路徑：//java/jdk1.8xxx/bin/JVisuaVM.exe

監控本地的Tomcat
監控遠程Tomcat
監控普通的JAVA進程

這個有不懂得可以看此文:如何利用 JConsole觀察分析Java程序的運行，進行排錯調優

2.8.jinfo

jinfo命令主要用于查看應用程序的配置參數，以及打印運行JVM時候所指定的JVM參數。jinfo可以使用-sysprops選項將虛擬機進程中所指定的System.getProperties()的內容打印出來，并且該命令還可以查看未被顯示指定的JVM參數的系統默認值，這通過jps -v是無法看到的。同時jinfo命令還能夠在運行期修改JVM參數，通過使用 -flag name=value 或者 -flag [+|-]name 來修改一部分運行期可修改的虛擬機參數

其他的一些工具如BTrace、Reference等有興趣可以自己查下資料的

2.9.依賴、參考的數據有系統運行日志、堆棧錯誤信息、gc日志、線程快照、堆轉儲快照進行調優

此處參考大佬的文章:JVM性能調優 倒也不失為一種思路 大家可根據自己業務場景或者其他因素進行篩選使用

①系統運行日志：系統運行日志就是在程序代碼中打印出的日志，描述了代碼級別的系統運行軌跡（執行的方法、入參、返回值等），一般系統出現問題，系統運行日志是首先要查看的日志。

②堆棧錯誤信息：當系統出現異常后，可以根據堆棧信息初步定位問題所在，比如根據“java.lang.OutOfMemoryError: Java heap space”可以判斷是堆內存溢出；根據“java.lang.StackOverflowError”可以判斷是棧溢出；根據“java.lang.OutOfMemoryError: PermGen space”可以判斷是方法區溢出等。
③GC日志：程序啟