yangjava

Jvm性能优化

2016/01/10 JVM

GC调优(工具篇)

理论总是作为指导实践的工具,能把这些知识应用到实际工作中才是 我们的最终目的。

给一个系统定位问题的时候,知识、经验是关键基础,数据是依据,工具是运用知识处理数据的手段。这里说的数据包括:运行日志、异常堆栈、GC日志、线程快照( threaddump/javacore文件)、堆转储快照(heapdump/hprof文件)等。

JMX API: JVM内部运行时状态信息标准API

从 JVM 运行时获取GC行为数据, 最简单的办法是使用标准 JMX API 接口. JMX是获取 JVM内部运行时状态信息 的标准API. 可以编写程序代码, 通过 JMX API 来访问本程序所在的JVM，也可以通过JMX客户端执行(远程)访问。

JConsole: Java监视与管理控制台

JConsole ( Java Monitoring and Management Console ) 是—种基于JMX的可视化监视管理工具。它管理部分的功能是针对JMX MBean进行管理,由于MBean可以使用代码、中间件服务器的管理控制台或者所有符合JMX规范的软件进行访问,所以本节将会着重介绍JConsole监视部分的功能。

VisualVM:多合一故障处理工具

VisualVM(All-in-One Java Troubleshooting Tool)是到目前为止随JDK发布的功能最强大的运行监视和故障处理程序,并且可以预见在未来一段时间内都是官方主力发展的虚拟机故障处理工具。

通过插件扩展支持,VisualVM可以做到:

  • 显示虚拟机进程以及进程的配置、环境信息(jps、 jinfo)。
  • 监视应用程序的CPU、GC、堆、方法区以及线程的信息(jstat、jstack)。
  • dump以及分析堆转储快照(jmap、jhat)。
  • 方法级的程序运行性能分析,找出被调用最多、运行时间最长的方法。
  • 离线程序快照:收集程序的运行时配置、线程dump、内存dump等信息建立个快照, 可以将快照发送开发者处进行Bug反馈。
  • 其他plugins的无限的可能性……

BTrace:动态日志跟踪

BTrace是一个很“有趣”的VisualVM插件 ,本身也是可以独立运行的程序。它的作用是在不停止目标程序运行的前提下,通过HotSpot虚拟机的HotSwap技术动态加入原本并不存在的调试代码。这项功能对实际生产中的程序很有意义:经常遇到程序出现问题,但排查错误的一些必要信息,譬如方法参数、返回值等,在开发时并没有打印到日志之中,以至于不得不停掉服务,通过调试增量来加入日志代码以解决问题。当遇到生产环境服务无法随便停止时 ,缺一两句日志导致排错进行不下去是一件非常郁闷的事情。

GCViewerGC:日志分析工具

Profilers:分析器

AProf

GC调优(实战篇)

磁盘不足排查

其实，磁盘不足排查算是系统、程序层面的问题排查，并不算是JVM，但是另一方面考虑过来就是，系统磁盘的不足，也会导致JVM的运行异常，所以也把磁盘不足算进来了。并且排查磁盘不足，是比较简单，就是几个命令，然后就是逐层的排查，首先第一个命令就是df -h，查询磁盘的状态：

从上面的显示中其中第一行使用的2.8G最大，然后是挂载在 / 目录下，我们直接cd /。然后通过执行：

du -sh *

查看各个文件的大小，找到其中最大的，或者说存储量级差不多的并且都非常大的文件，把那些没用的大文件删除就好。然后，就是直接cd到对应的目录也是执行：du -sh *，就这样一层一层的执行，找到对应的没用的，然后文件又比较大的，可以直接删除。

CPU过高排查

排查过程

  • 使用top查找进程id
  • 使用top -Hp <pid>查找进程中耗cpu比较高的线程id
  • 使用printf %x <pid>将线程id十进制转十六进制
  • 使用 jstack -pid | grep -A 20 <pid>过滤出线程id锁关联的栈信息
  • 根据栈信息中的调用链定位业务代码

案例代码如下：

