轉載請注明原創出處，謝謝！
今天在JVMPocket群里面看見，阿牛發了一個gc截圖，之后ak47截圖了
特別恐怖，我就覺得好奇，去看看服務情況，截圖日志如下
關於jstat命令詳情可以參考：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html
高手就是高手，就通過這個，直接提出1，就是達到old的92%的閾值了 不斷做cms gc 2.估計是不斷做system gc這些都是猜測，讓執行
jstat -gccause pid 看看情況，為什么說要執行gccause呢？
尤其ygc沒有，只有fgc，那gccause出來的一定就是我們想要的
如果有ygc，這個命令就不好用了，很容易吧我們想要的東西覆蓋
看看jstat的說明
Jstat是JDK自帶的一個輕量級小工具。全稱“Java Virtual Machine statistics monitoring tool”，它位於Java的bin目錄下，主要利用JVM內建的指令對Java應用程序的資源和性能進行實時的命令行的監控，包括了對Heap size和垃圾回收狀況的監控。可見，Jstat是輕量級的、專門針對JVM的工具，非常適用。
jstat工具特別強大，有眾多的可選項，詳細查看堆內各個部分的使用量，以及加載類的數量。使用時，需加上查看進程的進程id，和所選參數。參考格式如下：
jstat -options
可以列出當前JVM版本支持的選項，常見的有
l class (類加載器)
l compiler (JIT)
l gc (GC堆狀態)
l gccapacity (各區大小)
l gccause (最近一次GC統計和原因)
l gcnew (新區統計)
l gcnewcapacity (新區大小)
l gcold (老區統計)
l gcoldcapacity (老區大小)
l gcpermcapacity (永久區大小)
l gcutil (GC統計匯總)
l printcompilation (HotSpot編譯統計)
通過這個就排除了是執行system gc
在通過jstat -gc pid 查看gc堆狀態
看到這里大家應該都看出問題了，我靠什么情況，old512K
把jvm參數貼出：
-Xms2048m
-Xmx5120m
-XX:MaxNewSize=5120m
-XX:PermSize=4096M
-XX:-HeapDumpOnOutOfMemoryError
-XX:MaxPermSize=3072m
-Xmx5120m MaxNewSize=5120m old就沒有空間了
修改參數
-Xms5120m
-Xmx5120m
-Xmn1512M
-XX:PermSize=128M
-XX:MaxPermSize=512M
-XX:-HeapDumpOnOutOfMemoryError
再觀察情況，
jstat -gcutil pid 3s 30，看一下90s內ygc次數和ygct的時間變化
完美，一次0.005，才5ms
有個參數可以把ygc耗時花在哪里打出來
剛剛說的那個參數是：-XX:+PrintGCApplicationStoppedTime
該參數如何參考，查看呢？ 在微信小程序里面搜索：JVMPocket，這個小程序是笨神大大提供的
結果如下：
萬能的好工具！！！！
這幾個參數建議也加上去:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/log/gclog/
-Xloggc:/data/log/gclog/gc.log
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly顯示申明cms+ParNew，設定old區75%時就回收
但是應用啟動前需要提前創建目錄/data/log/gclog/
參數不明白啥意思 去搜索微信小程序
最后感謝笨神，感謝阿飛！
個人公眾號
