虚拟机性能监控、故障处理工具

- 二、基础故障处理工具
- - 4.2.1 jps：虚拟机进程状况工具
  - 4.2.2 jstat:虚拟机统计信息监视工具
  - 4.2.3 jinfo:Java配置信息工具
  - 4.2.4 jmap:java内存映像工具
  - 4.2.5 jhat:虚拟机堆转储快照分析工具
  - 4.2.6 jstack：Java堆栈跟踪工具
  - 4.2.7 基础工具总结
- 三、可视化故障处理工具
- - 4.3.1 JHSDB：基于服务性代理的调试工具
  - 4.3.2 JConsole:Java监视与管理控制台
  - - 1、启动JConsole
    - 2、内存监控
    - 3、线程监控
  - 4.3.3 VisualVM：多合-故障处理工具
  - - 1、VisualVM兼容范围与插件安装
    - 2、生成、浏览堆转储快照
    - 3、分析程序性能
    - 4、BTrace动态日志跟踪

二、基础故障处理工具

4.2.1 jps：虚拟机进程状况工具

jps可以列出正在运行的虚拟机进程，并显示虚拟机执行主类名称以及这些进程的本地虚拟机唯一ID。

jps命令格式：

jps [options] [hostid]

选项	作用
-q	只输出LVMID，省略主类的名称
-m	输出虚拟机进程启动时传递给主类main()函数的参数
-l	输出主类的全名，如果进程执行的是JAR包，则输出JAR路径
-v	输出虚拟机进程启动时的JVM参数

4.2.2 jstat:虚拟机统计信息监视工具

jstat可以显示本地或者远程虚拟机进程中的类加载、内存、垃圾收集、即时编译等运行时数据，在没有GUI图形界面、只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的常用工具。

jstat命令格式为：

jstat [option vmid [interval[s|ms] [count]]]

对于VMID和LVMID：如果是本地虚拟机进程，VMID和LVMID是一致的，如果是远程虚拟机进程，那VMID的格式是：

[protocol:][//]lvmid[@hostname[:port]/servername]

参数interval和count代表查询间隔和次数，如果省略这两个参数，说明只查询一次，假设需要没250毫秒查询一次进程2764垃圾收集状况，一共查询20次，那命令应该是：

jstat -gc 2764 250 20

option代表用户希望查询的虚拟机信息，主要分为三类：类加载、类收集、运行期编译状况

选项	作用
-class	监视类加载、卸载数量、总空间以及类装载所耗费的时间
-gc	监视Java堆状况，包括Eden区、2个Survivor区、老年代、永久代等的容量，已用空间，垃圾收集时间合计等信息
-gccapacity	监视内容与-gc基本相同，但输出主要关注Java堆各个区域用到的最大、最小空间
-gcutil	监视内容与-tc基本相同，但输出主要关注已使用空间占总空间的百分比
-gccause	与-gcutil功能一样，但是会额外输出导致上一次垃圾收集产生的原因
-gcnew	监视新生代垃圾收集状况
-gcnewcapacity	监视内容与-gcnew基本相同，输出主要关注使用到的最大、最小空间
-gcold	监视老年代垃圾收集状况
-gcoldcapacity	监视内容与-gcold基本相同，输出主要关注是用到的最大、最小空间
-gcpermcapacity	输出永久代使用的最大、最小空间
-compiler	输出即时编译器编译过的方法、耗时等信息
-printcompilation	输出已经被即时编译的方法

在这里插入图片描述

以下是各个数值的解释：

S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：Eden区的大小
EU：Eden区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

4.2.3 jinfo:Java配置信息工具

jinfo的作用是实时查看和调整虚拟机各项参数

jinfo命令格式：

jinfo [option] pid

执行样例：查询CMSInitiatingOccupancyFraction参数值

jinfo -flag CMSInitiatingOccupancyFraction 14444
-XX:CMSIntiatingOccupancyFraction=85

4.2.4 jmap:java内存映像工具

jmap命令用于生成堆转储快照。

如果不使用jmap命令，也可以使用一些其他的“暴力”手段，例如-XX：+HeapDumpOnOutOfMemoryError参数，可以让虚拟机出一场之后自动生成堆转储快照文件，通过-XX:+HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break]键让虚拟机生成堆转储快照文件，又或者在Linux系统下通过Kill-3命令发送进程退出信号“恐吓”一下虚拟机，也能顺利拿到堆转储快照。