public class CPUSoaring {
        public static void main(String[] args) {

                Thread thread1 = new Thread(new Runnable(){
                        @Override
                        public void run() {
                                for (;;){
                                      System.out.println("I am children-thread1");
                                }
                        }
                },"children-thread1");
                
                 Thread thread2 = new Thread(new Runnable(){
                        @Override
                        public void run() {
                                for (;;){
                                      System.out.println("I am children-thread2");
                                }
                        }
                },"children-thread2");
                
                thread1.start();
                thread2.start();
                System.err.println("I am is main thread!!!!!!!!");
        }
}

  • 第一步：首先通过top命令可以查看到id为3806的进程所占的CPU最高：

  • 第二步：然后通过top -Hp pid命令，找到占用CPU最高的线程：

  • 第三步：接着通过：printf ‘%x\n’ tid命令将线程的tid转换为十六进制：xid：

  • 第四步：最后通过：**jstack pid grep xid -A 30**命令就是输出线程的堆栈信息，线程所在的位置：

  • 第五步：还可以通过jstack -l pid > 文件名称.txt 命令将线程堆栈信息输出到文件，线下查看。

    这就是一个CPU飙高的排查过程，目的就是要找到占用CPU最高的线程所在的位置，然后就是review你的代码，定位到问题的所在。使用Arthas的工具排查也是一样的，首先要使用top命令找到占用CPU最高的Java进程，然后使用Arthas进入该进程内，使用dashboard命令排查占用CPU最高的线程。，最后通过thread命令线程的信息。

内存打满排查

排查过程

  • 查找进程id：top -d 2 -c
  • 查看JVM堆内存分配情况：jmap -heap pid
  • 查看占用内存比较多的对象：jmap -histo pid | head -n 100
  • 查看占用内存比较多的存活对象：jmap -histo:live pid | head -n 100

示例

  • 第一步：top -d 2 -c

  • 第二步：jmap -heap 8338

  • 第三步：定位占用内存比较多的对象

    这里就能看到对象个数以及对象大小……

    这里看到一个自定义的类，这样我们就定位到具体对象，看看这个对象在那些地方有使用、为何会有大量的对象存在。

OOM异常排查

OOM的异常排查也比较简单，首先服务上线的时候，要先设置这两个参数：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}

指定项目出现OOM异常的时候自动导出堆转储文件，然后通过内存分析工具（Visual VM）来进行线下的分析。

首先我们来聊一聊，哪些原因会导致OOM异常，站在JVM的分区的角度：

  • Java堆
  • 方法区
  • 虚拟机栈
  • 本地方法栈
  • 程序计数器
  • 直接内存

只有程序计数器区域不会出现OOM，在Java 8及以上的元空间（本地内存）都会出现OOM。

而站在程序代码的角度来看，总结了大概有以下几点原因会导致OOM异常：

  • 内存泄露
  • 对象过大、过多
  • 方法过长
  • 过度使用代理框架，生成大量的类信息

接下来我们屋来看看OOM的排查，出现OOM异常后dump出了堆转储文件，然后打开jdk自带的Visual VM工具，导入堆转储文件，首先我使用的OOM异常代码如下：

import java.util.ArrayList;
import java.util.List;

class OOM {

        static class User{
                private String name;
                private int age;

                public User(String name, int age){
                        this.name = name;
                        this.age = age;
                }
        }

        public static void main(String[] args) throws InterruptedException {
                List<User> list = new ArrayList<>();
                for (int i = 0; i < Integer.MAX_VALUE; i++) {
                        Thread.sleep(1000);
                        User user = new User("zhangsan"+i,i);
                        list.add(user);
                }
        }

}

代码很简单，就是往集合里面不断地add对象，带入堆转储文件后，在类和实例那栏就可以看到实例最多的类：

这样就找到导致OOM异常的类，还可以通过下面的方法查看导致OOM异常的线程堆栈信息，找到对应异常的代码段。

上面的方法是排查已经出现了OOM异常的方法，肯定是防线的最后一步，那么在此之前怎么防止出现OOM异常呢？

一般大厂都会有自己的监控平台，能够实施的监控测试环境、预览环境、线上实施的服务健康状况（CPU、内存） 等信息，对于频繁GC，并且GC后内存的回收率很差的，就要引起我们的注意了。

因为一般方法的长度合理，95%以上的对象都是朝生夕死，在Minor GC后只剩少量的存活对象，所以在代码层面上应该避免方法过长、大对象的现象。

每次自己写完代码，自己检查后，都可以提交给比自己高级别的工程师review自己的代码，就能及时的发现代码的问题，基本上代码没问题，百分之九十以上的问题都能避免，这也是大厂注重代码质量，并且时刻review代码的习惯。

Jvisualvm

项目频繁YGC 、FGC问题排查

内存问题

对象内存占用、实例个数监控

img

对象内存占用、年龄值监控

img

