JVM（四）——GC调优案例_jvm gc实战案例-CSDN博客

本文链接：https://blog.csdn.net/qq_35599414/article/details/121768132

面试题

什么是内存泄漏和什么是内存溢出 (陌陌)
Java存在内存泄漏吗，内存泄漏的场景有哪些，如何避免(百度)
Java 中会存在内存泄漏吗，简述一下？(猎聘)
内存泄漏是怎么造成的？(拼多多、字节跳动)
内存泄漏与内存溢出的区别 (字节跳动)
Java存在内存溢出的现象吗 (字节跳动)
Java中会存在内存泄漏吗，请简单描述。 (美团)

内存溢出：

内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。

由于GC一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况。

大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的Full GC操作，这时候会回收大量的内存，供应用程序继续使用。

javadoc中对OutOfMemoryError的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。

而内存不够的原因：

OOM前一定有GC？

内存泄露

也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。（也就是内存存在一些对象即不被程序使用了，又回收不了。占着茅坑的情况。例如ThreadLocal的内存泄露问题）

但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏”。

例如：多次引用

对象 X 引用对象 Y，X 的生命周期比 Y 的生命周期长；那么当Y生命周期结束的时候，X依然引用着Y，这时候，垃圾回收期是不会回收对象Y的；如果对象X还引用着生命周期比较短的A、B、C，对象A又引用着对象 a、b、c，这样就可能造成大量无用的对象不能被回收，进而占据了内存资源，造成内存泄漏，直到内存溢出。

尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现OutOfMemory异常，导致程序崩溃。

注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。

可达性分析算法来判断对象是否是不再使用的对象，本质都是判断一个对象是否还被引用。那么对于这种情况下，由于代码的实现不同就会出现很多种内存泄漏问题（让JVM误以为此对象还在引用中，无法回收，造成内存泄漏）。

内存泄漏与内存溢出的关系：
1. 内存泄漏（memory leak ）
申请了内存用完了不释放，比如一共有 1024M 的内存，分配了 512M 的内存一直不回收，那么可以用的内存只有 512M 了，仿佛泄露掉了一部分；
通俗一点讲的话，内存泄漏就是【占着茅坑不拉shi】。

2. 内存溢出（out of memory）
申请内存时，没有足够的内存可以使用；
通俗一点儿讲，一个厕所就三个坑，有两个站着茅坑不走的（内存泄漏），剩下最后一个坑，厕所表示接待压力很大，这时候一下子来了两个人，坑位（内存）就不够了，内存泄漏变成内存溢出了。

可见，内存泄漏和内存溢出的关系：内存泄漏的增多，最终会导致内存溢出。

一、内存泄露

一、内存泄露

内存泄露的分类：

经常发生：发生内存泄露的代码会被多次执行，每次执行，泄露一块内存；
偶然发生：在某些特定情况下才会发生；
一次性：发生内存泄露的方法只会执行一次；
隐式泄漏：一直占着内存不释放，直到执行结束；严格的说这个不算内存泄漏，因为最终释放掉了，但是如果执行时间特别长，也可能会导致内存耗尽。

内存泄露的8种情况：
1、静态集合类

静态集合类，如HashMap、LinkedList等等。如果这些容器为静态的，那么它们的生命周期与JVM程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。
public class MemoryLeak {
    static List list = new ArrayList();

    public void oomTests() {
        Object obj = new Object();//局部变量
        list.add(obj);
    }
}
例如上面的代码，list是静态对象，所以生命周期和jvm一样，而obj对象被list引用，所以obj对象在list被回收前不会被回收。这就导致了obj对象的内存泄露问题。

2、单例模式

单例模式，和静态集合导致内存泄露的原因类似，因为单例的静态特性，它的生命周期和 JVM 的生命周期一样长，所以如果单例对象如果持有外部对象的引用，那么这个外部对象也不会被回收，那么就会造成内存泄漏。

3、内部类持有外部类

