前言
不会JVM调优的程序员不是一个好Java程序员。
一、JVM调优命令大全
jps
JVM Process Status Tool,显示指定系统内所有的HotSpot虚拟机进程.
命令格式
jps [options] [hostid]
Option参数
-l : 输出主类全名或jar路径
-q : 只输出LVMID
-m : 输出JVM启动时传递给main()的参数
-v : 输出JVM启动时显示指定的JVM参数
示例
$ jps -l -m
28920 org.apache.catalina.startup.Bootstrap start
11589 org.apache.catalina.startup.Bootstrap start
25816 sun.tools.jps.Jps -l -m
jstat
jstat(JVM statistics Monitoring)是用于监视虚拟机运行时状态信息的命令，它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。
命令格式
jstat [option] LVMID [interval] [count]
参数
[option] : 操作参数
LVMID : 本地虚拟机进程ID
[interval] : 连续输出的时间间隔
[count] : 连续输出的次数
Option参数
class class loader的行为统计。Statistics on the behavior of the class loader.
compiler HotSpt JIT编译器行为统计。Statistics of the behavior of the HotSpot Just-in-Time compiler.
gc 垃圾回收堆的行为统计。Statistics of the behavior of the garbage collected heap.
gccapacity 各个垃圾回收代容量(young,old,perm)和他们相应的空间统计。Statistics of the capacities of the generations and their corresponding spaces.
gcutil 垃圾回收统计概述。Summary of garbage collection statistics.
gccause 垃圾收集统计概述（同-gcutil），附加最近两次垃圾回收事件的原因。Summary of garbage collection statistics (same as -gcutil), with the cause of the last and
gcnew 新生代行为统计。Statistics of the behavior of the new generation.
gcnewcapacity 新生代与其相应的内存空间的统计。Statistics of the sizes of the new generations and its corresponding spaces.
gcold 年老代和永生代行为统计。Statistics of the behavior of the old and permanent generations.
gcoldcapacity 年老代行为统计。Statistics of the sizes of the old generation.
gcpermcapacity 永生代行为统计。Statistics of the sizes of the permanent generation.
printcompilation HotSpot编译方法统计。HotSpot compilation method statistics.
示例
$ jstat -class 11589
Loaded Bytes Unloaded Bytes Time
7035 14506.3 0 0.0 3.67
Loaded : 加载class的数量
Bytes : class字节大小
Unloaded : 未加载class的数量
Bytes : 未加载class的字节大小
Time : 加载时间
jstat -compiler 1262
Compiled Failed Invalid Time FailedType FailedMethod
2573 1 0 47.60 1 org/apache/catalina/loader/WebappClassLoader findResourceInternal
Compiled : 编译数量
Failed : 编译失败数量
Invalid : 无效数量
Time : 编译耗时
FailedType : 失败类型
FailedMethod : 失败方法的全限定名
$ jstat -gc 1262
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
26112.0 24064.0 6562.5 0.0 564224.0 76274.5 434176.0 388518.3 524288.0 42724.7 320 6.417 1 0.398 6.815
S0C : survivor0区的总容量
S1C : survivor1区的总容量
S0U : survivor0区已使用的容量
S1C : survivor1区已使用的容量
EC : Eden区的总容量
EU : Eden区已使用的容量
OC : Old区的总容量
OU : Old区已使用的容量
PC 当前perm的容量 (KB)
PU perm的使用 (KB)
YGC : 新生代垃圾回收次数
YGCT : 新生代垃圾回收时间
FGC : 老年代垃圾回收次数
FGCT : 老年代垃圾回收时间
GCT : 垃圾回收总消耗时间
jstat -gccapacity 1262
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC
614400.0 614400.0 614400.0 26112.0 24064.0 564224.0 434176.0 434176.0 434176.0 434176.0 524288.0 1048576.0 524288.0 524288.0 320 1
NGCMN : 新生代占用的最小空间
NGCMX : 新生代占用的最大空间
OGCMN : 老年代占用的最小空间
OGCMX : 老年代占用的最大空间
OGC：当前年老代的容量 (KB)
OC：当前年老代的空间 (KB)
PGCMN : perm占用的最小空间
PGCMX : perm占用的最大空间
jmap
jmap(JVM Memory Map)命令用于生成heap dump文件，如果不使用这个命令，还可以使用
-XX:+HeapDumpOnOutOfMemoryError参数来让虚拟机出现OOM的时候·自动生成dump文件。
jmap不仅能生成dump文件，还可以查询finalize执行队列、Java堆和永久代的详细信息，如当前使用率、当前使用的是哪种收集器等。
命令格式
jmap [option] LVMID
Option参数
dump : 生成堆转储快照
finalizerinfo : 显示在F-Queue队列等待Finalizer线程执行finalizer方法的对象
heap : 显示Java堆详细信息
histo : 显示堆中对象的统计信息
permstat : to print permanent generation statistics
F : 当-dump没有响应时，强制生成dump快照
jstack
jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。 如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。
命令格式
jstack [option] LVMID
option参数
-F : 当正常输出请求不被响应时，强制输出线程堆栈
-l : 除堆栈外，显示关于锁的附加信息
-m : 如果调用到本地方法的话，可以显示C/C++的堆栈
jinfo
jinfo(JVM Configuration info)这个命令作用是实时查看和调整虚拟机运行参数。
之前的jps -v口令只能查看到显示指定的参数，如果想要查看未被显示指定的参数的值就要使用jinfo口令。
命令格式
jinfo [option] [args] LVMID
option参数
-flag : 输出指定args参数的值
-flags : 不需要args参数，输出所有JVM参数的值
-sysprops : 输出系统属性，等同于System.getProperties()
二、实践
本实践基于JDK 1.8。
用SpringBoot搭建了一个简易的web环境。
构造内存溢出生成dump文件并分析
@Controller
public class MemoryController {
private List<User> userList = new ArrayList<>();
/**
* -Xmx32M -Xms32M
* @return
*/
@RequestMapping("/heap")
public String heap() {
long i = 0;
while(true) {
userList.add(new User(i++, UUID.randomUUID().toString()));
}
}
}
可以看到，用一个list存储了无限生成的User对象，最终会导致OOM
我已经写好了启动参数在发生OOM时生成dump文件。
然后MAT导入dump文件看看。
可以看到
提示说在我的controller里有一个对象占用了66.18%的内存，并给出了是哪个类加载器加载的。这么大的对象明显不正常，让我们继续往下看。
我们可以看到，我们的User对象在内存中就有124604个，这个数字是不正常的。
浅堆：表示一个对象结构所占用的内存大小。
深堆：表示一个对象被回收后，真实释放的内存数。
只查看强引用，我们可以发现，在task线程里，我的controller里有一个userList对象，占用了很大的内存数，造成了内存泄露。
C++的内存泄露是指程序丢失了某块内存的引用，也就是说程序员手动申请了某块内存没有调用响应的析构函数。
Java的内存泄露是指错误的操作导致了程序中无用对象不能被及时回收。
Jstack实践分析死锁
构造一个死锁。
@RequestMapping("/deadlock")
@ResponseBody
public String deadlock() {
new Thread(new Runnable() {
@Override
public void run() {
synchronized (lock1) {
try {
Thread.sleep(1000);
} catch (Exception e) {
}
synchronized (lock2) {
System.out.println("Thread1 over");
}
}
}
}).start();
new Thread(new Runnable() {
@Override
public void run() {
synchronized (lock2) {
try {
Thread.sleep(1000);
} catch (Exception e) {
}
synchronized (lock1) {
System.out.println("Thread1 over");
}
}
}
}).start();
return "deadlock";
}
访问该URL，用jstack命令导出文件。
打开txt文件。
我们可以看到线程13持有0x00000000fed94fa8锁，等待0x00000000fed94f98。
线程12持有0x00000000fed94f98锁，等待0x00000000fed94fa8。
Jstack实践死循环
死循环大家可能以为在线上环境中遇不到，但是其实是比较常见的问题。之前看过一篇博客
https://blog.csdn.net/goldenfish1919/article/details/8755378
某阿里工程师，也因为系统优化导致的小BUG产生了死循环。
当你的CPU负载过高，很可能就是产生了死循环。
用了上文中的实例。
@RequestMapping("/loop")
@ResponseBody
public List<Long> loop() {
String data = "{\"data\":[{\"partnerid\":]";
return getPartneridsFromJson(data);
}
public static List<Long> getPartneridsFromJson(String data) {
//{\"data\":[{\"partnerid\":982,\"count\":\"10000\",\"cityid\":\"11\"},{\"partnerid\":983,\"count\":\"10000\",\"cityid\":\"11\"},{\"partnerid\":984,\"count\":\"10000\",\"cityid\":\"11\"}]}
//上面是正常的数据
List<Long> list = new ArrayList<Long>(2);
if (data == null || data.length() <= 0) {
return list;
}
int datapos = data.indexOf("data");
if (datapos < 0) {
return list;
}
int leftBracket = data.indexOf("[", datapos);
int rightBracket = data.indexOf("]", datapos);
if (leftBracket < 0 || rightBracket < 0) {
return list;
}
String partners = data.substring(leftBracket + 1, rightBracket);
if (partners == null || partners.length() <= 0) {
return list;
}
while (partners != null && partners.length() > 0) {
int idpos = partners.indexOf("partnerid");
if (idpos < 0) {
break;
}
int colonpos = partners.indexOf(":", idpos);
int commapos = partners.indexOf(",", idpos);
if (colonpos < 0 || commapos < 0) {
//partners = partners.substring(idpos+"partnerid".length());//1
continue;
}
String pid = partners.substring(colonpos + 1, commapos);
if (pid == null || pid.length() <= 0) {
//partners = partners.substring(idpos+"partnerid".length());//2
continue;
}
try {
list.add(Long.parseLong(pid));
} catch (Exception e) {
//do nothing
}
partners = partners.substring(commapos);
}
return list;
}
这个程序解析Json在正常数据下不会有问题，但是一旦有错误的数据，就会产生死循环。
为了方便观察，我们把项目达成jar包放在linux上跑。
当多次访问该URL时，CPU负载已经到达很高了。TOP查看。
可以看到CPU负载已经到10.19了。非常高了，通常线上网站负载达到这个数字就已经崩了。
我们利用top命令查看线程信息。
可以发现这些java线程CPU占用率极高。
继续用jstack命令打印堆栈信息，看看这些线程在干什么。
将线程ID转换为16进制。我们可以看到线程正在执行。
至此，我们已经定位完成，只需要到该方法内部去查看该方法在干什么事情就可以了。