java虚拟机：jvm调优-工具篇

工具做为图形化界面来展示更能直观的发现问题，另一方面一些耗费性能的分析（dump文件分析）一般也不会在生产直接分析，往往dump下来的文件达1G左右，人工分析效率较低，因此利用工具来分析jvm相关问题，长长可以到达事半功倍的效果来。

jvm监控分析工具一般分为两类，一种是jdk自带的工具，一种是第三方的分析工具。jdk自带工具一般在jdk bin目录下面，以exe的形式直接点击就可以使用，其中包含分析工具已经很强大，几乎涉及了方方面面，但是我们最常使用的只有两款：jconsole.exe和jvisualvm.exe；第三方的分析工具有很多，各自的侧重点不同，比较有代表性的：MAT(Memory Analyzer Tool)、GChisto等。

对于大型 JAVA 应用程序来说，再精细的测试也难以堵住所有的漏洞，即便我们在测试阶段进行了大量卓有成效的工作，很多问题还是会在生产环境下暴露出来，并且很难在测试环境中进行重现。JVM 能够记录下问题发生时系统的部分运行状态，并将其存储在堆转储 (Heap Dump) 文件中，从而为我们分析和诊断问题提供了重要的依据。其中VisualVM和MAT是dump文件的分析利器。

Jconsole（Java Monitoring and Management Console）是从java5开始，在JDK中自带的java监控和管理控制台，用于对JVM中内存，线程和类等的监控，是一个基于JMX（java management extensions）的GUI性能监测工具。jconsole使用jvm的扩展机制获取并展示虚拟机中运行的应用程序的性能和资源消耗等信息。

直接在jdk/bin目录下点击jconsole.exe即可启动，界面如下:

在弹出的框中可以选择本机的监控本机的java应用，也可以选择远程的java服务来监控，如果监控远程服务需要在tomcat启动脚本中添加如下代码：

连接进去之后，就可以看到jconsole概览图和主要的功能：概述、内存、线程、类、VM、MBeans

简介

VisualVM 是一个工具，它提供了一个可视界面，用于查看 Java 虚拟机 (Java Virtual Machine, JVM) 上运行的基于 Java 技术的应用程序（Java 应用程序）的详细信息。VisualVM 对 Java Development Kit (JDK) 工具所检索的 JVM 软件相关数据进行组织，并通过一种使您可以快速查看有关多个 Java 应用程序的数据的方式提供该信息。您可以查看本地应用程序以及远程主机上运行的应用程序的相关数据。此外，还可以捕获有关 JVM 软件实例的数据，并将该数据保存到本地系统，以供后期查看或与其他用户共享。

VisualVM 是javajdk自带的最牛逼的调优工具了吧，也是我平时使用最多调优工具，几乎涉及了jvm调优的方方面面。同样是在jdk/bin目录下面双击jvisualvm.exe既可使用，启动起来后和jconsole 一样同样可以选择本地和远程，如果需要监控远程同样需要配置相关参数，主界面如下；

VisualVM可以根据需要安装不同的插件，每个插件的关注点都不同，有的主要监控GC，有的主要监控内存，有的监控线程等。

如何安装：

1、从主菜单中选择“工具”>“插件”。2、在“可用插件”标签中，选中该插件的“安装”复选框。单击“安装”。3、逐步完成插件安装程序。

我这里以 Eclipse(pid 22296)为例，双击后直接展开，主界面展示了系统和jvm两大块内容，点击右下方jvm参数和系统属性可以参考详细的参数信息.

因为VisualVM的插件太多，我这里主要介绍三个我主要使用几个：监控、线程、Visual GC

监控的主页其实也就是，cpu、内存、类、线程的图表

线程和jconsole功能没有太大的区别

Visual GC 是常常使用的一个功能，可以明显的看到年轻代、老年代的内存变化，以及gc频率、gc的时间等。

以上的功能其实jconsole几乎也有，VisualVM更全面更直观一些，另外VisualVM非常多的其它功能，可以分析dump的内存快照，dump出来的线程快照并且进行分析等，还有其它很多的插件大家可以去探索

MAT是什么？

