jps, jmap, jhat, mat, jstat

jps:

与unix上的ps类似，用来显示本地的java进程，可以查看本地运行着几个java程序，并显示他们的进程号。

jps -mlv

可查看java进程的全路径名

jmap:

jmap（java memory map）是用来对正在运行的java进程进行内存、对象分析的。通过jmap可以获得进程中不同类的实例数量，并可以dump出当前进程状态，供分析使用（使用jhat，MAT等分析工具）。

常用参数：

jmap -histo[:live] ${pid}

打印某pid中，不同类的实例数量和占用空间，默认按占用空间排序。如果使用了:live选项，仅获取生存的对象，但是会导致gc。
tips：
由于Spring中ioc自动扫描的bean，默认都是单例。如果某个Service出现两个bean，会导致一些问题，常见的是null pointer等。通过日志可以确认有没有类的覆盖（override），通过jmap定位到该类，确认是否有多个实例被创建。
注：
jmap -histo，如果加了:live会导致程序进入gc，stop-the-world。

jmap -dump:[live,]format=b,file=${XXXDump.bin} ${pid}

将某pid的内存镜像dump下来，存为${XXXDump.bin}文件，用于结合jhat，MAT分析。
tips：
获取内存镜像可以做很多工作，比如用jhat获得不同类的所有实例个数，每个实例的内部变量值等等。
注：

1. jmap -dump这个命令执行，JVM会将整个heap的信息dump写入到一个文件，heap如果比较大的话，就会导致这个过程比较耗时，并且执行的过程中为了保证dump的信息是可靠的，所以会暂停应用。
2. 如果想dump堆信息，可以使用gcore命令，比jmap -dump快。

jmap -heap ${pid}

-heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况。通常用来排查jvm的问题（如gc次数、时间异常等，配合jstat -gcutils排查）
###经典场景：

1. 内存泄漏memory leak，通过jmap -histo获取类的实例数量，判断是否有问题。
2. 发现有本应是单例的结果重复加载（日志中的override、莫名的nullpointer等），通过jmap -dump获取内存镜像，用jhat和MAT分析。
   用jhat ${pid}可以解析镜像文件到域名（默认本机7000），直接用浏览器访问也可以得到类和实例的状态。有MAT可以分析得更可视化。

jhat:

jhat命令解析会Java堆dump并启动一个web服务器，默认7000端口，可以在浏览器中查看堆的dump文件，获得dump文件中的对象数量及状态。常与jmap命令合作，使用jmap -dump:format=b,file=a.bin ${pid}获取dump文件后，使用jhat进行分析。个人认为jhat的功能是MAT功能的子集。
常用功能有

1. Show instance counts for all classes (excluding platform)，平台外的所有对象信息。
   以及
2. Show heap histogram 以树状图形式展示堆情况。
   树状图的输出很像jmap -histo的结果，用法也类似。
   此命令的常用方式是分析dump文件，可以用浏览器轻松获取某个类的实例对象，是否被加载了等等。

mat:

http://blog.csdn.net/itomge/article/details/48719527
http://www.lightskystreet.com/2015/09/01/mat_usage/
http://blog.csdn.net/xx326664162/article/details/50084543

jstat:

jstat也是jdk提供的对jvm监控的工具之一，使用方法网上文章较多。如http://blog.csdn.net/fenglibing/article/details/6411951。笔者常用的选项包括：
jstat -gcutil {pid} {timeinterval} ：可以指定时间间隔打印jvm的各部分空间占用，以及gc数据。
jstat -gccause {pid} ：可以获取gc的原因
jstat -class {pid} ：可以打印jvm的类加载信息，如加载类的数量，占用空间，加载类的耗时等。

tip1: jstat为什么只有ygc和fgc，没有major gc的信息？

此处提出一点笔者的积累。jvm的minor gc概念清晰（回收young gen），但是major gc和full gc的概念较为模糊，详情可见http://blog.csdn.net/ligeforrent/article/details/76619057中R大在知乎的回答。 这种模糊在jstat中也有所体现。
在jstat中关于gc的指标只有ygc和fgc，没有major gc的数据。这一度让笔者感到不解，直到看到了一篇译文（http://blog.csdn.net/ligeforrent/article/details/76619057）。其中明确地指出，其实jstat中的fgc不能真正表示full gc，它是指：发生old gen清理时，stop-the-world的次数和时间。
由于CMS中存在独立的major gc(CMS GC) 和 full gc，当发生CMS GC时，会发生初始标记-并发标记-重新标记-并发清理。其中1,3是STW的，会在jstat中体现为两次fgc。其实在CMS GC工作正常时，是不需要发生真正的serial full gc的。这种情况只能在GC日志中看出，通过jstat是看不出的。
如果把jstat中的fgc理解为stop-the-world，它的输出结果也是正确的，一次CMS GC确实会发生两次较短的stw（相较于serial full gc较短）。