最近線上的後臺出現很詭異的部分線程池掛起，特別是在沒有切時間的情況下出現quartz調度線程池卡死，因此獲取現場信息就特別重要。
不料碰上更加詭異的情況，即kill -3 無法獲取javacore（命令正常執行後，運行目錄下沒有javacore，且通過find -name *core無法找到）
(吐槽下某些IDC人。只會用IBM的webphere自帶的admin來生成。。)
考慮到jvm用的是ibm的j9.只有祭出其殺招
1、通過內核自帶的靜態方法生成（coredump也可以生成，不過一般不需要這麼大殺器，kill -6就夠了）
@override
public void getJavaCore(){
com.ibm.jvm.Dump.JavaDump();
}
@override
public void getheapDump(){
com.ibm.jvm.Dump.HeapDump();
}
2、通過jmx來調用，例行重啓後加載驗證，可以正常生成
3、由於網絡設備抓報有大小限制，無法抓到完整的包，且從出問題的包來看，丟包率遠小於20%，且由於rtt在200~500ms之間，
在每秒超過60*1kbytes報文的單條連接推送量下，可以發現即便用了netty異步發送，從發送窗口看，tcp的發送緩衝已經一直處於
90%的狀態，發送隊列堵塞嚴重
但是爲什麼出現應用線程池卡死還未有結論（即便出現bit反轉，導致報文全部異常，netty或者應用線程池飄飛的概率也不高）
4、可以通過tcpdump 進行本機抓包驗證
但是做好以上準備後，問題至今仍未重現，開發環境仍就也無法重現。。。
最近線上的後臺出現很詭異的部分線程池掛起，特別是在沒有切時間的情況下出現quartz調度線程池卡死，因此獲取現場信息就特別重要。
不料碰上更加詭異的情況，即kill -3 無法獲取javacore（命令正常執行後，運行目錄下沒有javacore，且通過find -name *core無法找到）
(吐槽下某些IDC人。只會用IBM的webphere自帶的admin來生成。。)
考慮到jvm用的是ibm的j9.只有祭出其殺招
1、通過內核自帶的靜態方法生成（coredump也可以生成，不過一般不需要這麼大殺器，kill -6就夠了）
@override
public void getJavaCore(){
com.ibm.jvm.Dump.JavaDump();
}
@override
public void getheapDump(){
com.ibm.jvm.Dump.HeapDump();
}
2、通過jmx來調用，例行重啓後加載驗證，可以正常生成
3、由於網絡設備抓報有大小限制，無法抓到完整的包，且從出問題的包來看，丟包率遠小於20%，且由於rtt在200~500ms之間，
在每秒超過60*1kbytes報文的單條連接推送量下，可以發現即便用了netty異步發送，從發送窗口看，tcp的發送緩衝已經一直處於
90%的狀態，發送隊列堵塞嚴重
但是爲什麼出現應用線程池卡死還未有結論（即便出現bit反轉，導致報文全部異常，netty或者應用線程池飄飛的概率也不高）
4、可以通過tcpdump 進行本機抓包驗證
但是做好以上準備後，問題至今仍未重現，開發環境仍就也無法重現。。。