MAT(Memory Analyzer Tool)，一个基于Eclipse的内存分析工具，是一个快速、功能丰富的Java heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。使用内存分析工具从众多的对象中进行分析，快速的计算出在内存中对象的占用大小，看看是谁阻止了垃圾收集器的回收工作，并可以通过报表直观的查看到可能造成这种结果的对象。

通常内存泄露分析被认为是一件很有难度的工作，一般由团队中的资深人士进行。不过要介绍的 MAT（Eclipse Memory Analyzer）被认为是一个“傻瓜式“的堆转储文件分析工具，你只需要轻轻点击一下鼠标就可以生成一个专业的分析报告。和其他内存泄露分析工具相比，MAT 的使用非常容易，基本可以实现一键到位，即使是新手也能够很快上手使用。

MAT以eclipse 插件的形式来安装，具体的安装过程就不在描述了，可以利用visualvm或者是 jmap命令生产堆文件，导入eclipse mat中生成分析报告：

生产这会报表的同时也会在dump文件的同级目录下生成三份（dump_Top_Consumers.zip、dump_Leak_Suspects.zip、dump_Top_Components.zip）分析结果的html文件，方便发送给相关同事来查看。

需要关注的是下面的Actions、Reports、Step by Step区域：

duplicate classes ：检测由多个类装载器加载的类

Leak Suspects ：内存泄漏分析

以上只是一个初级的介绍，mat还有更强大的使用，比如对比堆内存，在生产环境中往往为了定位问题，每隔几分钟dump出一下内存快照，随后在对比不同时间的堆内存的变化来发现问题。

GChisto是一款专业分析gc日志的工具，可以通过gc日志来分析：Minor GC、full gc的时间、频率等等，通过列表、报表、图表等不同的形式来反应gc的情况。虽然界面略显粗糙，但是功能还是不错的。

配置好本地的jdk环境之后，双击GChisto.jar,在弹出的输入框中点击 add 选择gc.log日志

GC Pause Distribution:查看GC停顿的详细分布，x轴表示垃圾收集停顿时间，y轴表示是停顿次数。

GC Timeline：显示整个时间线上的垃圾收集

不过这款工具已经不再维护，不能识别最新jdk的日志文件。

GCViewer也是一款分析小工具，用于可视化查看由Sun / Oracle, IBM, HP 和 BEA Java 虚拟机产生的垃圾收集器的日志，gcviewer个人感觉显示 的界面比较乱没有GChisto更专业一些。

以上的两款gc分析日志，一个不太维护了，一个不太专业，求推荐更好的gc分析工具

本文转载自

原文作者：纯洁的微笑 

原文地址：http://www.cnblogs.com/ityouknow/p/5603287.html

相关内容

jvm内存溢出性能调优

jps jstat Top jstack jmap mat工具

 top -Hp pid可以查看某个进程的线程信息

-H 显示线程信息，-p指定pid

jps:可以列出正在运行的虚拟机进程，并显示虚拟机执行主类名称及进程pid 如：jps -l pid

jstack是java虚拟机自带的一种堆栈跟踪工具。用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。

线程的几种状态:

NEW：未启动的。不会出现在Dump中。

RUNNABLE：在虚拟机内执行的。运行中状态，可能里面还能看到locked字样，表明它获得了某把锁。

BLOCKED：受阻塞并等待监视器锁。被某个锁(synchronizers)給block住了。

WATING：无限期等待另一个线程执行特定操作。等待某个condition或monitor发生，一般停留在park(), wait(), sleep(),join() 等语句里。

TIMED_WATING：有时限的等待另一个线程的特定操作。和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。

TERMINATED：已退出的。

例一：

public class MyThread implements Runnable{

    public void run() {

        synchronized(this) {

            for (int i = 0; i < 1; i--) {

                System.out.println(Thread.currentThread().getName() +Thread.currentThread().getId()+ " do loop " + i);

            }

        }

    }

    public static void main(String[] args) {

        MyThread t1 = new MyThread();

        Thread ta = new Thread(t1, "A");

        Thread tb = new Thread(t1, "B");

        ta.start();

        tb.start();

    }

}

jstack -l 6212 > d:11.jstack.txt