内部类持有外部类，如果一个外部类的实例对象的方法返回了一个内部类的实例对象。
这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄漏。
public class HandlerDemoActivity extends Activity implements OnClickListener {
 
  private static final int MESSAGE_INCRESE = 0;
  private static final int MESSAGE_DECRESE = 1;
  private TextView tv_demo_number;
  private Button btn_demo_increase;
  private Button btn_demo_decrease;
  private Button btn_demo_pause;
  
  private Handler handler = new Handler(){
     //回调方法
     public void handleMessage(android.os.Message msg) {
       String strNum = tv_demo_number.getText().toString();
       //转换为整型数据,获取当前显示的数值
       int num = Integer.parseInt(strNum);
       
       switch(msg.what){
       case MESSAGE_INCRESE:
          num++;
          tv_demo_number.setText(num + "");
          
          if(num == 20){
            Toast.makeText(HandlerDemoActivity.this, "已达到最大值", 0).show();
            btn_demo_pause.setEnabled(false);
            return;
          }
          
          //发送延迟的+1的消息
          sendEmptyMessageDelayed(MESSAGE_INCRESE, 300);//指的是延迟处理，而不是延迟发送
          
          break;
       case MESSAGE_DECRESE:
          num--;
          tv_demo_number.setText(num + "");
          
          
          if(num == 0){
            Toast.makeText(HandlerDemoActivity.this, "已达到最小值", 0).show();
            btn_demo_pause.setEnabled(false);
            return;
          }
          
          //发送延迟的-1的消息
          sendEmptyMessageDelayed(MESSAGE_DECRESE, 300);//指的是延迟处理，而不是延迟发送
          
          break;
       }
       
     }
  };
  
  @Override
  protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.activity_handler_demo);
     init();
  }
 
  
  private void init() {
     tv_demo_number = (TextView) findViewById(R.id.tv_demo_number);
     btn_demo_increase = (Button) findViewById(R.id.btn_demo_increase);
     btn_demo_decrease = (Button) findViewById(R.id.btn_demo_decrease);
     btn_demo_pause = (Button) findViewById(R.id.btn_demo_pause);
     
     btn_demo_increase.setOnClickListener(this);
     btn_demo_decrease.setOnClickListener(this);
     btn_demo_pause.setOnClickListener(this);
     
     
  }
 
  @Override
  public void onClick(View v) {
     ....
  }
}
4、各种连接，如数据库连接、网络连接和IO连接等

各种连接，如数据库连接、网络连接和IO连接等。
在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用close方法来释放与数据库的连接。只有连接被关闭后，垃圾回收器才会回收对应的对象。
否则，如果在访问数据库的过程中，对Connection、Statement或ResultSet不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。
public static void main(String[] args) {
    try {
        Connection conn = null;
        Class.forName("com.mysql.jdbc.Driver");
        conn = DriverManager.getConnection("url", "", "");
        Statement stmt = conn.createStatement();
        ResultSet rs = stmt.executeQuery("....");
    } catch (Exception e) { //异常日志
    
    } finally {   
        //1.关闭结果集 Statement   
        // 2.关闭声明的对象 ResultSet   
        // 3.关闭连接 Connection
    }
}
5、变量不合理的作用域

变量不合理的作用域。一般而言，一个变量的定义的作用范围大于其使用范围，很有可能会造成内存泄漏。另一方面，如果没有及时地把对象设置为null，很有可能导致内存泄漏的发生。
public class UsingRandom {
     private String msg;
     public void receiveMsg(){
        //private String msg;
        readFromNet();// 从网络中接受数据保存到msg中
        saveDB();// 把msg保存到数据库中
        //msg = null;
     }
}
如上面这个伪代码，通过readFromNet方法把接受的消息保存在变量msg中，然后调用saveDB方法把msg的内容保存到数据库中，此时msg已经就没用了，由于msg的生命周期与实例对象的生命周期相同，此时msg还不能回收，因此造成了内存泄漏。

