一次線上死循環的排查

一、問題發現

      Prometheus報警某服務的一個節點 Old GC過多，須要排查。

二、查看GC日誌

      使用tail -f gc.log命令查看異常節點的GC日誌，從日誌能夠看出Young GC過於頻繁，居然在1s內有9次Young GC：

      使用tail -f gc.log命令查看正常節點的GC日誌，從日誌能夠看出，正常節點，好久才進行一次Young GC：

      兩個節點的JVM參數配置是徹底同樣的，而且負載均衡策略使用的是Ribbon默認的輪詢策略，也就是說，兩個節點可以接受到的請求是均衡的，不存在一個節點比另外一個階段負載大的狀況。
      使用jstat命令查看異常節點的Young GC頻率，發現確實存在異常：

三、使用jps命令找出該應用進程的pid，再使用top -Hp pid命令查看該進程下佔用CPU最多的線程id：

四、將查到的線程id 9182，使用printf "%x\n" 9182命令，轉換爲16進制：

五、使用jstack 9088 | grep 23de -A 30命令查看堆棧信息（屢次查看）：

      第一次：

      第二次：

      該線程一直處於Running狀態，而且兩次查看中發現，堆棧中有共同的方法調用，懷疑問題可能發生在RedPackUtilV3.java:169處，須要查看業務同窗代碼。

六、查看業務同窗代碼

發現極有多是while循環中break條件一直沒成立，致使了死循環，最後就請業務同窗本身檢查代碼邏輯了。