jmap的部分功能在Windows平台下受限，除了生成堆转储快照的-dump选项和用于查看每个类的实例、空间占用统计的-histo选项在所有操作系统中都可以使用之外，其余只能在Linux/Solaris中使用

jmap命令格式：

jmap [option] vmid

选项	作用
-dump	生成Java堆转储快照。格式为-dump:[live,]format=b,file=，其中live子参数说明是否只dump出存活的对象
-finalizerinfo	显示在F-Queue中等待Finalizer线程执行finalize方法的对象。只在Linux/Solaris平台下有效
-heap	显示Java堆详细信息，如使用哪种回收器、参数配置、分代状况等。只在Linux/Solaris平台下有效
-histo	显示堆中对象统计信息，包括类、实例数量、合计容量
-permstat	以ClassLoader为统计口径显示永久代内存状态。只在Linux/Solaris平台下有效
-F	当虚拟机进程对-dump选项没有响应时，可使用这个选项强制生成dump快照。只在Linux/Solaris平台下有效

使用jmap生成dump文件：

jmap -dump:format=b,file=eclipse.bin 3500

4.2.5 jhat:虚拟机堆转储快照分析工具

jhat命令与jmap搭配使用，来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP/Web服务器，生成堆转储快照的分析结果后，可以在浏览器中查看。

一般不会使用jhat直接在应用程序的服务器上分析快照。

4.2.6 jstack：Java堆栈跟踪工具

jstack（Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照（一般称为threaddump或者 javacore文件）。

线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的目的通常是定位线程出现长时间停顿的原因。线程出现停顿时通过jstack来查看各个线程的调用堆栈，就可以获知没有响应的线程到底在后台做些什么事情，或者等待着什么资源。

jstack命令格式：

jstack [option] vmid

选项	作用
-F	当正常输出的请求不被响应时，强制输出线程堆栈
-l	除堆栈外，显示关于锁的附加信息
-m	如果调用到本地方法的话，可以显示C/C++的堆栈

从JDK 5起，java.lang.Thread类新增了一个getAllStackTraces()方法用于获取虚拟机中所有线程的 StackTraceElement对象。使用这个方法可以通过简单的几行代码完成jstack的大部分功能，在实际项目中不妨调用这个方法做个管理员页面，可以随时使用浏览器来查看线程堆栈。

4.2.7 基础工具总结

基础工具：用于支持基本的程序创建和运行

在这里插入图片描述

安全：用于程序签名、设置安全测试等

在这里插入图片描述

国际化：用于创建本地语言文件

在这里插入图片描述

远程方法调用：用于跨Web或网络的服务交互

在这里插入图片描述

部署工具：用于程序打包、发布、部署

在这里插入图片描述

Java Web Start

在这里插入图片描述

性能监控和故障处理工具

在这里插入图片描述

REPL和脚本工具
在这里插入图片描述

三、可视化故障处理工具

4.3.1 JHSDB：基于服务性代理的调试工具

JDK中提供了JCMD和JHSDB两个集成式的多功能工具箱，以下是JCMD、JHSDB与原基础工具实现相同功能的简要对比

在这里插入图片描述

JHSDB是一款基于服务性代理实现的进程外调试工具。服务性代理是 HotSpot虚拟机中一组用于映射Java虚拟机运行信息的、主要基于Java语言（含少量JNI代码）实现的 API集合。

