JVM-优化

JDK常用JVM优化相关命令

bin	描述	功能
jps	打印Hotspot VM进程	VMID、JVM参数、main()函数参数、主类名/Jar路径
jstat	查看Hotspot VM 运行时信息	类加载、内存、GC[可分代查看]、JIT编译  命令格式：jstat -gc 10340 250 20
jinfo	查看和修改虚拟机各项配置	-flag name=value
jmap	heapdump: 生成VM堆转储快照、查询finalize执行队列、Java堆和永久代详细信息	jmap -dump:live,format=b,file=heap.bin [VMID]
jstack	查看VM当前时刻的线程快照: 当前VM内每一条线程正在执行的方法堆栈集合	Thread.getAllStackTraces()提供了类似的功能
javap	查看经javac之后产生的JVM字节码代码	自动解析.class文件, 避免了去理解class文件格式以及手动解析class文件内容
jcmd	一个多功能工具, 可以用来导出堆, 查看Java进程、导出线程信息、 执行GC、查看性能相关数据等	几乎集合了jps、jstat、jinfo、jmap、jstack所有功能
jconsole	基于JMX的可视化监视、管理工具	可以查看内存、线程、类、CPU信息, 以及对JMX MBean进行管理
jvisualvm	JDK中最强大运行监视和故障处理工具	可以监控内存泄露、跟踪垃圾回收、执行时内存分析、CPU分析、线程分析…

JPS

jps - l 

显示线程id和执行线程的主类名 

jps -v 

显示线程id和执行线程的主类名和JVM配置信息

jinfo : 查看正在运行的JVM参数

jinfo -flags <进程id>

jinfo -flag <参数名> <进程id>

jstat

jstat -参数 线程id 执行时间（单位毫秒） 执行次数 

jstat -gc 4488 30 10

S0C S1C S0U S1U EC EU 

10752.0 10752.0 0.0 0.0 65536.0 18351.3 

OC OU PC PU YGC YGCT FGC FGCT GCT 

173568.0 0.0 21504.0 2659.6 0 0.000 0 0.000 0.000 

SXC - survivor 初始空间大小，单位字节。 

SXU - survivor 使用空间大小， 单位字节。 

EC - eden 初始空间大小 

EU - eden 使用空间大小 

OC - old 初始空间大小 

OU - old 使用空间大小 

PC - permanent 初始空间大小 

PU - permanent 使用空间大小 

YGC - youngGC 收集次数 

YGCT - youngGC收集使用时长， 单位秒 

FGC - fullGC收集次数 

FGCT - fullGC收集使用时长 

GCT - 总计收集使用总时长 YGCT+FGCT

jmap

查看内存中对象数量及大小

#查看所有对象，包括活跃以及非活跃的

jmap ‐histo <pid> | more

#查看活跃对象

jmap ‐histo:live <pid> | more

#对象说明

B byte

C char

D double

F float

I int

J long

Z boolean