通过上面两张图发现这些对象占用内存比较大而且存活时间也是比较常，所以survivor 中的空间被这些对象占用，而如果缓存再次刷新则会创建同样大小对象来替换老数据，这时发现eden内存空间不足，就会触发yonggc 如果yonggc 结束后发现eden空间还是不够则会直接放到老年代，所以这样就产生了大对象的提前晋升，导致fgc增加……

优化办法：优化两个缓存对象，将缓存对象大小减小。优化一下两个对象，缓存关键信息！

CPU耗时问题排查

Cpu使用耗时监控：

img

耗时、调用次数监控：

img

从上面监控图可以看到主要耗时还是在网络请求，没有看到具体业务代码消耗过错cpu……

调优堆内存分配

初始堆空间大小设置

  • 使用系统默认配置在系统稳定运行一段时间后查看记录内存使用情况：Eden、survivor0 、survivor1 、old、metaspace
  • 按照通用法则通过gc信息分配调整大小，整个堆大小是Full GC后老年代空间占用大小的3-4倍
  • 老年代大小为Full GC后老年代空间占用大小的2-3倍
  • 新生代大小为Full GC后老年代空间占用大小的1-1.5倍
  • 元数据空间大小为Full GC后元数据空间占用大小的1.2-1.5倍

活跃数大小是应用程序运行在稳定态时，长期存活的对象在java堆中占用的空间大小。也就是在应用趋于稳太时FullGC之后Java堆中存活对象占用空间大小。（注意在jdk8中将jdk7中的永久代改为元数据区，metaspace 使用的物理内存，不占用堆内存）

堆大小调整的着手点、分析点

  • 统计Minor GC 持续时间
  • 统计Minor GC 的次数
  • 统计Full GC的最长持续时间
  • 统计最差情况下Full GC频率
  • 统计GC持续时间和频率对优化堆的大小是主要着手点，我们按照业务系统对延迟和吞吐量的需求，在按照这些分析我们可以进行各个区大小的调整

年轻代调优

年轻代调优规则

  • 老年代空间大小不应该小于活跃数大小1.5倍。老年代空间大小应为老年代活跃数2-3倍
  • 新生代空间至少为java堆内存大小的10% 。新生代空间大小应为1-1.5倍的老年代活跃数
  • 在调小年轻代空间时应保持老年代空间不变

MinorGC是收集eden+from survivor 区域的，当业务系统匀速生成对象的时候如果年轻带分配内存偏小会发生频繁的MinorGC，如果分配内存过大则会导致MinorGC停顿时间过长，无法满足业务延迟性要求。所以按照堆分配空间分配之后分析gc日志，看看MinorGC的频率和停顿时间是否满足业务要求。

  • MinorGC频繁原因 MinorGC 比较频繁说明eden内存分配过小，在恒定的对象产出的情况下很快无空闲空间来存放新对象所以产生了MinorGC,所以eden区间需要调大。

  • 年轻代大小调整 Eden调整到多大那，我们可以查看GC日志查看业务多长时间填满了eden空间，然后按照业务能承受的收集频率来计算eden空间大小。比如eden空间大小为128M每5秒收集一次，则我们为了达到10秒收集一次则可以调大eden空间为256M这样能降低收集频率。年轻代调大的同时相应的也要调大老年代，否则有可能会出现频繁的concurrent model failed 从而导致Full GC 。

  • MinorGC停顿时间过长 MinorGC 收集过程是要产生STW的。如果年轻代空间太大，则gc收集时耗时比较大，所以我们按业务对停顿的要求减少内存，比如现在一次MinorGC 耗时12.8毫秒，eden内存大小192M ,我们为了减少MinorGC 耗时我们要减少内存。比如我们MinorGC 耗时标准为10毫秒，这样耗时减少16.6% 同样年轻代内存也要减少16.6% 即192*0.1661 = 31.89M 。年轻代内存为192-31.89=160.11M,在减少年轻代大小，而要保持老年代大小不变则要减少堆内存大小至512-31.89=480.11M

堆内存：512M 年轻代: 192M 收集11次耗时141毫秒 12.82毫秒/次

img

堆内存：512M 年轻代：192M 收集12次耗时151毫秒 12.85毫秒/次

img

按照上面计算调优 堆内存： 480M 年轻带： 160M 收集14次 耗时154毫秒 11毫秒/次 相比之前的 12.82毫秒/次 停顿时间减少1.82毫秒

img

