1.概述
在实际工作中我们难免会遇见程序执行慢、线程死锁等一系列的问题，这时候就需要我们定位具体问题然后来解决问题了。所谓的程序调优其实也就是定位问题然后解决问题。怎么定位问题喃？在JAVA程序的调优中我们无非要关注以下内容：
- JVM的情况
- 程序的情况
JVM的情况无其实就是去看一下它的类加载情况、内存使用情况、GC的情况。
程序的情况无非就是其线程的运行情况。
JDK为我们提供了两套方案来查看这两方面的情况，一方面是命令，另一方面是工具。
2.命令
2.1.查看JAVA进程
当然查看上面说的两方面情况的前提是要知道程序的进程是哪个对吧。所以首先是第一个常用的命令：
- jps，查看当前机器上的java进程
jps命令默认输出进程的ID号以及对应的主启动类：
jps常用的一些参数：
- -q：简洁模式，只输出Java虚拟机（JVM）的进程ID（PID），不显示主类名称或者其他详细信息。
- -m：输出运行主类（即包含main方法的类）时传递给main方法的参数。
2.2.查看虚拟机状态
jstat，查看虚拟机状态，该命令需要跟上参数来指定具体查看的项目。
jstat的主要常用参数如下：
- 监控堆内存（Heap）： jstat -gc <pid> [interval] [count]：显示GC（Garbage Collection）统计信息，包括各代堆内存的大小、已用空间、已分配对象数以及GC次数与时间等。这里要注意的是如果只是想看内存情况，jmp命令也可以办到。
类装载系统（Class Loader）： jstat -class <pid>：显示类加载器相关的统计信息，比如已加载的类数量及其占用的空间。
线程信息（Thread Information）： jstat -thread <pid>：显示有关Java线程的信息，如活动线程数、死锁检测等。
- GC算法详细信息（Detailed GC Algorithm Info）： jstat -gccapacity <pid>：显示各个分代区域的容量配置。 jstat -gcutil <pid>：提供更详细的GC使用率信息，包括堆区的使用率和永久代的使用情况。
jstat -gc的结果对应的字段含义如下：
年轻代相关指标： S0C: 第一个幸存区（Survivor Space 0）的当前容量（字节）。 S1C: 第二个幸存区（Survivor Space 1）的当前容量。 S0U: 第一个幸存区当前已使用的空间。 S1U: 第二个幸存区当前已使用的空间。
Eden区和老年代相关指标： EC: Eden区的当前容量。 EU: Eden区当前已使用的空间。 OC: 老年代（Old Generation）的当前容量。 OU: 老年代当前已使用的空间。
元空间（Metaspace）或永久代（Permanent Generation，在JDK 1.8之前的版本中）： MC: 元空间的当前容量（在JDK 1.8及更高版本中）或永久代的当前容量（在JDK 1.8之前）。 MU: 元空间当前已使用的空间或永久代当前已使用的空间。
垃圾收集次数和时间： YGCT: 自JVM启动以来，年轻代垃圾回收（Young Generation Collection）所花费的总时间。 FGCT: 自JVM启动以来，全局或全堆垃圾回收（Full Garbage Collection，也可能是并发标记清除等类型的GC）所花费的总时间。 GCT: 总共的垃圾回收时间（YGCT + FGCT）。
jstat -gccapacity 结果对应的字段含义如下：
NGCMN - 新生代（Young Generation）的最小容量。
NGCMX - 新生代的最大容量。
NGC - 当前新生代的实际容量。
OGCMN - 老年代（Old Generation）的最小容量。
OGCMX - 老年代的最大容量。
OGC - 当前老年代的实际容量。
PC/MC - 元空间（MetaSpace）的最小容量（在JDK 1.8及更高版本中）。在JDK 1.8之前，这里是永久代（PermGen）的相关字段。
PC/MC - 元空间的当前容量。
CCSMN - 如果存在的话，表示压缩类空间（Compressed Class Space）的最小容量（在启用压缩类空间的情况下）。
CCSMX - 压缩类空间的最大容量。
CCSC - 当前压缩类空间的实际容量。
OC (Old Capacity): 表示当前老年代（Old Generation）的容量，即当前老年代能容纳多少内存空间。
MCMN (Metaspace Capacity Minimum): 在JDK 1.8及更高版本中，这个字段指的是元空间（Metaspace）的最小容量。元空间取代了永久代（PermGen），用于存储类元数据和静态变量等。
MCMX (Metaspace Capacity Maximum): 表示元空间的最大容量，即元空间允许增长到的最大内存大小。
MC (Metaspace Capacity): 表示当前元空间的实际容量，即当前元空间占用的内存大小。
jstat -gcutil 结果对应的字段含义如下：
S0：第一个幸存区（Survivor Space 0）的使用率。
S1：第二个幸存区（Survivor Space 1）的使用率。
E：伊甸园区（Eden Space）的使用率。
O：老年代（Old Generation）的使用率。
M：元空间（Metaspace）的使用率。在JDK 1.8及更高版本中，元空间取代了永久代（PermGen）来存储类的元数据和静态变量。
CCS（如果存在）：压缩类空间（Compressed Class Space）的使用率（在启用压缩类空间的情况下）。
YGC：自JVM启动以来，年轻代（Young Generation）垃圾回收的次数。
YGCT：自JVM启动以来，年轻代垃圾回收所消耗的总时间。
FGC：自JVM启动以来，全局或全堆（Full GC）垃圾回收的次数。
FGCT：自JVM启动以来，全局或全堆垃圾回收所消耗的总时间。
GCT：自JVM启动以来，所有垃圾回收（包括年轻代和全局）所消耗的总时间。
2.3.查看线程的情况
查看线程的情况无非就是抓一下线程的执行记录，也就是线程快照，jstack，可以用来抓线程快照，从而展示JVM当前线程的一个总体情况。
如果Java进程启用了远程调试，jstack可以连接到远程主机上的调试端口来获取线程堆栈信息：
jstack [-l] <host>:<port>
其中，-l 参数会包含锁定信息，有助于发现死锁问题。
jstack命令输出的信息通常包括：
线程ID（Thread ID）和线程名称（Thread Name）
线程的状态（如RUNNABLE、BLOCKED、WAITING、TIMED_WAITING）
线程执行的Java方法堆栈（Method Stack Trace），按照调用顺序逐层显示，这有助于追踪线程执行流和识别阻塞点。
通过分析jstack命令的输出，可以快速找到哪些线程处于何种状态，以及可能导致性能瓶颈或问题的代码位置，从而指导进一步的问题排查和性能调优工作。
3.工具
3.1.jconsole
连接上我们想监控的程序就可以看到，这其实就是个集成了前文所有命令的功能的图形化界面：
这里需要注意的是jconsole可以用来监控MBean，也就是用JMX自行实现的监控指标，对JMX不了解但是有兴趣的读者可以移步：
3.2.jvisualVM
jvisualVM其实和jconsole在功能上大部分是重叠的也是那些命令的图形化工具：
但是其和jconsole不同的是：
当我们用到了JMX，有自定义的MBean的时候一般用jconsole来进行可视化监控。当我们需要导入线程快照的时候一般用jvisualVM。
为什么会导入jvisualVM喃？是因为在实际的生产环境中，为了防止被攻击，服务器不会开出去太多的端口，所以想通过JDK的监控工具直接远程到服务器上去其实是比较难的，所以一般是用jstack命令去抓一段线程快照，然后拉到本地来用jvisualVM来进行可视化分析从而定位问题。
4.实战场景
下面是一些使用上述JDK工具进行具体场景优化和问题排查的例子：
示例1：使用jps和jstat排查内存泄漏
场景：一个长期运行的Java服务突然出现内存占用过高，疑似存在内存泄漏。
操作： 首先，使用jps命令找到目标Java进程的ID。 接着，利用jstat -gcutil <pid>周期性地监控JVM的内存使用情况，包括年轻代、老年代和元空间的使用率，以及垃圾回收的次数和时间。 如果观察到老年代使用率不断攀升且垃圾回收频繁且无效，则可能存在内存泄漏。 进一步，通过jmap -dump:format=b,file=<filename>.hprof <pid>命令生成堆转储文件。 使用MAT（Memory Analyzer Tool）分析堆转储文件，查找是否存在大量未释放的对象及其引用路径。
示例2：使用jstack解决线程死锁问题
场景：一个Java应用在高负载下发生卡顿，初步判断可能是线程死锁。
操作： 使用jps找到目标进程ID。 执行jstack <pid>命令获取线程堆栈信息。 分析输出的线程堆栈，寻找那些状态为BLOCKED并且持有和等待资源相互关联的线程，这些往往是死锁的关键线索。 根据堆栈信息找到造成死锁的代码片段，修改代码以避免死锁发生。
示例3：使用jinfo动态调整JVM参数
场景：一个Java应用在运行时发现GC过于频繁，影响了系统性能。
操作： 使用jps找到目标进程ID。 使用jinfo -flag UseConcMarkSweepGC <pid>检查当前是否使用CMS垃圾收集器。 若确认为CMS，但是效果不佳，可以考虑调整GC参数，如增大初始堆大小 -Xms 或 最大堆大小 -Xmx，或者改变GC策略（如切换到G1垃圾收集器）。 使用jinfo -flag -Xms <new_size> <pid>或jinfo -flag -Xmx <new_size> <pid>动态调整堆大小（并非所有JVM版本都支持所有参数的动态调整）。
示例4：使用jconsole进行实时性能监控
场景：需要持续监控Java应用的CPU、内存、线程数等基础性能指标。
操作： 启动Java应用时添加 -Dcom.sun.management.jmxremote 等JMX远程监控相关参数。 运行jconsole，连接到目标Java应用。 在jconsole界面中，可以实时查看各项性能指标，并进行图表绘制和历史数据分析，快速发现潜在的性能瓶颈。 通过这些实际场景和操作步骤，可以看到JDK自带的各种工具在实际工作中是如何协同配合，帮助我们诊断和优化Java应用程序的。