实际上这个msg变量可以放在receiveMsg方法内部，当方法使用完，那么msg的生命周期也就结束，此时就可以回收了。还有一种方法，在使用完msg后，把msg设置为null，这样垃圾回收器也会回收msg的内存空间。

6、改变hash值

改变哈希值，当一个对象被存储进HashSet集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了。
否则，对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄漏。

这也是 String 为什么被设置成了不可变类型，我们可以放心地把 String 存入 HashSet，或者把 String 当做 HashMap 的 key 值；

当我们想把自己定义的类保存到散列表的时候，需要保证对象的 hashCode 不可变。

举例1：
/**
 * 演示内存泄漏
 *
 * @author shkstart
 * @create 14:43
 */
 
public class ChangeHashCode {
    public static void main(String[] args) {
        HashSet set = new HashSet();
        Person p1 = new Person(1001, "AA");
        Person p2 = new Person(1002, "BB");

        set.add(p1);
        set.add(p2);
        p1.name = "CC";
        set.remove(p1);
        System.out.println(set);//2个对象！
        
//        set.add(new Person(1001, "CC"));
//        System.out.println(set);
//        set.add(new Person(1001, "AA"));
//        System.out.println(set);

    }
}

class Person {
    int id;
    String name;

    public Person(int id, String name) {
        this.id = id;
        this.name = name;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Person)) return false;

        Person person = (Person) o;

        if (id != person.id) return false;
        return name != null ? name.equals(person.name) : person.name == null;
    }

    @Override
    public int hashCode() {
        int result = id;
        result = 31 * result + (name != null ? name.hashCode() : 0);
        return result;
    }

    @Override
    public String toString() {
        return "Person{" +
                "id=" + id +
                ", name='" + name + '\'' +
                '}';
    }
}
举例2：
/**
 * 演示内存泄漏
 * @author shkstart
 * @create 14:47
 */
public class ChangeHashCode1 {
    public static void main(String[] args) {
        HashSet<Point> hs = new HashSet<Point>();
        Point cc = new Point();
        cc.setX(10);//hashCode = 41
        hs.add(cc);
        cc.setX(20);//hashCode = 51
        System.out.println("hs.remove = " + hs.remove(cc));//false
        hs.add(cc);
        System.out.println("hs.size = " + hs.size());//size = 2
    }

}

class Point {
    int x;

    public int getX() {
        return x;
    }

    public void setX(int x) {
        this.x = x;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + x;
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        Point other = (Point) obj;
        if (x != other.x) return false;
        return true;
    }
}
7、缓存泄露

内存泄漏的另一个常见来源是缓存，一旦你把对象引用放入到缓存中，他就很容易遗忘。比如：之前项目在一次上线的时候，应用启动奇慢直到夯死，就是因为代码中会加载一个表中的数据到缓存（内存）中，测试环境只有几百条数据，但是生产环境有几百万的数据。

对于这个问题，可以使用WeakHashMap代表缓存，此种Map的特点是，当除了自身有对key的引用外，此key没有其他引用那么此map会自动丢弃此值。
/**
 * 演示内存泄漏
 *
 * @author shkstart
 * @create 14:53
 */
public class MapTest {
    static Map wMap = new WeakHashMap();
    static Map map = new HashMap();

    public static void main(String[] args) {
        init();
        testWeakHashMap();
        testHashMap();
    }

    public static void init() {
        String ref1 = new String("obejct1");
        String ref2 = new String("obejct2");
        String ref3 = new String("obejct3");
        String ref4 = new String("obejct4");
        wMap.put(ref1, "cacheObject1");
        wMap.put(ref2, "cacheObject2");
        map.put(ref3, "cacheObject3");
        map.put(ref4, "cacheObject4");
        System.out.println("String引用ref1，ref2，ref3，ref4 消失");

    }

