1、問題發現
Prometheus報警某服務的一個節點 Old GC過多，需要排查。
2、查看GC日志
使用tail -f gc.log命令查看異常節點的GC日志，從日志可以看出Young GC過於頻繁，竟然在1s內有9次Young GC：
使用tail -f gc.log命令查看正常節點的GC日志，從日志可以看出，正常節點，很久才進行一次Young GC：
兩個節點的JVM參數配置是完全一樣的，並且負載均衡策略使用的是Ribbon默認的輪詢策略，也就是說，兩個節點能夠接受到的請求是均衡的，不存在一個節點比另一個階段負載大的情況。
使用jstat命令查看異常節點的Young GC頻率，發現確實存在異常：
3、使用jps命令找出該應用進程的pid，再使用top -Hp pid命令查看該進程下占用CPU最多的線程id：
4、將查到的線程id 9182，使用printf "%x\n" 9182命令，轉換為16進制：
5、使用jstack 9088 | grep 23de -A 30命令查看堆棧信息（多次查看）：
第一次：
第二次：
該線程一直處於Running狀態，並且兩次查看中發現，堆棧中有共同的方法調用，懷疑問題可能發生在RedPackUtilV3.java:169處，需要查看業務同學代碼。
6、查看業務同學代碼
發現極有可能是while循環中break條件一直沒成立，導致了死循環，最后就請業務同學自己檢查代碼邏輯了。