JVM08-虚拟机故障处理之可视化故障处理工具JConsole工具

前言

上一篇我们介绍了JVM07-虚拟机故障处理命令行工具。这一篇将继续介绍虚拟机故障处理之可视化故障处理工具JConsole工具。这个工具我们可以在JDK的bin目录下找到。

JConsole的介绍

JConsole是一款基于JMX（Java Management Extensions）的可视化监视、管理工具。它主要是通过JMX的MBean对系统进行信息收集和参数动态调整。JMX是一种开放性的技术，不仅可以用在虚拟机本身的管理上，还可以运行于虚拟机之上的软件中，典型的如中间件大多也是基于JMX来实现管理和监控的。

JConsole的使用

1. 启动JConsole

运行JDK/bin目录下的jconsole.exe就可以启动JConsole。JConsole启动之后会自动搜索出本机运行的所有虚拟机进程（只能监控运行在本虚拟机的进程），而不需要用户自己使用jps来查询，如图，有如下进程，双击选中JConsoleTest进程其中一个进程便可以进入主界面开始监控JConsoleTest进程的相关信息。同时JMX支持跨服务器的管理。

内存监控

"内存"页签的作用相当于可视化的jstat命令，用于监控被收集器管理的虚拟机内存（被收集器直接管理Java堆和被间接管理的方法区）的变化趋势。如下 JConsoleTest类循环创建OOMObject对象，每隔50ms创建一个，就相当于以 100KB/50ms的速度向Java堆中填充数据。一共填充1000次。我们可以进入内存 页签中观察内存变化趋势。
运行前的内存设置如下：设置堆内存最大为100m。

-Xms100m -Xmx100m  -XX:+UseSerialGC

  

 

  
1
 

上面我们只是指定了整个堆的内存，没有指定新生代的大小。那么整个新生代的堆内存大小是多少呢？看下图：

如上图，我们看到Eden区域的内存一直在平稳的增加，直到执行System.gc();之后才下降下来。
看左下角可以知道Eden区域的大小是27,328 KB，同时没有设置-XX:SurvivorRation，按照JVM默认的设置Eden与Survivor的比例为8:1，而新生代有两个Survivor区域。所以整个新生代的内存大小是27328KB*1.25=34160KB。
同时我们注意到在循环填充完数据之后，执行System.gc();之后，新生代的Eden和Survivor区域已使用内存明显下降，但是老年代的内存还处于高位，这是为啥呢？这是因为System.gc();是放在setOOMObject方法内部调用的，而在该方法内oomObjectList对象还是有效的，是不能被回收的。所以老年代还是处于高位。要是oomObjectList对象也能被回收，只需要将System.gc();的调用放到setOOMObject方法外部调用。这样才能使垃圾收集器可以收集老年代中的oomObjectList对象。

