Java现场信息获取蛋疼方法

最近线上的后台出现很诡异的部分线程池挂起，特别是在没有切时间的情况下出现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 get heapDump(){

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 get heapDump(){

com.ibm.jvm.Dump. HeapDump ();

}

 2、通过jmx来调用，例行重启后加载验证，可以正常生成

3、由于网络设备抓报有大小限制，无法抓到完整的包，且从出问题的包来看，丢包率远小于20%，且由于rtt在200~500ms之间，

在每秒超过60*1kbytes报文的单条连接推送量下，可以发现即便用了netty异步发送，从发送窗口看，tcp的发送缓冲已经一直处于

90%的状态，发送队列堵塞严重

但是为什么出现应用线程池卡死还未有结论（即便出现bit反转，导致报文全部异常，netty或者应用线程池飘飞的概率也不高）

4、可以通过tcpdump 进行本机抓包验证

但是做好以上准备后，问题至今仍未重现，开发环境仍就也无法重现。。。