2019-06-25 23:00:05

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000002b7e800 nid=0xb80 waiting on condition [0x0000000000000000]

   java.lang.Thread.State: RUNNABLE

"B" #12 prio=5 os_prio=0 tid=0x000000001b4b1800 nid=0x1d0 waiting for monitor entry [0x000000001c12f000]

   java.lang.Thread.State: BLOCKED (on object monitor)

        at MyThread.run(MyThread.java:12)

        - waiting to lock (a MyThread)

        at java.lang.Thread.run(Thread.java:748)

"A" #11 prio=5 os_prio=0 tid=0x000000001b4b1000 nid=0x1cec runnable [0x000000001c02f000]

   java.lang.Thread.State: RUNNABLE

        at java.io.FileOutputStream.writeBytes(Native Method)

        at java.io.FileOutputStream.write(FileOutputStream.java:326)

        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)

        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)

        - locked (a java.io.BufferedOutputStream)

        at java.io.PrintStream.write(PrintStream.java:482)

        - locked (a java.io.PrintStream)

        ...

        at MyThread.run(MyThread.java:13)

        - locked (a MyThread)

        at java.lang.Thread.run(Thread.java:748)

dump时间，虚拟机的信息 在top命令中，已经获取到了占用cpu资源较高的线程pid，将该pid转成16进制的值，在thread dump中每个线程都有一个nid，找到对应的nid即可；

此处是我们最为关心的地方，也是通过stack trace查找问题的地方,每个item的具体含义是

-Thread name: "A"

-线程优先级： prio=10

-java线程的identifier：tid=0x09b7b400

-native线程的identifier: nid=0x12f2

-线程的状态： in Object.wait()  java.lang.Thread.State: TIMED_WAITING (on object monitor) 

-线程栈起始地址：[0xb30f9000]

例二：

public void run() {

        synchronized(this) {

            for (int i = 0; i < 1; i--) {

                //System.out.println(Thread.currentThread().getName() +Thread.currentThread().getId()+ " do loop " + i);

                try {

                    this.wait();

                } catch (InterruptedException e) {

                    e.printStackTrace();

                }

            }

        }

    }

2019-06-25 22:52:25

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x000000000252e800 nid=0x3e5c waiting on condition [0x0000000000000000]

   java.lang.Thread.State: RUNNABLE

"B" #12 prio=5 os_prio=0 tid=0x000000001b19b000 nid=0x4d38 in Object.wait() [0x000000001bdee000]

   java.lang.Thread.State: WAITING (on object monitor)

        at java.lang.Object.wait(Native Method)

        - waiting on (a MyThread)

        at java.lang.Object.wait(Object.java:502)

        at MyThread.run(MyThread.java:15)

        - locked (a MyThread)

        at java.lang.Thread.run(Thread.java:748)

 "A" #11 prio=5 os_prio=0 tid=0x000000001b198000 nid=0x2b18 in Object.wait() [0x000000001bcef000]

   java.lang.Thread.State: WAITING (on object monitor)

        at java.lang.Object.wait(Native Method)

        - waiting on (a MyThread)

        at java.lang.Object.wait(Object.java:502)

        at MyThread.run(MyThread.java:15)

        - locked (a MyThread)

        at java.lang.Thread.run(Thread.java:748)

 使用MAT工具进行内存泄露分析

既然要分析内存，首先需要获取可供分析的原始内存文件，这就需要用到jmap命令。jmap是JDK自带的一种用于生成内存镜像文件的工具，通过该工具，开发人员可以快速生成dump文件。开发人员可以使用命令“jmap -help”查看jmap的常用命令

获取dump文件有两种方法：

其一，通过上面介绍的 jmap工具生成，可以生成任意一个java进程的dump文件；

其二，通过配置JVM参数生成，选项“-XX:+HeapDumpOnOutOfMemoryError ”和-“XX:HeapDumpPath”所代表的含义就是当程序出现OutofMemory时，将会在相应的目录下生成一份dump文件，而如果不指定选项“XX:HeapDumpPath”则在当前目录下生成dump文件。

虽然有两种方式获取dump文件，但是考虑到生产环境中几乎不可能在线对其进行分析，大都是采用离线分析，因此使用jmap+MAT工具是最常见的组合。

