JDK自带工具能帮助我们分析内存问题，给一个系统定位问题的时候，知识、经验是关键基础。数据是一句，工具是运用只是处理数据点手段。这里的数据包括：运行日志、异常堆栈、GC日志、线程快照（threaddump/javacore文件）、堆转储快照（heapdump/hprof文件）等。JDK命令行工具大多数是jdk/lib/tools/jar类库的一层薄包装而已，他们的主要功能代码是在tools类库中实现的。
命令行工具
jps 虚拟机进程状况工具
JVM Process Status Tool，显示指定系统内所有HotSpot虚拟机进程，功能和ps命令类似。使用频率最高，因为其他JDK工具大多需要输入他查询到的LVMID来确定要监控的是哪一个虚拟机进程。
1 jps
2 jps -v 可以查看虚拟机启动时显示指定的参数列表
jstat 虚拟机统计信息监视工具
JVM Statistics Monitoring Tool 是用于监视虚拟机各种运行状态信息的命令行工具。他可以显示本地或远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。
1 jstat [ option vmid [ interval [ s | ms] [count] ] ]
选项option 代表着用户希望查询的虚拟机信息，主要分为三类：类装载、垃圾收集、运行期编译状况。
class 监视类装载、卸载数量、总空间以及类装载所耗费的时间
gc 监视Java堆状况，包括Eden区、两个survivor区、老年代、永久代的容量、已用空间、GC时间合记的时间
gcutil 监视内容与gc基本相同，输出主要关注空间占用总空间的百分比。
compiler 输出JIT编译器编译过的方法、耗时等信息。
查看垃圾回收情况
例子：jstat -gc 2764 250 20 每250毫秒查询进程2764进程的垃圾回收情况，一共查询20次。
来瞅瞅
分别是两个Survivor区Eden区，老年代，永久代，Minor GC次数，MinorGC耗时，FullGC次数，FullGC耗时，总GC耗时
如果FullGC次数多又久那就要分析问题了，可能是配置内存太少，请出jmap
如果内存飚高，一直不回收，看YGC又很少，一般可以通过修改启动参数xmx设置小点来解决
查看类加载
分别为装载的类、装载的大小，卸载的类数量、卸载类的大小、装载和卸载类花费的时间
jinfo Java配置信息工具
Configuration Info for Java的作用是实时地查看和调整虚拟机各项参数。
jinfo [ option ] pid
1
jmap Java内存映像工具
Memory Map for Java 用于生成堆转储快照（一般称为heapdump 或 dump文件）。如果不适用jmap命令，要想获取Java堆转储快照，还有暴力手段：-XX: +HeapDumpOnOutOfMemoryError，可以让虚拟机在OOM异常出现之后自动生成dump文件。
jmap的作用并不仅仅是为了获取dump文件，还可以查询finalize执行队列、Java对和永久代的详细信息，如空间使用率、当前用的是哪种收集器等。
$ jmap
Usage:
jmap [option] <pid>
(to connect to running process)
jmap [option] <executable <core>
(to connect to a core file)
jmap [option] [server_id@]<remote server IP or hostname>
(to connect to remote debug server)
where <option> is one of:
<none> to print same info as Solaris pmap
-heap to print java heap summary
-histo[:live] to print histogram of java object heap; if the "live"
suboption is specified, only count live objects
-clstats to print class loader statistics
-finalizerinfo to print information on objects awaiting finalization
-dump:<dump-options> to dump java heap in hprof binary format
dump-options:
live dump only live objects; if not specified,
all objects in the heap are dumped.
format=b binary format
file=<file> dump heap to <file>
Example: jmap -dump:live,format=b,file=heap.bin <pid>
-F force. Use with -dump:<dump-options> <pid> or -histo
to force a heap dump or histogram when <pid> does not
respond. The "live" suboption is not supported
in this mode.
-h | -help to print this help message
-J<flag> to pass <flag> directly to the runtime system
常用option
dump 生成Java堆转储快照
heap 显示Java堆栈详细信息，如使用的回收器、参数配置等等，仅在Linux/Solaris平台下有效。
histo[:live] 显示存活的内存对象
# 生产环境慎用jmap，可能会手动造成Full GC
# 生产常用，实例最多的类 只显示前10个 。head -10就不解释了，-n是以数字大小排序，-r方向排序，-k 2排序依据是第二列数据
jmap -histo:live pid | sort -n -r -k 2 | head -10
# 统计合计容量前十的类
A：jmap -histo pid | sort -n -r -k 3 | head 10
jhat 虚拟机堆转储快照分析工具
JVM Heap Analysis Tool.jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在浏览器查看，但是实用性并不高。
jstack Java堆栈跟踪工具
jstack一般用来分析cpu飙高的问题，可能是死循环或者死锁，请求外部资源导致长时间等待，当然做性能压测的时候也会影响到CPU，可以查看各个线程的堆栈信息
首先确定要分析的进程，一般通过top或者jps命令来确定哪个进程的cpu使用率有问题
确定要分析的线程,利用 top -H -p pid来找到线程的编号，此时要转成16进制，可以在前端使用pid..toString(16)来转换或者计算器程序员模式转
锁定线程后，用jstack pid > xxx.log命令打印文件到本地，查看该文件找到 nid为线程编号的堆栈信息来定位问题
分析堆栈，业务代码就好处理了，直接看代码。但有时是线程池的问题,如下堆栈信息，corePoolSize为0就会出现CPU打满的状态，但是这块也是看的博客，具体还要再研究一下。
其中线程状态也就是JAVA定义的几个
"pool-1-thread-1" - Thread t@10
java.lang.Thread.State: RUNNABLE
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
可视化工具
JConsole
JConsole在JDK1.5时期就已经提供的虚拟机监控工具，Java Monitoring and Management Console 是一种基于JMX的可视化监视、管理工具。他管理部分的功能是针对JMX MBean 进行管理。
VisualVM
All-in-One Java Troubleshooting Tool 是目前为止随JDK发布的功能最强大的运行监视和故障处理程序。不需要被监视的程序基于特殊Agent裕兴。
生成、浏览堆转储快照
分析程序性能
BTrace 动态日志跟踪 本身也是可以独立运行的程序，作用是在不停止目标程序运行的前提下，通过HotSpot虚拟机的HotSwap技术动态加入原本并不存在的调试代码。
MAT
eclipse插件
JVM - 性能监控工具及定位方法 (OOM、CPU 飙高)