但是还没达到10毫秒的要求，继续按照这样的逻辑进行 11-10=1 ；1/11= 0.909 即 0.09 所以耗时还要降低9%。 年轻代减少：160*0.09 = 14.545=14.55 M; 160-14.55 =145.45=145M 堆大小： 480-14.55 = 465.45=465M 但是在这样调整后使用jmap -heap 查看的时候年轻代大小和实际配置数据有出入（年轻代大小为150M大于配置的145M），这是因为-XX:NewRatio 默认2 即年轻代和老年代1：2的关系，所以这里将-XX:NewRatio 设置为3 即年轻代、老年大小比为1：3 ，最终堆内存大小为：

img

MinorGC耗时 159/16=9.93毫秒

img

MinorGC耗时 185/18=10.277=10.28毫秒

img

MinorGC耗时 205/20=10.25毫秒

img

Ok 这样MinorGC停顿时间过长问题解决，MinorGC要么比较频繁要么停顿时间比较长，解决这个问题就是调整年轻代大小，但是调整的时候还是要遵守这些规则。

老年代调优

按照同样的思路对老年代进行调优，同样分析FullGC 频率和停顿时间，按照优化设定的目标进行老年代大小调整。

老年代调优流程

  • 分析每次MinorGC 之后老年代空间占用变化，计算每次MinorGC之后晋升到老年代的对象大小
  • 按照MinorGC频率和晋升老年代对象大小计算提升率即每秒钟能有多少对象晋升到老年代
  • FullGC之后统计老年代空间被占用大小计算老年带空闲空间，再按照第2部计算的晋升率计算该老年代空闲空间多久会被填满而再次发生FullGC，同样观察FullGC 日志信息，计算FullGC频率，如果频率过高则可以增大老年代空间大小老解决，增大老年代空间大小应保持年轻代空间大小不变
  • 如果在FullGC 频率满足优化目标而停顿时间比较长的情况下可以考虑使用CMS、G1收集器。并发收集减少停顿时间

栈溢出

栈溢出异常的排查（包括虚拟机栈、本地方法栈）基本和OOM的一场排查是一样的，导出异常的堆栈信息，然后使用mat或者Visual VM工具进行线下分析，找到出现异常的代码或者方法。

当线程请求的栈深度大于虚拟机栈所允许的大小时，就会出现StackOverflowError异常，二从代码的角度来看，导致线程请求的深度过大的原因可能有：方法栈中对象过大，或者过多，方法过长从而导致局部变量表过大，超过了-Xss参数的设置。

死锁排查

死锁的案例演示的代码如下：

public class DeadLock {

	public static Object lock1 = new Object();
	public static Object lock2 = new Object();

	public static void main(String[] args){
		Thread a = new Thread(new Lock1(),"DeadLock1");
		Thread b = new Thread(new Lock2(),"DeadLock2");
		a.start();
		b.start();
	}
}
class Lock1 implements Runnable{
	@Override
	public void run(){
		try{
			while(true){
				synchronized(DeadLock.lock1){
					System.out.println("Waiting for lock2");
					Thread.sleep(3000);
					synchronized(DeadLock.lock2){
						System.out.println("Lock1 acquired lock1 and lock2 ");
					}
				}
			}
		}catch(Exception e){
			e.printStackTrace();
		}
	}
}
class Lock2 implements Runnable{
	@Override
	public void run(){
		try{
			while(true){
				synchronized(DeadLock.lock2){
					System.out.println("Waiting for lock1");
					Thread.sleep(3000);
					synchronized(DeadLock.lock1){
						System.out.println("Lock2 acquired lock1 and lock2");
					}
				}
			}
		}catch(Exception e){
			e.printStackTrace();
		}
	}
}

上面的代码非常的简单，就是两个类的实例作为锁资源，然后分别开启两个线程，不同顺序的对锁资源资源进行加锁，并且获取一个锁资源后，等待三秒，是为了让另一个线程有足够的时间获取另一个锁对象。

运行上面的代码后，就会陷入死锁的僵局：

死锁排查-死锁运行结果示例

对于死锁的排查，若是在测试环境或者本地，直接就可以使用Visual VM连接到该进程，如下界面就会自动检测到死锁的存在

死锁排查-检测死锁

并且查看线程的堆栈信息。就能看到具体的死锁的线程：

死锁排查-查看线程堆栈信息

线上的话可以上用Arthas也可以使用原始的命令进行排查，原始命令可以先使用jps查看具体的Java进程的ID，然后再通过jstack ID查看进程的线程堆栈信息，他也会自动给你提示有死锁的存在：

