给一个系统定位问题的时候， 知识、 经验是关键基础， 数据是依据， 工具是运用知识处理数据的手段。 这里说的数据包括但不限于异常堆栈、 虚拟机运行日志、 垃圾收集器日志、 线程快照（threaddump/javacore文件） 、 堆转储快照（heapdump/hprof文件） 等。 恰当地使用虚拟机故障处理、分析的工具可以提升我们分析数据、 定位并解决问题的效率， 但我们在学习工具前， 也应当意识到工具永远都是知识技能的一层包装， 没有什么工具是“秘密武器”， 拥有了就能“包治百病”。
jps： 虚拟机进程状况工具
jps全称：JVM Process Status Tool ，可以列出正在运行的虚拟机进程， 并显示虚拟机执行主类（ Main Class， main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（ LVMID， Local Virtual Machine Identifier）
虽然功能比较单一， 但它绝对是使用频率最高的JDK命令行工具， 因为其他的JDK工具大多需要输入它查询到的LVMID来确定要监控的是哪一个虚拟机进程。 对于本地虚拟机进程来说， LVMID与操作系统的进程ID（ PID， Process Identifier） 是一致的， 使用Windows的任务管理器或者UNIX的ps命令也可以查询到虚拟机进程的LVMID， 但如果同时启动了多个虚拟机进程， 无法根据进程名称定位时， 那就必须依赖jps命令显示主类的功能才能区分了。
JPS命令格式：
jps [option] [hostid]
option参数有如下：
我们常用的就是 -l 快速显示出我们想要查看的系统运行进程所在的id，后续配合我们的jstat工具使用
比如我们有如下代码：
package demo6;
public class JPSDemo {
public static void main(String[] args) throws InterruptedException {
Thread.sleep(30000);
System.out.println("hello jps");
}
}
当我运行起来后，就可以通过IDEA 下方的Terminal工具输入jps命令进行查看：
我们可以看到我们当前代码所在的进程ID就是15020
jstat： 虚拟机统计信息监视工具
jstat（ JVM Statistics Monitoring Tool） 是用于监视虚拟机各种运行状态信息的命令行工具。 它可以显示本地或者远程虚拟机进程中的类加载、 内存、 垃圾收集、 即时编译等运行时数据， 在没有GUI图形界面、 只提供了纯文本控制台环境的服务器上， 它将是运行期定位虚拟机性能问题的常用工具。
jstat命令格式为：
jstat [ option vmid [interval[s|ms] [count]] ]
对于命令格式中的VMID与LVMID需要特别说明一下： 如果是本地虚拟机进程， VMID与LVMID是一致的； 如果是远程虚拟机进程， 那VMID的格式应当是：
[protocol:][//]lvmid[@hostname[:port]/servername]
参数interval和count代表查询间隔和次数， 如果省略这2个参数， 说明只查询一次。 假设需要每250毫秒查询一次进程2764垃圾收集状况， 一共查询20次， 那命令应当是：jstat -gc 2764 250 20
选项option代表用户希望查询的虚拟机信息， 主要分为三类： 类加载、 垃圾收集、 运行期编译状况。
这里知道了jstat的一些参数选项以及作用后，我们就可以结合jps命令先查询到我们当前系统运行的进程ID，然后结合jstat命令来查看当前系统的内存情况，如下：
查询结果表明： 这台服务器的新生代Eden区（E， 表示Eden） 使用了24.34%的空间， 2个Survivor区（S0、 S1， 表示Survivor0、 Survivor1） 里面都是空的， 老年代（O， 表示Old） 和 元空间 （M，表示Metaspace） 则分别使用了0%和17.34%的空间。
程序运行以来共发生Minor GC（YGC， 表示Young GC） 0次， 总耗时0.000秒； 发生Full GC（FGC， 表示Full GC） 0次， 总耗时（FGCT， 表示Full GC Time） 为0 秒； 所有GC总耗时（GCT， 表示GC Time） 为0秒。
当然我们的代码里面并没有导致GC的发生，不过jstat工具却是能非常清晰的帮助我们看到内存的占用情况以及所用的时间和发生的次数
我们再来看常用的gc选项得到的结果：
跟我们的 选项 gcutil有些区别，这里做一下解释：
- S0C：这是s0区的大小，上图代表我们的s0区是5M大小
- S1C：这是s1区的大小，上图代表我们的s1区是5M大小，跟S0是匹配的
- S0U/S1U：代表的是两个Survivor区当前使用的内存大小，目前都是0未有对象占用
- EC：Eden区的大小，32.5M
- EU：Eden区当前使用的内存大小，差不多8M
- OC：老年代大小，差不多85.5M
- OU：老年代当前使用的内存大小，0代表没有对象占用
- MC：这是方法区（永久代、元数据区）的大小
- MU：这是方法区（永久代、元数据区）当前使用的内存大小
jmap和jhat：
jmap（ Memory Map for Java） 命令用于生成堆转储快照（ 一般称为heapdump或dump文件）
jmap的作用并不仅仅是为了获取堆转储快照， 它还可以查询finalize执行队列、 Java堆和方法区的详细信息， 如空间使用率、 当前用的是哪种收集器等
jmap命令格式：
jmap [ option ] vmid
option选项的合法值与具体含义如下所示 ：
这里使用较多的主要就是两个Option：
- -histo ：如果只是想简单了解下当前jvm中的对象对内存占用的情况，直接使用jmap -histo命令即可
-dump
通过命令： jmap -dump:live,format=b,file=dump.hprof PID 会在当前目录下生成一个 dump.hrpof 文件，一个二进制格式不能直接打卡，需要借助jhat工具
JDK提供 jhat（ JVM Heap Analysis Tool） 命令与jmap搭配使用， 来分析jmap生成的堆转储快照。
jhat内置了一个微型的HTTP/Web服务器， 生成堆转储快照的分析结果后， 可以在浏览器中查看。 不过实事求是地说， 在实际工作中， 除非手上真的没有别的工具可用， 否则多数人是不会直接使用jhat命令来分析堆转储快照文件的， 主要原因有两个方面。
一是一般不会在部署应用程序的服务器上直接分析堆转储快照， 即使可以这样做， 也会尽量将堆转储快照文件复制到其他机器上进行分析， 因为分析工作是一个耗时而且极为耗费硬件资源的过程， 既然都要在其他机器上进行， 就没有必要再受命令行工具的限制了。
另外一个原因是jhat的分析功能相对来说比较简陋， 后文将会介绍到的VisualVM， 以及专业用于分析堆转储快照文件的Eclipse Memory Analyzer、 IBM HeapAnalyzer等工具， 都能实现比jhat更强大专业的分析功能。
但是对于一些小公司而言，压力不大的情况下，我们平时可以直接通过jstat jmap jhat 等工具去看看线上系统的JVM运行是否正常，有没有频繁Full GC的问题。如果有就优化，没有的话，平时每天定时去看看，或者每周都去看看即可。
通过命令解析dump快照：
通过浏览器打开查看：
小结：
本篇通过介绍JPS、Jstat、Jmap、Jhat工具的使用，如何来进行JVM内存的分析，大家可以自己结合一个程序进行练习掌握工具的基本使用。后续我们将通过两个实战案例结合工具来演示如何分析调优，帮助大家进一步掌握实操能力。