[ 数组，如[I表示int[]

[L+类名 其他对象

查看内存使用情况： jmap -heap <进程id>

将内存使用情况dump到文件中

#用法：

jmap ‐dump:format=b,file=dumpFileName <pid>

#示例

jmap ‐dump:format=b,file=/tmp/dump.dat 6219

MAT(Memory Analyzer Tool)，一个基于Eclipse的内存分析工具，是一个快速、功能丰

富的JAVA heap分析工具，它可以帮助我们分析dump文件，查找内存泄漏和减少内存消耗。

jvisualvm（监控本地和远程java进程）

一个JDK内置的图形化VM监视管理工具

visualgc插件

重启jvisualvm工具

JVM常见参数

配置方式：java [options] MainClass [arguments] 

options - JVM启动参数。 配置多个参数的时候，参数之间使用空格分隔。 

参数命名： 常见为 -参数名 

参数赋值： 常见为 -参数名=参数值 | -参数名:参数值

内存设置

-Xms:初始堆大小，JVM启动的时候，给定堆空间大小。 

-Xmx:最大堆大小，JVM运行过程中，如果初始堆空间不足的时候，最大可以扩展到多少。 

-Xmn：设置年轻代大小。整个堆大小=年轻代大小+年老代大小+持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。 

-Xss： 设置每个线程的Java栈大小。JDK5.0以后每个线程Java栈大小为1M，以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。 

-XX:NewSize=n:设置年轻代大小 

-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代+年老代和的1/4 

-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5 

-XX:MaxPermSize=n:设置持久代大小

-XX:MaxTenuringThreshold：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。

内存设置经验分享

JVM中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统 下，一般限制在1.5G~2G；64为操作系统对内存无限制。 

Tomcat配置方式： 编写catalina.bat|catalina.sh，增加JAVA_OPTS参数设置。windows和linux配置方式不同。windows - set "JAVA_OPTS=%JAVA_OPTS% 自定义参数"；linux - JAVA_OPTS="$JAVA_OPTS 自定义参数" 

常见设置： 

-Xmx3550m -Xms3550m -Xmn2g -Xss128k 适合开发过程的测试应用。要求物理内存大于4G。 

-Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=160m -XX:MaxTenuringThreshold=0 适合高并发本地测试使用。且大数据对象相对较多（如IO流） 

环境： 16G物理内存，高并发服务，重量级对象中等（线程池，连接池等），常用对象比例为40%（运行过程中产生的对象40%是生命周期较长的） 

-Xmx10G -Xms10G -Xss1M -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:MaxPermSize=2048m -XX:MaxTenuringThreshold=5

收集器设置

收集器配置的时候，次收集器和全收集器必须匹配。具体匹配规则参考3.1.3 

-XX:+UseSerialGC:设置串行收集器，年轻带收集器， 次收集器 

-XX:+UseParallelGC:设置并行收集器 

-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。 

-XX:+UseParallelOldGC:设置并行年老代收集器，JDK6.0支持对年老代并行收集。 

-XX:+UseConcMarkSweepGC:设置年老代并发收集器，测试中配置这个以后，-XX:NewRatio的配置失效，原因不明。所以，此时年轻代大小最好用-Xmn设置。 

-XX:+UseG1GC:设置G1收集器

垃圾回收统计信息

类似日志的配置信息。会有控制台相关信息输出。 商业项目上线的时候，不允许使用。一定使用loggc 

-XX:+PrintGC 

-XX:+Printetails 

-XX:+PrintGCTimeStamps

-Xloggc:filename

并行收集器设置

-XX:ParallelGCThreads=n:设置并行收集器收集时最大线程数使用的CPU数。并行收集线程数。 

-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间，单位毫秒。可以减少STW时间。 

-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)并发收集器设置 

-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。 

-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。 

-XX:CMSFullGCsBeforeCompaction=n：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。 

-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片

收集器设置经验分享

关于收集器的选择JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。 

常见配置： 

并行收集器主要以到达一定的吞吐量为目标，适用于科学计算和后台处理等。 

-Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 

使用ParallelGC作为并行收集器， GC线程为20（CPU核心数>=20时），内存问题根据硬件配置具体提供。建议使用物理内存的80%左右作为JVM内存容量。 

-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC 

指定老年代收集器，在JDK5.0之后的版本，ParallelGC对应的全收集器就是ParallelOldGC。可以忽略 

-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 

指定GC时最大暂停时间。单位是毫秒。每次GC最长使用100毫秒。可以尽可能提高工作线程的执行资源。 

-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

UseAdaptiveSizePolicy是提高年轻代GC效率的配置。次收集器执行效率。 

并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域、互联网领域等。 

-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 

指定年轻代收集器为ParNew，年老代收集器ConcurrentMarkSweep，并发GC线程数为20（CPU核心>=20），并发GC的线程数建议使用（CPU核心数+3）/4或CPU核心数【不推荐使用】。 

-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection 

CMSFullGCsBeforeCompaction=5执行5次GC后，运行一次内存的整理。 

UseCMSCompactAtFullCollection执行老年代内存整理。可以避免内存碎片，提高GC过程中的效率，减少停顿时间。

简单总结

年轻代大小选择 

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。 

吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。 

年老代大小选择 

响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得： 

并发垃圾收集信息 

持久代并发收集次数 

传统GC信息 

花在年轻代和年老代回收上的时间比例 

减少年轻代和年老代花费的时间，一般会提高应用的效率 

吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代存放长期存活对象。 

较小堆引起的碎片问题，因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、整理方式进行回收。如果出现“碎片”，可能需要进行如下配置：

-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。 

-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩

package jvm;
import java.io.IOException;
import java.lang.management.GarbageCollectorMXBean;
import java.lang.management.ManagementFactory;
import java.util.List;
public class Test {
public static void main(String[] args) {
List<GarbageCollectorMXBean> l =
ManagementFactory.getGarbageCollectorMXBeans();
for(GarbageCollectorMXBean b : l) {
System.out.println(b.getName());
}
try {
System.in.read();
} catch (IOException e) {
e.printStackTrace();
}
}
}