死锁排查-jstack查看线程堆栈

Arthas工具可以使用thread命令排查死锁，要关注的是BLOCKED状态的线程，如下图所示：

死锁排查-Arthas查看死锁

具体thread的详细参数可以参考如下图所示：

死锁排查-Thread详细参数

如何避免死锁

上面我们聊了如何排查死锁，下面我们来聊一聊如何避免死锁的发生，从上面的案例中可以发现，死锁的发生两个线程同时都持有对方不释放的资源进入僵局。所以，在代码层面，要避免死锁的发生，主要可以从下面的四个方面进行入手：

  • 首先避免线程的对于资源的加锁顺序要保持一致

  • 并且要避免同一个线程对多个资源进行资源的争抢

  • 另外的话，对于已经获取到的锁资源，尽量设置失效时间，避免异常，没有释放锁资源，可以使用acquire() 方法加锁时可指定 timeout 参数

  • 最后，就是使用第三方的工具检测死锁，预防线上死锁的发生

死锁的排查已经说完了，上面的基本就是问题的排查，也可以算是调优的一部分吧，但是对于JVM调优来说，重头戏应该是在Java堆，这部分的调优才是重中之重。

调优实战

上面说完了调优的目的和调优的指标，那么我们就来实战调优，首先准备我的案例代码，如下：

import java.util.ArrayList;
import java.util.List;

class OOM {

	static class User{
		private String name;
		private int age;

		public User(String name, int age){
			this.name = name;
			this.age = age;
		}

	}

	public static void main(String[] args) throws InterruptedException {
		List<User> list = new ArrayList<>();
		for (int i = 0; i < Integer.MAX_VALUE; i++) {
		     Tread.sleep(1000);
			System.err.println(Thread.currentThread().getName());
			User user = new User("zhangsan"+i,i);
			list.add(user);
		}
	}
}

案例代码很简单，就是不断的往一个集合里里面添加对象，首先初次我们启动的命令为：

java   -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM

就是纯粹的设置了一些GC的打印日志，然后通过Visual VM来看GC的显示如下：

调优实战-VisualVM查看GC显示

可以看到一段时间后出现4次Minor GC，使用的时间是29.648ms，发生一次Full GC使用的时间是41.944ms。

Minor GC非常频繁，Full GC也是，在短时间内就发生了几次，观察输出的日志发现以及Visual VM的显示来看，都是因为内存没有设置，太小，导致Minor GC频繁。

因此，我们第二次适当的增大Java堆的大小，调优设置的参数为：

java -Xmx2048m -Xms2048m -Xmn1024m -Xss256k  -XX:+UseConcMarkSweepGC  -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM

观察一段时间后，结果如下图所示：

调优实战-一段时间后VisualVM查看GC显示

可以发现Minor GC次数明显下降，但是还是发生了Full GC，根据打印的日志来看，是因为元空间的内存不足，看了上面的Visual VM元空间的内存图，也是一样，基本都到顶了：

调优实战-元空间不足

因此第三次对于元空间的区域设置大一些，并且将GC回收器换成是CMS的，设置的参数如下：

java -Xmx2048m -Xms2048m -Xmn1024m -Xss256k -XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m -XX:+UseConcMarkSweepGC  -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM

观察相同的时间后，Visual VM的显示图如下：

调优实战-元空间调后后VisualVM查看GC显示

同样的时间，一次Minor GC和Full GC都没有发生，所以这样我觉得也算是已经调优了。

但是调优并不是一味的调大内存，是要在各个区域之间取得平衡，可以适当的调大内存，以及更换GC种类，举个例子，当把上面的案例代码的Thread.sleep(1000)给去掉。

然后再来看Visual VM的图，如下：

调优实战-去掉线程休眠VisualVM显示

可以看到Minor GC也是非常频繁的，因为这段代码本身就是不断的增大内存，直到OOM异常，真正的实际并不会这样，可能当内存增大到一定两级后，就会在一段范围平衡。

当我们将上面的情况，再适当的增大内存，JVM参数如下：

java -Xmx4048m -Xms4048m -Xmn2024m -XX:SurvivorRatio=7  -Xss256k -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=100m -XX:+UseConcMarkSweepGC  -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM

可以看到相同时间内，确实Minor GC减少了，但是时间增大了，因为复制算法，基本都是存活的，复制需要耗费大量的性能和时间：

