（1）第一可以通過 top -Hp PID , jstack PID等查看占用CPU資源過高的線程是哪些？可能會看到是GC線程。
或者是其他線程，如果是GC線程，那么jstat查看JVM垃圾回收器工作的情況。如果是其他業務線程，可能需要跟蹤棧信息，追蹤到代碼中進行分析。（可能是一直循環處理業務，數據量大，處理耗時。）
-- 業務線程導致CPU高的場景，沒有關注過，不知道我的理解對不對。
（2）查看JVM垃圾回收情況相關的信息
YoungGC頻率，YoungGC耗時，每次GC過后Eden+S0區的垃圾回收情況；進入老年代的大小
FullGC頻率，YoungGC耗時，每次GC過后老年代的垃圾回收情況；
我的總結：
（1）如果是YoungGC，FullGC頻繁，但是每次FullGC回收之后，垃圾回收率很高，可能就是高並發引起的；要關注下是不是年輕代內存分配不合理，是否需要加大JVM堆內存。升級機器等。根據YoungGC每次進入老年代的大小，重新預估一下，新生代需要分配多大的內存比較合適，來解決這個高並發引起的FullGC問題。
（2）如果FullGC之后，回收的內存時多時少，或者說很少，甚至可能出現連續的1-3次，回收之后，老年代剩余空間是在增長的，這個時候就要排除是否有發生內存泄漏的嫌疑。或者說高並發引起的問題導致對象無法被回收。這時候一般需要dump下內存快照，使用MAT工具分析內存快照，可以短時間連續dump兩次，對比兩次內存快照，查看哪些對象不斷在增長。這些對象是不是大對象，因為並發問題無法被及時回收，JVM處在OOM邊緣。然后根據派排查結果，優化代碼問題。
優化JVM參數：
（1）優化新生代和老年代的占比。盡量保證每次YoungGC之后。可以打印對內存信息，計算一下一般存活對象是多大。假設是100M。那么可以將S0設置成 S0 * 50% = 100M。 S0大概需要200M。這樣就可以把Eden和老年代大小預估出來了，一般業務系統。老年代分配1至2G就可以了。
（2）需要開啟CMS垃圾回收器的對內存碎片進行整理。一般每次FullGC都整理一遍最好。
（3）-XX:CMSInitiatingOccupancyFraction=92。老年代占用92%以上發生FullGC。一般這個值我覺得偏大了，如果是高並發系統，會有較大可能出現Concurrent Mode Failure。所以我對CMS設置的時候，會把老年代預留空間大小預估到S0區大小這樣。一般設置80%。對於這點不知道是否合理？
（4）還會設置一些額外的參數：-XX:-OmitStackTraceInFastThrow
還有打印GC日志，發生OOM的時候dump內存快照參數。
（5）還有一點，如果沒有發生什么特殊的問題，不會對其他的參數進行優化。能簡單設置就采用簡單的設置。
轉載，如有侵權，請聯系刪除。