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出的文件进行排序，检查即可。

public class FileBean {
 private String path;
 private String name;
 
 public FileBean(String path,String name){
  this.path = path;
  this.name = name;
 }
 public String getName() {
  return name;
 }
 public void setName(String name) {
  this.name = name;
 }
 public String getPath() {
  return path;
 }
 public void setPath(String path) {
  this.path = path;
 }
 public String getPathName(){
  return path+name;
 }
}