调优实战-减少MinorGC后VisualVM显示

所以，调优要有取舍，取得一个平衡点，性能、状态达到佳就OK了，并没最佳的状态，这就是调优的基本法则，而且调优也是一个细活，所谓慢工出细活，需要耗费大量的时间，慢慢调，不断的做对比。

调优参数

堆

  • -Xms1024m 设置堆的初始大小
  • -Xmx1024m 设置堆的最大大小
  • -XX:NewSize=1024m 设置年轻代的初始大小
  • -XX:MaxNewSize=1024m 设置年轻代的最大值
  • -XX:SurvivorRatio=8 Eden和S区的比例
  • -XX:NewRatio=4 设置老年代和新生代的比例
  • -XX:MaxTenuringThreshold=10 设置晋升老年代的年龄条件

栈

  • -Xss128k

元空间

  • -XX:MetasapceSize=200m 设置初始元空间大小
  • -XX:MaxMatespaceSize=200m 设置最大元空间大小 默认无限制

直接内存

  • -XX:MaxDirectMemorySize 设置直接内存的容量，默认与堆最大值一样

日志

  • -Xloggc:/opt/app/ard-user/ard-user-gc-%t.log 设置日志目录和日志名称
  • -XX:+UseGCLogFileRotation 开启滚动生成日志
  • -XX:NumberOfGCLogFiles=5 滚动GC日志文件数，默认0，不滚动
  • -XX:GCLogFileSize=20M GC文件滚动大小，需开 UseGCLogFileRotation
  • -XX:+PrintGCDetails 开启记录GC日志详细信息（包括GC类型、各个操作使用的时间）,并且在程序运行结束打印出JVM的内存占用情况
  • -XX:+ PrintGCDateStamps 记录系统的GC时间
  • -XX:+PrintGCCause 产生GC的原因(默认开启)

GC

Serial垃圾收集器（新生代）

开启

  • -XX:+UseSerialGC

关闭：

  • -XX:-UseSerialGC //新生代使用Serial 老年代则使用SerialOld

Parallel Scavenge收集器（新生代）开启

  • -XX:+UseParallelOldGC 关闭
  • -XX:-UseParallelOldGC 新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器

ParallelOl垃圾收集器（老年代）开启

  • -XX:+UseParallelGC 关闭
  • -XX:-UseParallelGC 新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器

ParNew垃圾收集器（新生代）开启

  • -XX:+UseParNewGC 关闭
  • -XX:-UseParNewGC //新生代使用功能ParNew 老年代则使用功能CMS

CMS垃圾收集器（老年代）开启

  • -XX:+UseConcMarkSweepGC 关闭
  • -XX:-UseConcMarkSweepGC
  • -XX:MaxGCPauseMillis GC停顿时间，垃圾收集器会尝试用各种手段达到这个时间，比如减小年轻代
  • -XX:+UseCMSCompactAtFullCollection 用于在CMS收集器不得不进行FullGC时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，（在Shenandoah和ZGC出现前）是无法并发的
  • -XX：CMSFullGCsBefore-Compaction 多少次FullGC之后压缩一次，默认值为0，表示每次进入FullGC时都进行碎片整理）
  • -XX:CMSInitiatingOccupancyFraction 当老年代使用达到该比例时会触发FullGC，默认是92
  • -XX:+UseCMSInitiatingOccupancyOnly 这个参数搭配上面那个用，表示是不是要一直使用上面的比例触发FullGC，如果设置则只会在第一次FullGC的时候使用-XX:CMSInitiatingOccupancyFraction的值，之后会进行自动调整
  • -XX:+CMSScavengeBeforeRemark 在FullGC前启动一次MinorGC，目的在于减少老年代对年轻代的引用，降低CMSGC的标记阶段时的开销，一般CMS的GC耗时80%都在标记阶段
  • -XX:+CMSParallellnitialMarkEnabled 默认情况下初始标记是单线程的，这个参数可以让他多线程执行，可以减少STW
  • -XX:+CMSParallelRemarkEnabled 使用多线程进行重新标记，目的也是为了减少STW

G1垃圾收集器开启

  • -XX:+UseG1GC 关闭
  • -XX:-UseG1GC
  • -XX：G1HeapRegionSize 设置每个Region的大小，取值范围为1MB～32MB
  • -XX：MaxGCPauseMillis 设置垃圾收集器的停顿时间，默认值是200毫秒，通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的

Search

    微信好友

    博士的沙漏

    Table of Contents