Java自帶的效能監測工具用法簡介
https://blog.csdn.net/xad707348125/article/details/51985854
https://www.cnblogs.com/yjd_hycf_space/p/7755633.html
http://www.cnblogs.com/alipayhutu/archive/2012/08/20/2647353.html
問題： 發現jstat，jmap等命令不存在的
解決：
yum install java-1.8.0-openjdk-devel-debug問題： Unable to open socket file: target process not responding or HotSpot VM not loaded
Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
解決：
在用jstack工具檢視jvm執行緒的執行情況時出現上述錯誤。就是因為該程序長時間沒有啟停，在/tmp/hsperfdata_'username'/資料夾下的該程序檔案被Linux自身的機制（tmp下面不能存放很多檔案）刪除，需重新啟停。所以要注意/etc/cron.daily/tmpwatch改檔案在生產的情況。否則出現記憶體洩漏，或者記憶體溢位時，很難排查，或者出現系統執行緩慢時，想要觀察系統執行情況也沒辦法，再或者，想把現場儲存至dump檔案中，等待大神解決也不能做。
對線上伺服器的java應用dump操作時發現，以下報錯，不能dump。jps也獲取不到java程序的pid。
# jmap -dump:file=/data/dump/jvm_en.hprof 20176
20176: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
重啟後，jps可以獲得該java程序的pid，jstack也可以dump執行緒。
jps
- 檢視所有的jvm程序，包括程序ID，程序啟動的路徑等等。
- 我自己也用PS，即：ps -ef | grep java
jstack
- 觀察jvm中當前所有執行緒的執行情況和執行緒當前狀態。
- 系統崩潰了？如果java程式崩潰生成core檔案，jstack工具可以用來獲得core檔案的java stack和native stack的資訊，從而可以輕鬆地知道java程式是如何崩潰和在程式何處發生問題。
- 系統hung住了？jstack工具還可以附屬到正在執行的java程式中，看到當時執行的java程式的java stack和native stack的資訊, 如果現在執行的java程式呈現hung的狀態，jstack是非常有用的。
jstat
- jstat利用JVM內建的指令對Java應用程式的資源和效能進行實時的命令列的監控，包括了對程序的classloader，compiler，gc情況；
- 特別的，一個極強的監視記憶體的工具，可以用來監視VM記憶體內的各種堆和非堆的大小及其記憶體使用量，以及載入類的數量。
jmap
- 監視程序執行中的jvm物理記憶體的佔用情況，該程序記憶體內，所有物件的情況，例如產生了哪些物件，物件數量；
- 系統崩潰了？jmap 可以從core檔案或程序中獲得記憶體的具體匹配情況，包括Heap size, Perm size等等
jinfo
- 觀察程序執行環境引數，包括Java System屬性和JVM命令列引數
- 系統崩潰了？jinfo可以從core檔案裡面知道崩潰的Java應用程式的配置資訊。
jstat命令檢視jvm的GC情況 （以Linux為例）
jstat命令可以檢視堆記憶體各部分的使用量，以及載入類的數量。命令的格式如下：
jstat [-命令選項] [vmid] [間隔時間/毫秒] [查詢次數]
注意！！！：使用的jdk版本是jdk8.
類載入統計：
- Loaded:載入class的數量
- Bytes：所佔用空間大小
- Unloaded：未載入數量
- Bytes:未載入佔用空間
- Time：時間
編譯統計
- Compiled：編譯數量。
- Failed：失敗數量
- Invalid：不可用數量
- Time：時間
- FailedType：失敗型別
- FailedMethod：失敗的方法
垃圾回收統計
- S0C：第一個倖存區的大小
- S1C：第二個倖存區的大小
- S0U：第一個倖存區的使用大小
- S1U：第二個倖存區的使用大小
- EC：伊甸園區的大小
- EU：伊甸園區的使用大小
- OC：老年代大小
- OU：老年代使用大小
- MC：方法區大小
- MU：方法區使用大小
- CCSC:壓縮類空間大小
- CCSU:壓縮類空間使用大小
- YGC：年輕代垃圾回收次數
- YGCT：年輕代垃圾回收消耗時間
- FGC：老年代垃圾回收次數
- FGCT：老年代垃圾回收消耗時間
- GCT：垃圾回收消耗總時間
堆記憶體統計
- NGCMN：新生代最小容量
- NGCMX：新生代最大容量
- NGC：當前新生代容量
- S0C：第一個倖存區大小
- S1C：第二個倖存區的大小
- EC：伊甸園區的大小
- OGCMN：老年代最小容量
- OGCMX：老年代最大容量
- OGC：當前老年代大小
- OC:當前老年代大小
- MCMN:最小元資料容量
- MCMX：最大元資料容量
- MC：當前元資料空間大小
- CCSMN：最小壓縮類空間大小
- CCSMX：最大壓縮類空間大小
- CCSC：當前壓縮類空間大小
- YGC：年輕代gc次數
- FGC：老年代GC次數
新生代垃圾回收統計
- S0C：第一個倖存區大小
- S1C：第二個倖存區的大小
- S0U：第一個倖存區的使用大小
- S1U：第二個倖存區的使用大小
- TT:物件在新生代存活的次數
- MTT:物件在新生代存活的最大次數
- DSS:期望的倖存區大小
- EC：伊甸園區的大小
- EU：伊甸園區的使用大小
- YGC：年輕代垃圾回收次數
- YGCT：年輕代垃圾回收消耗時間
新生代記憶體統計
- NGCMN：新生代最小容量
- NGCMX：新生代最大容量
- NGC：當前新生代容量
- S0CMX：最大幸存1區大小
- S0C：當前倖存1區大小
- S1CMX：最大幸存2區大小
- S1C：當前倖存2區大小
- ECMX：最大伊甸園區大小
- EC：當前伊甸園區大小
- YGC：年輕代垃圾回收次數
- FGC：老年代回收次數
老年代垃圾回收統計
- MC：方法區大小
- MU：方法區使用大小
- CCSC:壓縮類空間大小
- CCSU:壓縮類空間使用大小
- OC：老年代大小
- OU：老年代使用大小
- YGC：年輕代垃圾回收次數
- FGC：老年代垃圾回收次數
- FGCT：老年代垃圾回收消耗時間
- GCT：垃圾回收消耗總時間
老年代記憶體統計
- OGCMN：老年代最小容量
- OGCMX：老年代最大容量
- OGC：當前老年代大小
- OC：老年代大小
- YGC：年輕代垃圾回收次數
- FGC：老年代垃圾回收次數
- FGCT：老年代垃圾回收消耗時間
- GCT：垃圾回收消耗總時間
元資料空間統計
- MCMN: 最小元資料容量
- MCMX：最大元資料容量
- MC：當前元資料空間大小
- CCSMN：最小壓縮類空間大小
- CCSMX：最大壓縮類空間大小
- CCSC：當前壓縮類空間大小
- YGC：年輕代垃圾回收次數
- FGC：老年代垃圾回收次數
- FGCT：老年代垃圾回收消耗時間
- GCT：垃圾回收消耗總時間
總結垃圾回收統計
- S0：倖存1區當前使用比例
- S1：倖存2區當前使用比例
- E：伊甸園區使用比例
- O：老年代使用比例
- M：元資料區使用比例
- CCS：壓縮使用比例
- YGC：年輕代垃圾回收次數
- FGC：老年代垃圾回收次數
- FGCT：老年代垃圾回收消耗時間
- GCT：垃圾回收消耗總時間
JVM編譯方法統計
- Compiled：最近編譯方法的數量
- Size：最近編譯方法的位元組碼數量
- Type：最近編譯方法的編譯型別。
- Method：方法名標識。