    public static void testWeakHashMap() {

        System.out.println("WeakHashMap GC之前");
        for (Object o : wMap.entrySet()) {
            System.out.println(o);
        }
        try {
            System.gc();
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("WeakHashMap GC之后");
        for (Object o : wMap.entrySet()) {
            System.out.println(o);
        }
    }

    public static void testHashMap() {
        System.out.println("HashMap GC之前");
        for (Object o : map.entrySet()) {
            System.out.println(o);
        }
        try {
            System.gc();
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("HashMap GC之后");
        for (Object o : map.entrySet()) {
            System.out.println(o);
        }
    }

}
/**
 * 结果
 * String引用ref1，ref2，ref3，ref4 消失
 * WeakHashMap GC之前
 * obejct2=cacheObject2
 * obejct1=cacheObject1
 * WeakHashMap GC之后
 * HashMap GC之前
 * obejct4=cacheObject4
 * obejct3=cacheObject3
 * Disconnected from the target VM, address: '127.0.0.1:51628', transport: 'socket'
 * HashMap GC之后
 * obejct4=cacheObject4
 * obejct3=cacheObject3
 **/
上面代码和图示主演演示WeakHashMap如何自动释放缓存对象，当init函数执行完成后，局部变量字符串引用weakd1,weakd2,d1,d2都会消失，此时只有静态map中保存中对字符串对象的引用，可以看到，调用gc之后，HashMap的没有被回收，而WeakHashMap里面的缓存被回收了。

8、监听器和回调

内存泄漏另一个常见来源是监听器和其他回调，如果客户端在你实现的API中注册回调，却没有显式的取消，那么就会积聚。

需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存成为WeakHashMap中的键。

二、内存溢出（OOM）及相关案例

一、堆溢出

下面的案例是不断的创建People对象，导致堆内存不足。
 /**
     * 案例1：模拟线上环境OOM
     */
    @RequestMapping("/add")
    public void addObject(){
        System.err.println("add"+peopleSevice);
        ArrayList<People> people = new ArrayList<>();
        while (true){
            people.add(new People());
        }
    }
此时我们配置下jvm启动参数
-XX:+PrintGCDetails -XX:MetaspaceSize=64m -XX:+HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=heap/heapdump.hprof -XX:+PrintGCDateStamps -Xms50M  -Xmx50M  -Xloggc:log/gc-oomHeap.log
此时会打印相应GC信息、GC时间，在发生OOM时会dump出快照文件到heap/heapdump.hprof文件，打印GC信息到log/gc-oomHeap.log文件中。

而且启动参数将堆内存设置为50M，这样能模拟堆溢出。

运行后结果：

分析原因及解决方法：

Finalizable对象是第一次判断不可达的对象了，此时这个对象被放到finalize队列，还没被真正的回收，会在第二次判断中进行回收。

我们此时将dump出来的快照文件导入jvisualvm分析：

此时有提示oom的线程，我们点击进入这个线程：

此时我们就可以追踪到这个接口的代码。从而去分析代码为什么出现oom。

并且我们可以看看在堆中是否有哪些对象频繁创建：

这样我们就基本可以看出是频繁创建出People这个对象导致的。

除了分析内存快照文件，我们还可以分析gc日志文件。如果打开gc日志文件，可以发现存在多次频繁的Full GC。

可以将我们之前生成的GC日志文件导入到GCEasy中在线分析，

可以看到后面存在频繁的GC操作。

我们主要的排除问题还是根据快照文件来定位问题。

二、元空间溢出

模拟代码：主要用cglib包中的Enhancer不断创建动态类，这时这些类信息等就会被放到元空间中。
    /**
     * 案例2:模拟元空间OOM溢出
     */
    @RequestMapping("/metaSpaceOom")
    public void metaSpaceOom(){
        ClassLoadingMXBean classLoadingMXBean = ManagementFactory.getClassLoadingMXBean();
        while (true){
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(People.class);
//            enhancer.setUseCache(false);
            enhancer.setUseCache(true);
            enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> {
                System.out.println("我是加强类，输出print之前的加强方法");
                return methodProxy.invokeSuper(o,objects);
            });
            People people = (People)enhancer.create();
            people.print();
            System.out.println(people.getClass());
            System.out.println("totalClass:" + classLoadingMXBean.getTotalLoadedClassCount());
            System.out.println("activeClass:" + classLoadingMXBean.getLoadedClassCount());
            System.out.println("unloadedClass:" + classLoadingMXBean.getUnloadedClassCount());
        }
    }
此时设置启动参数：

其中对元空间大小设置为60m（1.8的元空间默认是没内存限制的），并且对类加载、类卸载的信息打印。

运行结果：

解决思路：

分析及解决：

1、可以通过线上监控（可以命令也可以GUI方式）

此时发现元空间都满了。

使用jstat查看gc情况

2、通过查看gc日志

可以看到FUll gc的原因是元空间造成的

将日志文件导入GCEasy网站进行分线上图表分析：

此时图标分析也可以看出其元空间内存不足的现象。

3、快照文件（也是定位具体代码的一步）

将dump出来的快照文件导入jvisualvm中。

我们再次进入异常线程中：

此时则可以定位到我们的代码看看是不是反射或者动态生成太多对象导致的元空间不足。

那么我们现在怎么去解决这个问题？

三、GC overhead limit exceeded

模拟代码：
test1是不断往字符串常量池中放入对象，注意jdk8的字符串常量池物理上是放在堆内存中的，那么以我们的理论来说，不断往堆内存中放对象，不应该是会报堆溢出吗？然后这里的结果报的是GC overhead limit exceeded。
/**
 * 案例3：测试 GC overhead limit exceeded
 * @author shkstart
 * @create 16:57
 */
public class OOMTest {
    public static void main(String[] args) {
        test1();

//        test2();
    }

