2016年3月21日，凌晨2點多開始QQ郵箱收到幾十封測試報警郵件，是在應該內自己通過切面做的關於Cassandra操作出現問題的報警。內容如下：
打開了手機客戶端，試了下發現，沒問題。而Cassandra最容易出問題的地方是網絡，看了下，測試的兩個服務有一臺在同一個物理機房，一臺不在，所以懷疑是網絡連接導致的某種阻塞，然後導致內存溢出。（PS:這是一個合乎邏輯但錯誤的判斷，當時並沒有去驗證這種假設是否成立。驗證方式很簡單，看看兩臺機器是否都存在對應的異常。）
當時聯繫了早晨即將到公司的小A，並且說：Cassandra可能出問題了。（看着黑乎乎的郵件標題，第一反應是這個。） 小A查看了Cassandra的日誌和內存之後發現，並沒有內存不足的情況。分配給jvm的內存還有一大半沒有使用。
10點鐘我到公司後，分析報的錯全是java heap space.從新整理了思路，查看了不同keyspace的節點狀態，沒有任何異常，看完之後發現，正式環境一點錯沒有，那麼測試環境出問題，更是由於測試環境的網絡什麼的導致的了，在這裏又想當然了。
之後，客戶端開發人員陸續反應，測試環境出問題了，（慶幸一下，問題是自己先發現的），於是，11點左右，重啓了對應的模塊。
Everything is 看起來 ok!
中午吃過飯後，下午2點做一個技術分享。。正在聽，突然就被小B攔住了，說服務怎麼Blabla...,我一看，日誌這次沒有javaheapspace，卻在報：
NoHostAvailableException，這必然是網絡問題了啊，花了一個多小時，查看各種資料：
於是乎，重啓服務，發現Everything is 再一次看起來OK!
之後，做了些別的業務，直到晚上吃飯的時候，服務再次無法用。。內心深處當時的感慨依然是網絡不至於這麼差勁吧，之前怎麼沒有類似的情況。
飯後，回來看，發現兩臺對應服務的機器處於不同的機房，但是那臺處於同一個物理機房的機器也在報NoHostAvailableException...
於是這個時候查看了對應進程的情況，發現CPU失蹤處於100%，雖然有16核，於是查看了對應的線程日誌以及java heap的使用情況。。發現某個對象在heap中佔用量極其大，new generation始終是滿的。分配的空間完全不夠用。
查看了這個對象的邏輯，以及對應的數據，發現，這個邏輯竟然在不停的取200萬的數據在處理，而且是個Cron job，每小時一次。。（小A乾的！）
覈對數據庫的數據返現，這些測試數據的時間的確有問題，很大部分的竟然集中在了這一天。。。對應的語句中兩個萬惡的時間戳：
select * from table where status=1 and expire>=1426867200000 and expire<1426953600000
回過頭來看，如果早晨能冷靜思考，是可以定位到具體問題所在的。
後記：從cpu到線程，到heap 的一個分析思路和方法。
1.查看進程CPU的狀態。Top
2.如果CPU的狀態異常，需要定位到線程的CPU狀態。top -h
3.找到對應的線程，記下線程ID。
4. 得到線程ID的hex值，用於下一步查看線程的情況。 可用python 獲取hex值。
5. 通過jstack查看對應的情況。並找到對應線程在幹嘛。
6.通過jmap -histo查看對應進程的使用情況。
7.分析jmap日誌，得到對應的結果。
eg:
