OOM的情况很多,有jdk的bug,有不正确的编程习惯等等。
这里记录一下一下工具和步骤,方便自己以后使用。
1.多次收集Thread Dump信息
kill -3 PID
通过对比分析heap 对象信息和Thread信息来定位
2
.通过 -Xloggc:D:/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:/test.hprof
来收集heap dump 信息
.通过MAT来查看堆里比较大块的对象是些啥。如果有些很明显的业务对象占了很大空间,并且创建它们的点很少且都已知,就可以很快缩小追查范围。
3.通过google-perftools工具分析
http://code.google.com/p/google-perftools/
4.通过Btrace来定位
http://kenai.com/projects/btrace
参考:
http://blog.csdn.net/arkblue/article/details/6124237
http://blog.bluedavy.com/?p=205
这里记录一下一下工具和步骤,方便自己以后使用。
1.多次收集Thread Dump信息
kill -3 PID
通过对比分析heap 对象信息和Thread信息来定位
2
.通过 -Xloggc:D:/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:/test.hprof
来收集heap dump 信息
.通过MAT来查看堆里比较大块的对象是些啥。如果有些很明显的业务对象占了很大空间,并且创建它们的点很少且都已知,就可以很快缩小追查范围。
3.通过google-perftools工具分析
http://code.google.com/p/google-perftools/
4.通过Btrace来定位
http://kenai.com/projects/btrace
参考:
http://blog.csdn.net/arkblue/article/details/6124237
http://blog.bluedavy.com/?p=205