模拟堆溢出场景：设置如：-Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:dump

@Test

    public void testOOM() {

        List users = new ArrayList();

        while (true) {

            users.add(new Person("", 1));

        }

    }

Overview选项:

当成功启动MAT后，通过菜单选项“File->Open heap dump...”打开指定的dump文件后，将会生成Overview选项，如下所示：

 在Overview选项中，以饼状图的形式列举出了程序内存消耗的一些基本信息，其中每一种不同颜色的饼块都代表了不同比例的内存消耗情况。

Dominator Tree选项：

如果说需要定位内存泄露的代码点，我们可以通过Dominator Tree菜单选项来进行排查。Dominator Tree提供了一个列表。Dominator Tree：对象之间dominator关系树。如果从GC Root到达Y的的所有path都经过X，那么我们称X dominates Y，或者X是Y的Dominator 。Dominator Tree由系统中复杂的对象图计算而来。从MAT的dominator tree中可以看到占用内存最大的对象以及每个对象的dominator，如下所示：

 可以进一步查看内层应用情况，同时还可以看到对应类对象的属性值，如下所示：

Histogram选项:

可以通过Histogram分析，Histogram列出了每个类的实例数量，点击Action下的Histogram，得到以下结果：

如果需要查询特性的某个类，我们可以在第一行输入类名或者关键词进行正则匹配查找，如查找“erson”：

Path to GC Root:

    查看一个对象到RC Roots的引用链

    通常在排查内存泄漏的时候，我们会选择exclude all phantom/weak/soft etc.references，意思是查看排除虚引用/弱引用/软引用等的引用链，因为被虚引用/弱引用/软引用的对象可以直接被GC给回收，我们要看的就是某个对象否还存在Strong 引用链（在导出HeapDump之前要手动出发GC来保证），如果有，则说明存在内存泄漏，然后再去排查具体引用

总结：遇到线上问题，首先确认排查问题的思路：

查看日志

    查看CPU情况 top

    查看TCP情况 netstat

    查看java线程，jstack

    查看java堆，jmap

通过MAT分析堆文件，寻找无法被回收的对象

1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取比较多条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。 2.检查代码中是否有死循环或递归调用。 

3.检查是否有大循环重复产生新对象实体。 

4.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

5.结合内存查看工具动态查看内存使用情况

1.检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误。对代码进行走查和分析，找出可能发生内存溢出的位置。修正。

2.修改JVM启动参数，直接增加内存。

第一个异常：设置堆的方法是通过-Xms(堆的最小值)，-Xmx(堆的最大值)

第一个异常：设置栈大小的方法是设置-Xss参数-Xss100k

第三个异常：设置元空间-XX:PermSize和-XX:MaxPermSize参数（java8中去掉了PermGen（1.8前称永久代，主要用来 存放Class的静态信息，Main方法信息，常量信息，静态方法和变量信息，共享变量等信息 参数设置示例： -XX:PermSize=5M -XX:MaxPermSize=7M） 改为 Metaspace 默认情况下，类元数据只受可用的本地内存限制（容量取决于是32位或是64位操作系统的可用虚拟内存大小） 新参数（MaxMetaspaceSize）用于限制本地内存分配给类元数据的大小。如果没有指定这个参数，元空间会在运行时根据需要动态调整）

内存查看工具有许多，比较有名的有：mt、Optimizeit Profiler、JProbe Profiler、JinSight和Java1.5的Jconsole、visualVM(BTrace动态日志，不用修改服务可以加日志)等。它们的基本工作原理大同小异，都是监测Java程序运行时所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员可以根据这些信息判断程序是否有内存泄漏问题。一般来说，一个正常的系统在其启动完成后其内存的占用量是基本稳定的，而不应该是无限制的增长的。持续地观察系统运行时使用的内存的大小，可以看到在内存使用监控窗口中是基本规则的锯齿形的图线，如果内存的大小持续地增长，则说明系统存在内存泄漏问题。通过间隔一段时间取一次内存快照，然后对内存快照中对象的使用与引用等信息进行比对与分析，可以找出是哪个类的对象在泄漏。