服务性代理以HotSpot内部的数据结构为参照物进行设计，把这些C++的数据抽象出Java模型对象，相当于HotSpot的C++代码的一个镜像。通过服务性代理的API，可以在一个独立的Java虚拟机的进程里分析其他HotSpot虚拟机的内部数据，或者从HotSpot虚拟机进程内存中dump出来的转储快照里还原出它的运行状态细节。

4.3.2 JConsole:Java监视与管理控制台

JConsole是一款基于JMX的可视化监视、管理工具。它的主要功能是通过JMX的MBean（Managed Bean）对系统进行信息收集和参数动态调整。

1、启动JConsole

通过JDK/bin目录下的jconsole.exe启动JCon-sole后，会自动搜索出本机运行的所有虚拟机进程，而不需要用户自己使用jps来查询。双击选择其中一个进程便可进入主界面开始监控。 JMX支持跨服务器的管理，也可以使用下面的“远程进程”功能来连接远程服务器，对远程虚拟机进行监控。

2、内存监控

“内存”页签的作用相当于可视化的jstat命令，用于监视被收集器管理的虚拟机内存（被收集器直接管理的Java堆和被间接管理的方法区）的变化趋势。

Jconsole监视代码：

参数：-Xms100m -Xmx100m -XX:+UseSerialGC

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(500);
            list.add(new OOMObject());
        }
        System.gc();
    }
    public static void main(String[] args) throws Exception {
        fillHeap(1000);
    }

在这里插入图片描述

虚拟机启动参数只限制了Java堆为100MB，但没有明确使用-Xmn参数指定新生代大小，读者能否从监控图中估算出新生代的容量？

Eden空间为99008KB，因为没有设置-XX：SurvivorRadio参数，所以Eden 与Survivor空间比例的默认值为8∶1，因此整个新生代空间大约为99008KB×125%=123,760KB。

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

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

3、线程监控

如果说JConsole的“内存”页签相当于可视化的jstat命令的话，那“线程”页签的功能就相当于可视化的jstack命令了，遇到线程停顿的时候可以使用这个页签的功能进行分析。前面讲解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);
    }

在这里插入图片描述

检测死锁代码样例：

/**
     * 线程死锁等待演示
     */
    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();
        }
    }

出现线程死锁后，点击JConsole线程面板的“检测死锁”按钮，将出现一个新的“死锁”页：

在这里插入图片描述

如上图所示，线程15在等待线程12的对象，线程12在等待线程15的对象，两个对象都被各自的线程锁住。

4.3.3 VisualVM：多合-故障处理工具

1、VisualVM兼容范围与插件安装

在这里插入图片描述

这里VisualVM里的插件中心不知道为什么一直连不上，试了网上的各种方法也没解决问题，之后用到了哪个插件手动下载吧。

2、生成、浏览堆转储快照

VisualVM中生成堆转储快照文件有两种方式：

在“应用程序”窗口中右键单击应用程序节点，然后选择“堆Dump”
在“应用程序”窗口中双击应用程序节点以打开应用程序标签，然后再“监视”标签中单击“堆Dump”

3、分析程序性能

在Profiler页签中，VisualVM提供了程序运行期间方法级的处理器执行时间分析以及内存分析。做 Profiling分析肯定会对程序运行性能有比较大的影响，所以一般不在生产环境使用这项功能，或者改用 JMC来完成，JMC的Profiling能力更强，对应用的影响非常轻微。

4、BTrace动态日志跟踪

BTrace [3]是一个很神奇的VisualVM插件，它本身也是一个可运行的独立程序。BTrace的作用是在不中断目标程序运行的前提下，通过HotSpot虚拟机的Instrument功能[4]动态加入原本并不存在的调试代码。这项功能对实际生产中的程序很有意义：如当程序出现问题时，排查错误的一些必要信息时（譬如方法参数、返回值等），在开发时并没有打印到日志之中以至于不得不停掉服务时，都可以通过调试增量来加入日志代码以解决问题。

由于时间原因，这里不做过多记录，以后有需求再返回来看。