这一篇将继续介绍虚拟机故障处理之可视化故障处理工具JConsole工具。这个工具我们可以在JDK的bin目录下找到。
JConsole是一款基于JMX(Java Management Extensions)的可视化监视、管理工具。它主要是通过JMX的MBean对系统进行信息收集和参数动态调整。JMX是一种开放性的技术,不仅可以用在虚拟机本身的管理上,还可以运行于虚拟机之上的软件中,典型的如中间件大多也是基于JMX来实现管理和监控的。
运行JDK/bin目录下的jconsole.exe
就可以启动JConsole。JConsole启动之后会自动搜索出本机运行的所有虚拟机进程(只能监控运行在本虚拟机的进程),而不需要用户自己使用jps来查询,如图,有如下进程,双击选中JConsoleTest进程其中一个进程便可以进入主界面开始监控JConsoleTest进程的相关信息。同时JMX支持跨服务器的管理。
在这里插入图片描述
"内存"页签的作用相当于可视化的jstat命令,用于监控被收集器管理的虚拟机内存(被收集器直接管理Java堆和被间接管理的方法区)的变化趋势。如下 JConsoleTest类循环创建OOMObject对象,每隔50ms创建一个,就相当于以 100KB/50ms的速度向Java堆中填充数据。一共填充1000次。我们可以进入内存 页签中观察内存变化趋势。 运行前的内存设置如下:设置堆内存最大为100m。
-Xms100m -Xmx100m -XX:+UseSerialGC
上面我们只是指定了整个堆的内存,没有指定新生代的大小。那么整个新生代的堆内存大小是多少呢?看下图:
在这里插入图片描述
如上图,我们看到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();
}
}
说完了内存监控,我们接着来看看线程监控,如果说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);
}
}
运行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();
}
}
}
我们接着看下在 JConsole中的监控情况。同样的选中线程 页签,然后,点击检查死锁 按钮,就可以看到 线程一和线程二发生了死锁。
在这里插入图片描述
本文主要介绍了JConsole工具的使用场景,以及使用方法。JConsole是JDK自带的可视化监控工具,在实际的工作中我们可以用它来分析系统的运行状况。
深入理解Java虚拟机(第3版)