    public static void test1() {
        int i = 0;
        List<String> list = new ArrayList<>();
        try {
            while (true) {
                list.add(UUID.randomUUID().toString().intern());
                i++;
            }
        } catch (Throwable e) {
            System.out.println("************i: " + i);
            e.printStackTrace();
            throw e;
        }
    }

    public static void test2() {
        String str = "";
        Integer i = 1;
        try {
            while (true) {
                i++;
                str += UUID.randomUUID();
            }
        } catch (Throwable e) {
            System.out.println("************i: " + i);
            e.printStackTrace();
            throw e;
        }
    }
启动参数：
-XX:+PrintGCDetails  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heap/dumpExceeded.hprof -XX:+PrintGCDateStamps  -Xms10M  -Xmx10M -Xloggc:log/gc-oomExceeded.log
运行后：

此时我们查看GC日志：

这里我们先不进行问题定位，我们现在来运行test2方法：
public static void test2() {
        String str = "";
        Integer i = 1;
        try {
            while (true) {
                i++;
                str += UUID.randomUUID();
            }
        } catch (Throwable e) {
            System.out.println("************i: " + i);
            e.printStackTrace();
            throw e;
        }
    }
test2方法中是不断的进行字符拼接，此时由于String是不可变的，如果进行拼接jvm会重新new一个String对象出来。你会在运行后发现不会出现上面的报错，而是报下面的堆溢出错误：（注意test2是经过很长时间运行后才报这个异常的）

那么为什么呢？

GC overhead limit exceeded这个是JDK6新加的错误类型，一般都是堆太小导致的。Sun 官方对此的定义：超过98%的时间用来做GC并且回收了不到2%的堆内存时会抛出此异常。本质是一个预判性的异常，抛出该异常时系统没有真正的内存溢出。

那么对于test1中，会不断创建字符串对象并且放进常量池中，而每个字符串会被list对象引用，所以这些字符串对象不可以被回收。这就会导致每次回收的对象非常少，所以就会报出 GC overhead limit exceeded错误。

而对于test22，不停追加字符串，此时底层是新new一个String对象来接收新拼接出来的字符串，但是拼接前后的字符串还是会被放到常量池中，但如果新的String赋值成功后，旧的String对象就没有引用，此时就可以被回收。但是这时要注意，我们的堆内存是有限的，而新的String不断变大，在经过很长时间后堆内存就会出现oom现象。

定位问题：

两个例子都类似的定位手法：
1、分析dump下来的文件：

2、分析文件直方图：

打开Histogram，可以看到，String类型的字符串占用了大概8M的空间，几乎把堆占满，但是还没有占满，所以这也符合Sun 官方对此的定义：超过98%的时间用来做GC并且回收了不到2%的堆内存时会抛出此异常，本质是一个预判性的异常，抛出该异常时系统没有真正的内存溢出。

解决问题：

1. 检查项目中是否有大量的死循环或有使用大内存的代码，优化代码。
2. 添加参数 `-XX:-UseGCOverheadLimit` 禁用这个检查，其实这个参数解决不了内存问题，只是把错误的信息延后，最终出现 java.lang.OutOfMemoryError: Java heap space。
3. dump内存，检查是否存在内存泄漏，如果没有，加大内存。

四、线程溢出

java.lang.OutOfMemoryError : unable to create new native Thread，出现这种异常，基本上都是创建了大量的线程导致的。操作系统会崩溃，linux无法再进行任何命令，mac/windows可能直接关机重启。鉴于以上原因，我们在虚拟机进行测试。

测试代码：不断的创建线程
/**
 * 测试4：线程溢出
 * @author shkstart
 * @create 17:45
 */
public class TestNativeOutOfMemoryError {
    public static void main(String[] args) {
        for (int i = 0; ; i++) {
            System.out.println("i = " + i);
            new Thread(new HoldThread()).start();
        }
    }
}

class HoldThread extends Thread {
    CountDownLatch cdl = new CountDownLatch(1);