public class JConsoleTest { public static void main(String[] args) throws InterruptedException { setOOMObject(1000); } /** * 内存占位符对象，一个OOMObject大约占100KB。 */ static class OOMObject{ private static final byte[] param = new byte[100 * 1024]; } public static void setOOMObject(int num) throws InterruptedException { List<OOMObject> oomObjectList = new ArrayList<>(); Thread.sleep(3000); for (int i = 0; i < num; i++) { System.out.println("*********第["+i+"]次设值"); //休息50毫秒 Thread.sleep(50); oomObjectList.add(new OOMObject()); } System.gc(); }
}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
 

线程监控

说完了内存监控，我们接着来看看线程监控，如果说JConsole的"内存"页签相当于可视化的jstat命令的话，那"线程"页签的功能就相当于可视化的jstack命令了，遇到线程停顿的时候可以使用这个页签的功能进行分析。我们知道线程长时间停顿的主要原因有等待外部资源（数据库连接、网络资源、设备资源等）、死循环、锁等待等。下面用MonitoringTest类来模拟下等待外部资源、 死循环等待和锁等待等情况。

public class MonitoringTest { /** * 线程死循环演示 */ public static void createBusyThread() { new Thread(() -> { while (true) { } }, "testBusyThread").start(); } /** * 线程锁等待演示 * @param lock */ public static void createLockThread(final Object lock) { new Thread(() -> { synchronized (lock) { try { lock.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } }, "testLockThread").start(); } public static void main(String[] args) throws IOException { //等待外部资源 BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(System.in)); bufferedReader.readLine(); createBusyThread(); bufferedReader.readLine(); Object obj  = new Object(); createLockThread(obj); }
}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
  
33
  
34
  
35
  
36
  
37
  
38
  
39
 

运行MonitoringTest之后，在JConsole中观察其运行情况，首先我们在"线程"页签中选中main线程、堆栈追踪显示BufferedReader的readBytes()方法正在等待System.in的键盘输入。这时候线程为Runnable状态，Runnable状态的线程仍会被分配运行时间，但readBytes()方法检查到流没有更新就会立即归还令牌给操作系统，这种等待只消耗很小的处理器资源。如下图所示：

接着监控testBusyThread线程，如下图所示：testBusyThread线程一直在执行空循环，从堆栈追踪可以看到在MonitoringTest代码的第17行停留，第17行的代码为while(true)。这时候线程为Runable状态，而且没有归还线程执行令牌的动作，所以会空循环耗尽系统分配给它的执行时间，直到线程切换为止，这种等待会消耗大量的处理器资源。

最后我们看看testLockThread线程在等待lock对象的notify()或者notifyAll()方法的出现，线程这时候处于WAITING状态，在重新唤醒之前不会被分配执行时间。同时会释放占用的锁对象。testLockThread线程正处于正常的活锁等待中，只要lock对象的notify()或notifyAll()方法被调用，这个线程便能激活继续执行。相关监控结果如下图所示：

说完了活锁的情况，下面我们来看一个死锁的情况。如下JConsoleDeadLockTest类，在Runable的run方法中加了两把锁（synchronized），锁对象分别是 Integer.valueOf(a)和Integer.valueOf(b)。在main方法中定义两个线程，传入的a，b值相反。这种情况下就会出现死锁，原因是Integer.valueOf()方法处于减少对象创建次数和节省内存的考虑，会对数值为-128~127之间的Integer对象进行缓存，如果valueOf()方法传入的参数在这个范围内，就直接返回缓存中的对象。也就是说尽管调用了100次Integer.valueOf()方法，但一共只返回了两个不同的Integer对象，假如某个线程在两个synchronized块之间发生了一次线程切换，那就会出现线程A在等待了线程B持有的Integer.valueOf(1),而线程B又在等待线程A持有的Integer.valueOf(2)，结果就发生了死锁。

public class JConsoleDeadLockTest { static class SyncAddRunner implements Runnable { int a, b; public SyncAddRunner(int a, int b) { this.a = a; this.b = b; } @Override public void run() { synchronized (Integer.valueOf(a)) { synchronized (Integer.valueOf(b)) { System.out.println(a + b); } } } } public static void main(String[] args) { for (int i = 0; i < 100; i++) { new Thread(new SyncAddRunner(1, 2),"线程一").start(); new Thread(new SyncAddRunner(2, 1), "线程二").start(); } }
}


  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
 

我们接着看下在 JConsole中的监控情况。同样的选中线程 页签，然后，点击检查死锁 按钮，就可以看到 线程一和线程二发生了死锁。

总结

本文主要介绍了JConsole工具的使用场景，以及使用方法。JConsole是JDK自带的可视化监控工具，在实际的工作中我们可以用它来分析系统的运行状况。

参考

深入理解Java虚拟机（第3版）

文章来源: feige.blog.csdn.net，作者：码农飞哥，版权归原作者所有，如需转载，请联系作者。

原文链接：feige.blog.csdn.net/article/details/106637550