用Excel表格处理考勤数据图文教程(考勤管理excel表格)
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
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版)
Java JDK JVM 虚拟化
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。