随笔-2  评论-6  文章-5  trackbacks-0
  2007年7月9日
JVM Thread DUMP 
Windows 下用Ctrl-Break,Unix 下用 kill -3 <pid> 的命令让JVM输出 thread dump。
每隔几秒 thread dump 一次,多做几次,分析比较。

Thread Dump分析
1 找出这几次Thread dump 文件中,有哪些 Java Thread 处于长时间等待状态,很有可能就是问题之所在。
2 如果Java 线程等在某些不可能出错的地方,如 java.lang.XXX/java.util.XXX对象的某个方法,则很有可能是因为出现了 OutOfMemoryError 异常,原因不外乎是JVM 堆内存过小或出现内存泄漏。
3 对于死锁,最直接的表现就是至少两个线程长时间等待相互持有的对象(每个线程所持有的对象和它当前等待的对象都可以从 dump 中看到)。
4 对于死循环,要辅助CPU占用率确定;如果发现CPU至少一颗使用率为100%,并且有线程长时间位于用户代码处,则很有可能是死循环引起。


多线程缺陷排查
对于Java死锁问题很少出现,多线程访问变量时冲突很常见。
一般出在多线程共享同一对象实例如全局Map,Servlet,Interceptor,或如多线程同时访问某个静态方法,而此静态方法不巧又访问另一个静态变量。
这类问题自测发现不了,在并发压力测试时才能发现。如果代码的入口检查做得好,多半会抛出一些莫名其妙的异常;要不然就会出现正常运行但数据库记录不对的情况。
对这种问题,并无多好的办法解决,主要还是靠看异常堆栈和静态代码分析来解决。


内存泄漏排查
一般用商用辅助工具排查,但有可能出现在JVM heap dump 模式下,运行极度缓慢的情况。
笨笨曾经用过一个非常简单的工具,效果不错,它可以做到在不影响jvm 执行速度的情况下,做heap dump,然后对dump出的文件进行排序,检查即可。

posted @ 2007-07-09 22:01 tornado 阅读(846) | 评论 (0)编辑 收藏