JDK的可视化工具——Java监视与管理控制台（JConsole）。

分手后的思念是犯贱 2024-02-18 19:20 63阅读 0赞

JConsole（Java Monitoring and Management Console）是一种基于JMX的可视化监视、管理工具。他管理部分的功能是针对JMX MBean进行管理，由于MBean可以使用代码、中间件服务器的管理控制台或者所有符合JMX规范的软件进行访问，这里着重介绍JConsole监控部分的功能。

## 启动JConsole ##

通过JDK/bin目录下的“jconsole.exe”启动JConsole后，将自动搜索出本机运行的所有虚拟机进程，不需要用户自己再使用jps来查询了，如下图所示。双击选择其中一个进程即可开始监听，也可以使用下面的“远程进程”功能来连接远程服务器，对远程虚拟机进行监控。

> ![20180403152041839][]

从上图可以看出，该机器现在运行了Eclipse、JConsole和MonitoringTest三个本地虚拟机进程，其中MonitoringTest就是准备的“反面教材”代码之一。双击他进入JConsole主界面，可以看到主界面里共包括“概述”、“内存”、“线程”、“类”、“VM摘要”、“MBean”6个页签，如下图所示。

> ![20180403152306798][]

“概述”页签显示的是整个虚拟机运行数据的概览，其中包括“堆内存使用情况”、“线程”、“类”、“CPU使用情况”4种信息的曲线图，这些曲线图是后面“内存”、“线程”、“类”页签的信息汇总，具体内容将在后面介绍。

## 内存监控 ##

“内存”页面相当于可视化的jstat命令，用于监视受收集器管理的虚拟机内存（Java堆和永久代）的变化趋势。我们通过运行下面代码来体验一下他的监视功能。运行时设置的虚拟机参数为：-Xms100m-XX : +UseSerialGC，这段代码的作用是以64KB/50毫秒的速度往Java堆中填充数据，一共填充1000次，使用JConsole的“内存”页签进行监视，观察曲线和柱状图指示图的变化。

> /\*\*  
> \* 内存占位符对象，一个OOMObject大约占64K  
> \*/  
> static class OOMObject \{  
> public byte\[\] placeholder = new byte\[64 \* 1024\];  
> \}  
>   
> public static void fillHeap(int num) throws InterruptedException \{  
> List<OOMObject> list = new ArrayList<OOMObject>();  
> for (int i = 0; i < num; i++) \{  
> // 稍作延时，令监视曲线的变化更加明显  
> Thread.sleep(50);  
> list.add(new OOMObject());  
> \}  
> System.gc();  
> \}  
>   
> public static void main(String\[\] args) throws Exception \{  
> fillHeap(1000);  
> \}

程序运行后，在“内存”页签中可以看到内存池Eden区的运行趋势呈现折线状，如下图所示。而监视范围扩大至整个堆后，会发现曲线是一条向上增长的平滑曲线。并且从柱状图可以看出，在1000次循环执行结束，运行了System.gc()后，虽然整个新生代Eden和Survivor区都基本被清空了，但是代表老年代的柱状图仍然保持峰值状态，说明被填充进堆中的数据在System.gc()方法执行之后仍然存活。现提两个小问题供思考。

*  **虚拟机启动参数只限制了Java堆为100MB，没有指定-Xmn参数，能否从监控图中估计出新生代有多大？**

> 下图显示Eden空间为27 328KB，因为没有设置-XX : SurvivorRadio参数，所以Eden与Survivor空间比例为默认值8:1，整个新生代空间大约为27 328KB\*125%=34 160KB。

*  **为何执行了System.gc()之后，下图中代表老年代的柱状图仍然显示峰值状态，代码需要如何调整才能让System.gc()回收掉填充到堆中的对象？**

> 执行完System.gc()之后，空间未能回收是因为List<OOMObject> list对象仍然存活，fillHeap()方法仍然没有退出，因此list对象在System.gc()执行时仍然处于作用域之内。如果把System.gc()移动到fillHeap()方法外调用就可以回收掉全部内存。

> ![20180403153701912][]

## 线程监控 ##

如果上面的“内存”页签相当于可视化的jstat命令的话，“线程”页签的功能相当于可视化的jstack命令，遇到线程停顿时可以使用这个页签进行监控分析。线程长时间停顿的主要原因主要有：等待外部资源（数据库连接、网络资源、设备资源等）、死循环、锁等待（活锁和死锁）。同构下面代码分别演示一下这几种情况。

