本文转载自 http://alanhou.org/java-optimization/
1 JVM的参数类型
1.1 标准参数（各版本中保持稳定）
-help
-server -client
-version -showversion
-cp -classpath
1.2 X 参数（非标准化参数）
-Xint：解释执行
-Xcomp：第一次使用就编译成本地代码(即时编译执行)
-Xmixed：混合模式，JVM 自己决定是否编译成本地代码
- 示例：
java -version（默认是混合模式）
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
java -Xint -version
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, interpreted mode)
1.3 XX 参数（非标准化参数）
主要用于 JVM调优和 debug
- Boolean类型
格式：-XX:[+-]<name> 表示启用或者禁用name属性
比如：
-XX:+UseConcMarkSweepGC使用CMS的GC
-XX:UseG1GC
- 非Boolean类型
格式：-XX:<name>=<value>表示name的属性的值是value
比如：
-XX:MaxGCPauseMillis=500设置GC最大停顿时间500ms
-XX:GCTimeRatio=19
-Xms 设置最小堆内存空间,初始化时的大小等价于 -XX:InitialHeapSize
-Xmx 设置堆内存空间的最大值等价于 -XX:MaxHeapSize
-Xss 堆栈的大小等价于 -XX:ThreadStackSize
1.4 查看
jinfo -flag MaxHeapSize <pid>
-XX:+PrintFlagsInitial
-XX:+PrintFlagsFinal
-XX:+UnlockExperimentalVMOptions 解锁实验参数
-XX:+UnlockDiagnosticVMOptions 解锁诊断参数
-XX:+PrintCommandLineFlags 打印命令行参数
输出结果中=表示默认值，:=表示被用户或 JVM 修改后的值
示例：java -XX:+PrintFlagsFinal -version 执行此命令会新启动一个jvm进程，并打印出所有最终的参数值。关于如何在已有的jvm中查看参数呢？可以看jinfo的相关用法
- 补充：测试中需要用到 Tomcat，CentOS 7安装示例如下
sudo yum -y install java-1.8.0-openjdk*
wget http://mirror.bit.edu.cn/apache/tomcat/tomcat-8/v8.5.32/bin/apache-tomcat-8.5.32.tar.gz
tar -zxvf apache-tomcat-8.5.32.tar.gz
mv apache-tomcat-8.5.32 tomcat
cd tomcat/bin/
sh startup.sh
pid 可通过类似 ps -ef|grep tomcat或 jps来进行查看
1.5 jps
详情参考 jps官方文档
-l : 打印出进程的main方法名
1.6 jinfo
是jdk自带的一个工具，它可以用来查看正在运行的java应用程序的扩展参数（JVM中-X标示的参数）；甚至支持在运行时修改部分参数。
jinfo -flag MaxHeapSize <pid>
jinfo <pid>
-
查看进程的最大内存
image.png -
查看垃圾回收器
image.png
1.7 jstat
查看jvm统计的内存占用信息和类加载时间等
- 类装载信息
垃圾收集信息
JIT编译信息
详情参考 jstat 官方文档
- 类加载
-- 以下1000表示每隔1000ms 输出一次，共输出10次
jstat -class <pid> 1000 10
- 垃圾收集
-gc, -gcutil, -gccause, -gcnew, -gcold
jstat -gc <pid> 1000 10
以下大小的单位均为 KB
S0C, S1C, S0U, S1U: S0和 S1的总量和使用量
EC, EU: Eden区总量与使用量
OC, OU: Old区总量与使用量
MC, MU: Metacspace区(jdk1.8前为 PermGen)总量与使用量
CCSC, CCSU: 压缩类区总量与使用量
YGC, YGCT: YoungGC 的次数与时间
FGC, FGCT: FullGC 的次数与时间
GCT: 总的 GC 时间
- JIT 编译
-compiler, -printcompilation
1.8 jmap+MAT
详情参考jmap 官方文档
内存溢出演示：
https://start.spring.io/生成初始代码
最终代码：monitor_tuning
为快速产生内存溢出，右击 Run As>Run Configurations, Arguments 标签VM arguments 中填入
- 堆内存溢出
-Xmx32M -Xms32M
访问 http://localhost:8080/heap
Exception in thread "http-nio-8080-exec-2" Exception in thread "http-nio-8080-exec-1" java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
- 非堆内存溢出
–XX:MetaspaceSize=32M –XX:MaxMetaspaceSize=32M（同时在 pom.xml 中加入 asm 的依赖）
访问 http://localhost:8080/nonheap
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
- 内存溢出的主要原因
内存溢出有2个原因：1 内存泄漏（c++中的内存泄露表示，把某个对象的指针丢了则一直都将得不到释放内存，java中的内存泄露表示，一直占用某个对象而不释放，导致内存无法释放） 2 内存不足
- 内存溢出自动导出
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./
右击 Run As>Run Configurations, Arguments 标签VM arguments 中填入
-Xmx32M -Xms32M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./
可以看到自动在当前目录中生成了一个java_pid41140.hprof文件
java.lang.OutOfMemoryError: Java heap space
Dumping heap to ./\java_pid41140.hprof ...
Heap dump file created [42942003 bytes in 0.219 secs]
Exception in thread "http-nio-12345-exec-1" java.lang.OutOfMemoryError: Java heap space
- 另一种导出溢出也更推荐的方式是jmap
option: -heap, -clstats, -dump:<dump-options>, -F
jmap -dump:format=b,file=heap.hprof <pid>
D:\workspace\jvmTunning>jps
42992 Jps
41140 MonitorTuningApplication
10680
40584 RemoteMavenServer
42956 Launcher
D:\workspace\jvmTunning>jinfo -flag MaxHeapSize 41140
-XX:MaxHeapSize=33554432
D:\workspace\jvmTunning>jmap -dump:format=b,file=heap.hprof 41140
Dumping heap to D:\workspace\jvmTunning\heap.hprof ...
Heap dump file created
- MAT下载地址：http://www.eclipse.org/mat/
image.png
内存映射文件的分析工具 MAT， 1 查看对象占用的内存 2 查看对象的数量 这两个方法基本上就能排查出内存泄漏的地方
导出内存映射文件，有2个方法，1是自动导出 2 jmap导出。 当内存比较大的时候，用jmap比较合适，自动导出可能会失败
1.9 jstack
详情参考 jstack 官方文档
jstack <pid>
可查看其中包含java.lang.Thread.State: WAITING (parking)，JAVA 线程包含的状态有：
NEW：线程尚未启动
RUNNABLE：线程正在 JVM 中执行
BLOCKED：线程在等待监控锁(monitor lock)
WAITING：线程在等待另一个线程进行特定操作（时间不确定）
TIMED_WAITING：线程等待另一个线程进行限时操作
TERMINATED：线程已退出
monitor_tuning中新增CpuController.java
mvn clean package -Dmaven.test.skip
mvn 打包提速参考 CSDN
此时会生成一个monitor_tuning-0.0.1-SNAPSHOT.jar的 jar包，为避免本地的 CPU 消耗过多导致死机，建议上传上传到虚拟机进行测试
nohup java -jar monitor_tuning-0.0.1-SNAPSHOT.jar & 代表运行一个jar程序，并把输出内容重定向到nohup的文件中去。
访问 http://xx.xx.xx.xx:12345/loop(端口12345在application.properties文件中定义)
top -p <pid> -H可以查看线程及 CPU 消耗情况
使用 jstack <pid>可以导出追踪文件，文件中 PID 在 jstack 中显示的对应 nid 为十六进制(命令行可执行
print ‘%x’ <pid>可以进行转化，如1640对应的十六进制为668)
"http-nio-12345-exec-9" #24 daemon prio=5 os_prio=0 tid=0x00007faa2c783000 nid=0x668 waiting on condition [0x00007faa186de000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000ee20d078> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
访问http://xx.xx.xx.xx:12345/deadlock(如上jstack <pid>导出追踪记录会发现如下这样的记录)
Found one Java-level deadlock:
=============================
"Thread-5":
waiting to lock monitor 0x00007fb854004d78 (object 0x00000000ee0b89a8, a java.lang.Object),
which is held by "Thread-4"
"Thread-4":
waiting to lock monitor 0x00007fb854004cc8 (object 0x00000000ee0b89b8, a java.lang.Object),
which is held by "Thread-5"
Java stack information for the threads listed above:
===================================================
"Thread-5":
at com.imooc.monitor_tuning.chapter2.CpuController.lambda$deadlock$1(CpuController.java:41)
- waiting to lock <0x00000000ee0b89a8> (a java.lang.Object)
- locked <0x00000000ee0b89b8> (a java.lang.Object)
at com.imooc.monitor_tuning.chapter2.CpuController$$Lambda$336/267566858.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
"Thread-4":
at com.imooc.monitor_tuning.chapter2.CpuController.lambda$deadlock$0(CpuController.java:33)
- waiting to lock <0x00000000ee0b89b8> (a java.lang.Object)
- locked <0x00000000ee0b89a8> (a java.lang.Object)
at com.imooc.monitor_tuning.chapter2.CpuController$$Lambda$335/1121907286.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Found 1 deadlock.
