前言

填別人留下來的坑其實挺無奈的，會被搞的特別煩，特別是我這種要填三四個人留下來的坑的時候，滿滿的都是無奈。

幸好的是填坑也可以選擇一種更能提升自己的方式來填。

這次遇到的一個程式，是一個從kafka消費並且插入mysql的程式，該程式歷經三人之手，頻頻出問題，一直沒有被解決。傳到現在，症狀是這樣的：該程式跑個兩三天後會莫名其妙的停止消費，不再插入資料了，據說也不報錯，程序還在，反正就是不幹活了。

分析過程

等了一天半，這個程式不出意料的出問題了，狀況依然是停止消費，不再插入資料。我不太清楚之前的人是怎麼排查的，暫時按照我自己的方式來摸索。

首先看一下jvm記憶體的分佈情況，一下子就看到點子上了。old區和perm區基本上都滿了，然後可以觀察到每隔幾秒鐘就會進行一次full gc。這樣的話，整個程式不是一直都在full gc了，哪還有心情幹別的活？

抓緊時間看一下程式的報錯，非常明顯的OOM問題，不曉得之前的童鞋找到這沒。

按理說看到程式出錯了就該趕快補資料了，但是為了抓住錯誤的本質，我只能頂住一些壓力，緩半個小時再說，抓緊時間看一下各個指標。

首先是top一下看看cpu和記憶體，pid是25729那隻，貌似壓力很大的樣子。

然後是jmap看一下各個區的情況。仔細看一下就會發現，在Old Generation區已經佔用了2.6G的大小了，這個應該是十分不正常的。

這時候第一反應就是看一下垃圾回收用的什麼，嗯，ParallelGc，按說也沒啥問題啊，我可能也就是用這個了。

這時候無意間發現了jstat的一個引數gccause

然後我就想匯出堆疊的資訊，然後分析一下，但是太大了，有4G的大小，我的筆記本根本打不開。所以只能先用jcmd看一下，就發現了了一些比較好玩的東西。排在前面的這倆JDBC是啥麼個意思。

其實追到這裡基本已經可以定位到程式裡面的問題了，和關閉statment有關。

但是我們不能到此就結束，為了證明我是愛學習的，我用eclipse的的視覺化分析工具，打開了jmap匯出的檔案，具體怎麼匯出的可以參考這篇：http://zhaodedong.com/2015/09/01/jvm-tools/。

有個工具就是方便很多，首先就可以定位到到底是哪裡佔用了這麼的記憶體。然後就追呀追，果真還是學到了點東西。

看下面這個圖，首先程式裡面是用的inset語句，但是會有很多的ResultSet物件，然後我就挨個進去看了ResultSet裡面有什麼東西，發現都是要插入的資料，我一直以為JDBC只有在獲取結果的時候才會用ResultSet，沒想到插入資料同樣用的這個。

總結

jdk的各種工具我一直都有筆記做過記錄，但是沒有做過比較多的分析，趁此機會就詳細的挨個用了一遍。

個人感覺，其實在分析問題的時候還是需要一定的敏感度的，光知道工具是沒有用的，必須還要有對問題的敏感度，能夠明白每個工具獲得的結果有什麼用，哪些結果資料是不正常的。這點其實十分重要，至少我在分析之初是很懵的，看著一堆資料完全不知道怎麼下手，後來看了不少的文章也問了一些同事之後才把這些搞明白。

補充

本著嘗試的原則，我也嘗試jvm引數調優實踐。發現還是有效果的，至少多堅持的更久的時間程式都沒有出問題。但是由於沒有抓住問題的核心錯誤，依舊不是解決問題的方法。

nohup java -classpath $CLASS_PATH com.***.Consumer -Xms1024M -Xmx6000M -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+UseParallelGC XX:+UseParallelOldGC &

2016-09-22 00:14:00 rljp

轉載請註明： 轉載自趙德棟的 個人主頁 CSDN部落格

作者：趙德棟，作者介紹