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

网友投稿 686 2022-05-29

前言

上一篇我们介绍了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 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

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

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版)

Java JDK JVM 虚拟化

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Linux学习笔记Day5之Linux服务管理
下一篇:Python—OpenCV创建级联文件(Windows7/10环境)
相关文章