    @Override
    public void run() {
        try {
            cdl.await();
        } catch (InterruptedException e) {
        }
    }
}
运行结果：

而我们看上面的结果是创建了1万5千多个线程。（主要受操作系统参数限制）

解决方案：

1）、方向一

线程数受栈空间大小影响，所以可以修改栈空间来影响线程数量。

2）、方向二

在操作系统层面去控制每个进程的线程数。

但最终还是需要我们去修改代码的逻辑。

五、栈溢出（StackOfOveriwer）

代码：
public class Jtext2 {
	private int time ;
	
	public int gettime() {
		return time;
	}
	
	public void goon() {
		this.time++;
		try {
			Thread.sleep(400);   //防止主线程结束太快，不好监测
		} catch (InterruptedException e) {
			e.printStackTrace();
		}	
		goon();
	}
	
	public static void main(String[] args) {
		Jtext2 jtext2 = new Jtext2();
		try {
		jtext2.goon();
		}catch (Throwable e) {
			System.out.println(jtext2.gettime());
			e.printStackTrace();
		}
	}
}
设置参数：
-Xss160k

运行结果：

此时我们查看dump下来的线程快照等。（或者直接使用jstack pid命令查看）

然后我们主要关注waiting on condition、waiting on monitor entry状态的：

下面的信息可以看到在com.coin.Jtest2.goon处存在阻塞等待的代码根源。

此时main线程也一直处于阻塞等待的情况：

补充：检测死锁

代码：

package com.coin;

public class Jtex3 {
    public static void main(String[] args) {
        new Thread(new A(),"Thread-A").start();
        new Thread(new B(),"Thread-B").start();

        try {
            Thread.sleep(50000);//不让main线程快速结束，以便进行线程dunmp
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

}

class A implements Runnable{
    private static final Object lock1 = new Object();

    public static  void  amethod () {
        synchronized (lock1) {
            System.out.println("进入A");

            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            B.bmethod();
        }
    }

    @Override
    public void run() {
        amethod ();

    }
}

class B implements Runnable{
    private static final Object lock2 = new Object();

    public static void  bmethod () {
        synchronized (lock2) {
            System.out.println("进入B");


            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            A.amethod();
        }
    }

    @Override
    public void run() {
        bmethod();


    }
}

此时运行后打开jvisualvm查看线程，已经提示发现死锁了：