> /\*\*  
> \* 线程死循环演示  
> \*/  
> public static void createBusyThread() \{  
> Thread thread = new Thread(new Runnable() \{  
> @Override  
> public void run() \{  
> while (true) // 第41行  
> ;  
> \}  
> \}, "testBusyThread");  
> thread.start();  
> \}  
>   
> /\*\*  
> \* 线程锁等待演示  
> \*/  
> public static void createLockThread(final Object lock) \{  
> Thread thread = new Thread(new Runnable() \{  
> @Override  
> public void run() \{  
> synchronized (lock) \{  
> try \{  
> lock.wait();  
> \} catch (InterruptedException e) \{  
> e.printStackTrace();  
> \}  
> \}  
> \}  
> \}, "testLockThread");  
> thread.start();  
> \}  
>   
> public static void main(String\[\] args) throws Exception \{  
> BufferedReader br = new BufferedReader(new InputStreamReader(System.in));  
> br.readLine();  
> createBusyThread();  
> br.readLine();  
> Object obj = new Object();  
> createLockThread(obj);  
> \}

程序运行后，首先在“线程”页签中选择main线程，如下图所示。堆栈追踪显示BufferedReader在readBytes方法中等待System.in的键盘输入，这时线程为Runnable状态，Runnable状态的线程会被分配运行时间，但readBytes方法检查到流没有更新时会立刻归还执行令牌，这种等待只消耗很小的CPU资源。

> ![20180403154509559][]

接着监控testBusyThread线程，如下图所示，testBusyThread线程一直在执行空循环，从堆栈追踪中看到一直在MonitoringTest.java代码的41行停留，41行为：while(true)。这时候线程为Runnable状态，而且没有归还线程执行令牌的动作，会在空循环上用尽全部执行时间直到线程切换，这种等待会消耗较多的CPU资源。

> ![20180403154735793][]

下图显示testLockThread线程在等待着lock对象的notify或notifyAll方法的出现，线程这时候处于WAITING状态，在被唤醒前不会被分配执行时间。

> ![20180403154847232][]

testLockThread线程正在处于正常的活锁等待，只要lock对象的notify()或notifyAll()方法被调用，这个线程便能激活以继续执行。下面代码演示了一个无法再被激活的死锁等待。

> /\*\*  
> \* 线程死锁等待演示  
> \*/  
> static class SynAddRunalbe implements Runnable \{  
> int a, b;  
> public SynAddRunalbe(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 SynAddRunalbe(1, 2)).start();  
> new Thread(new SynAddRunalbe(2, 1)).start();  
> \}  
> \}

这段代码开了200个线程去分别计算1+2以及2+1的值，其中for循环是可省略的，两个线程也可能会导致死锁，不过那样概率太小，需要尝试运行很多次才能看到效果。一般的话，带for循环的版本最多运行2~3次就会遇到线程死锁，程序无法结束。造成死锁的原因是Integer.valueOf()方法基于减少对象创建次数和节省内存的考虑，\[-128, 127\]之间的数字会被缓存，当valueOf()方法传入参数在这个范围之内，将直接返回缓存中的对象。也就是说，代码中调用了200次Integer.value()方法一共就只返回了两个不同的对象。假如在某个线程的两个synchronized块之间发生了一次线程切换，那就会出现线程A等着被线程B持有的Integer.valueOf(1)，线程B又等着被线程A持有的Integer.valueOf(2)，结果出现大家都跑不下去的情景。

出现线程死锁之后，点击JConsole线程面板的“检测到死锁”按钮，将出现一个新的“死锁”页签，如下图所示。

> ![20180403160221239][]

上图中很清晰的显示了线程Thread-43在等待一个被线程Thread-12持有Integer对象，而点击线程Thread-12则显示他也在等待一个Integer对象，被线程Thread-43持有，这样两个线程就互相卡住，都不存在等到锁释放的希望了。

[20180403152041839]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/aaee2a36c9ab47829cbbbee90a571f74.png
[20180403152306798]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/d5f4bf01ce484ee5a8453dc1099d8175.png
[20180403153701912]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/a274990a76af481db7bb73f2e1253cb4.png
[20180403154509559]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/f9ae21d186704a83b59973fc045db8b8.png
[20180403154735793]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/a7a68fa0ede1485ca8fa14e9ffd2bbe3.png
[20180403154847232]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/7db74e9e55f8468dab804a6f6407a5a9.png
[20180403160221239]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/0bdb210a37ef448392446e2ba989ffdb.png