1、如何确定垃圾

1.1. 引用计数法

在 Java 中，引用和对象是有关联的。如果要操作对象则必须用引用进行。因此，很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。简单说，即一个对象如果没有任何与之关联的引用，即他们的引用计数都为 0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。当然，这也就引发了一个问题：循环引用的对象是无法被识别出来并且被回收的。

1.2 可达性分析

为了解决引用计数法的循环引用问题，Java 使用了可达性分析的方法。通过一系列的“GC roots” 对象作为起点搜索。如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。

要注意的是，不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象，则将面临回收。

2、清理垃圾方法

2.1. 标记清除算法（Mark-Sweep）

最基础的垃圾回收算法，分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。如图

从图中我们就可以发现，该算法最大的问题是内存碎片化严重，后续可能发生大对象不能找到可利用空间的问题。

2.2. 复制算法（copying）

为了解决 Mark-Sweep 算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清掉，如图：

这种算法虽然实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原本的一半。且存活对象增多的话，Copying 算法的效率会大大降低。

2.3. 标记整理算法(Mark-Compact)

结合了以上两个算法，为了避免缺陷而提出。标记阶段和 Mark-Sweep 算法相同，标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。如图：

2.3. 分代收集算法

分代收集法是目前大部分 JVM 所采用的方法,其核心思想是根据对象存活的不同生命周期将内存划分为不同的域，一般情况下将 GC 堆划分为老生代(Tenured/Old Generation)和新生代(Young Generation)。老生代的特点是每次垃圾回收时只有少量对象需要被回收，新生代的特点是每次垃圾回收时都有大量垃圾需要被回收，因此可以根据不同区域选择不同的算法。

2.3.1. 新生代与复制算法

目前大部分 JVM 的 GC 对于新生代都采取复制（Copying )算法，因为新生代中每次垃圾回收都要回收大部分对象，即要复制的操作比较少，但通常并不是按照 1：1 来划分新生代。一般将新生代划分为一块较大的 Eden 空间和两个较小的 Survivor 空间(From Space, To Space)，每次使用 Eden 空间和其中的一块 Survivor 空间，当进行回收时，将该两块空间中还存活的对象复制到另一块 Survivor 空间中。

2.3.2. 老年代与标记复制算法

而老年代因为每次只回收少量对象，因而采用标记整理算法( Mark-Compact) 算法。

方法区的永生代(Permanet Generation)，它用来存储 class 类，常量，方法描述等。对永生代的回收主要包括废弃常量和无用的类。

对象的内存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目

前存放对象的那一块)，少数情况会直接分配到老生代。

当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From Space 进行清理。

如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代。

在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环。

当对象在 Survivor 区躲过一次 GC 后，其年龄就会+1。默认情况下年龄到达 15 的对象会被移到老生代中。

3. JAVA 四中引用类型

java内存管理分为内存分配和内存回收，都不需要程序员负责，垃圾回收的机制主要是看对象是否有引用指向该对象。Java中提供这四种引用类型主要有两个目的：
第一是可以让程序员通过代码的方式决定某些对象的生命周期；
第二是有利于JVM进行垃圾回收。

3.1. 强引用

在 Java 中最常见的就是强引用，把一个对象赋给一个引用变量，这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它处于可达状态，它是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到 JVM 也不会回收,VM宁愿抛出OutOfMemory错误也不会回收这种对象。因此强引用是造成 Java 内存泄漏的主要原因之一。
如：

public void fun1() {  
        Object object = new Object();  
        Object[] objArr = new Object[1000];  
 }

当运行至Object[] objArr = new Object[1000];这句时，如果内存不足，JVM会抛出OOM错误也不会回收object指向的对象。不过要注意的是，当fun1运行完之后，object和objArr都已经不存在了，所以它们指向的对象都会被JVM回收。
如果想中断强引用和某个对象之间的关联，可以显示地将引用赋值为null，这样一来的话，JVM在合适的时间就会回收该对象。
比如Vector类的clear方法中就是通过将引用赋值为null来实现清理工作的

3.2. 软引用

软引用需要用 SoftReference 类来实现，对于只有软引用的对象来说，当系统内存足够时它不会被回收，当系统内存空间不足时它会被回收。软引用通常用在对内存敏感的程序中，如内存敏感的高速缓存,比如网页缓存、图片缓存等。使用软引用能防止内存泄露，增强程序的健壮性。

MyObject aRef = new  MyObject();  
SoftReference aSoftRef=new SoftReference(aRef);

对于这个MyObject对象，有两个引用路径，一个是来自SoftReference对象的软引用，一个来自变量aReference的强引用，所以这个MyObject对象是强可及对象。
随即，我们可以结束aReference对这个MyObject实例的强引用:

aRef = null;

这个MyObject对象成为了软引用对象。如果垃圾收集线程进行内存垃圾收集，并不会因为有一个SoftReference对该对象的引用而始终保留该对象。
作为一个Java对象，SoftReference对象除了具有保存软引用的特殊性之外，也具有Java对象的一般性。所以，当软可及对象被回收之后，虽然这个SoftReference对象的get()方法返回null,但这个SoftReference对象已经不再具有存在的价值，需要一个适当的清除机制，避免大量SoftReference对象带来的内存泄漏。在java.lang.ref包里还提供了ReferenceQueue。如果在创建SoftReference对象的时候，使用了一个ReferenceQueue对象作为参数提供给SoftReference的构造方法，如:

ReferenceQueue queue = new  ReferenceQueue();  
SoftReference  ref=new  SoftReference(aMyObject, queue);

那么当这个SoftReference所软引用的aMyOhject被垃圾收集器回收的同时，ref所强引用的SoftReference对象被列入ReferenceQueue。也就是说，ReferenceQueue中保存的对象是Reference对象，而且是已经失去了它所软引用的对象的Reference对象。另外从ReferenceQueue这个名字也可以看出，它是一个队列，当我们调用它的poll()方法的时候，如果这个队列中不是空队列，那么将返回队列前面的那个Reference对象。

3.3. 弱引用

弱引用需要用 WeakReference 类来实现，它比软引用的生存期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管 JVM 的内存空间是否足够，总会回收该对象占用的内存。下面是使用示例：
在java中，用java.lang.ref.WeakReference类来表示。下面是使用示例：

public class test {  
    public static void main(String[] args) {  
       WeakReference<People>reference=new WeakReference<People>(new People("zhouqian",20));  
        System.out.println(reference.get());  
       System.gc();//通知GVM回收资源  
       System.out.println(reference.get());  
  }  
}  
class People{  
   public String name;  
   public int age;  
   public People(String name,int age) {  
        this.name=name;  
        this.age=age;  
  }  
   @Override  
   public String toString() {  
       return "[name:"+name+",age:"+age+"]";  
   }  
 }

输出结果：

[name:zhouqian,age:20]
null

第二个输出结果是null，这说明只要JVM进行垃圾回收，被弱引用关联的对象必定会被回收掉。不过要注意的是，这里所说的被弱引用关联的对象是指只有弱引用与之关联，如果存在强引用同时与之关联，则进行垃圾回收时也不会回收该对象（软引用也是如此）。

3.4. 虚引用

虚引用需要 PhantomReference 类来实现，它不能单独使用，必须和引用队列联合使用。虚引用的主要作用是跟踪对象被垃圾回收的状态。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

import java.lang.ref.PhantomReference;  
import java.lang.ref.ReferenceQueue;  
public class Main {  
   public static void main(String[] args) {  
        ReferenceQueue<String> queue = new ReferenceQueue<String>();  
        PhantomReference<String> pr = new PhantomReference<String>(new String("hello"), queue);  
        System.out.println(pr.get());  
    }  
}

3.5.总结：

对于强引用，我们平时在编写代码时经常会用到。而对于其他三种类型的引用，使用得最多的就是软引用和弱引用，这2种既有相似之处又有区别。它们都是用来描述非必需对象的，但是被软引用关联的对象只有在内存不足时才会被回收，而被弱引用关联的对象在JVM进行垃圾回收时总会被回收。
在SoftReference类中，有三个方法，两个构造方法和一个get方法（WekReference类似）：

public SoftReference(T referent) {  
  super(referent);  
   this.timestamp = clock;  
   }  
public SoftReference(T referent, ReferenceQueue<? super T> q) {  
   super(referent, q);  
   this.timestamp = clock;  
  }

get方法用来获取与软引用关联的对象的引用，如果该对象被回收了，则返回null。

在使用软引用和弱引用的时候，我们可以显示地通过System.gc()来通知JVM进行垃圾回收，但是要注意的是，虽然发出了通知，JVM不一定会立刻执行，也就是说这句是无法确保此时JVM一定会进行垃圾回收的。

4. GC 分代收集算法 VS 分区收集算法

4.1. 分代收集算法

当前主流 VM 垃圾收集都采用”分代收集”(Generational Collection)算法, 这种算法会根据对象存活周期的不同将内存划分为几块, 如 JVM 中的 新生代、老年代、永久代，这样就可以根据各年代特点分别采用最适当的 GC 算法

4.1.1.在新生代-复制算法

每次垃圾收集都能发现大批对象已死, 只有少量存活. 因此选用复制算法, 只需要付出少量存活对象的复制成本就可以完成收集.

4.1.2. 在老年代-标记整理算法

因为对象存活率高、没有额外空间对它进行分配担保, 就必须采用“标记—清理”或“标记—整理”算法来进行回收, 不必进行内存复制, 且直接腾出空闲内存.

4.2. 分区收集算法

分区算法则将整个堆空间划分为连续的不同小区间, 每个小区间独立使用, 独立回收. 这样做的好处是可以控制一次回收多少个小区间 , 根据目标停顿时间, 每次合理地回收若干个小区间(而不是整个堆), 从而减少一次 GC 所产生的停顿。

5. GC 垃圾收集器介绍

Java 堆内存被划分为新生代和老年代两部分，新生代主要使用复制和标记-清除垃圾回收算法；年老代主要使用标记-整理垃圾回收算法，因此 java 虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器，JDK1.6 中 Sun HotSpot 虚拟机的垃圾收集器如下：

5.1. Serial 垃圾收集器（单线程、复制算法）

Serial（英文连续）是最基本垃圾收集器，使用复制算法，曾经是 JDK1.3.1 之前新生代唯一的垃圾收集器。Serial 是一个单线程的收集器，它不但只会使用一个 CPU 或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。

Serial 垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个 CPU 环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此 Serial 垃圾收集器依然是 java 虚拟机运行在 Client 模式下默认的新生代垃圾收集器。

5.2. ParNew 垃圾收集器（Serial+多线程）

ParNew 垃圾收集器其实是 Serial 收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和 Serial 收集器完全一样，ParNew 垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。

ParNew 收集器默认开启和 CPU 数目相同的线程数，可以通过-XX:ParallelGCThreads 参数来限制垃圾收集器的线程数。【Parallel：平行的】

ParNew 虽然是除了多线程外和 Serial 收集器几乎完全一样，但是 ParNew 垃圾收集器是很多 java 虚拟机运行在 Server 模式下新生代的默认垃圾收集器。

5.3. Parallel Scavenge 收集器（多线程复制算法、高效）

Parallel Scavenge 收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU 用于运行用户代码的时间/CPU 总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。自适应调节策略也是 ParallelScavenge 收集器与 ParNew 收集器的一个重要区别。

5.4. Serial Old 收集器（单线程标记整理算法 ）

Serial Old 是 Serial 垃圾收集器年老代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在 Client 默认的 java 虚拟机默认的年老代垃圾收集器。在 Server 模式下，主要有两个用途：

在 JDK1.5 之前版本中与新生代的 Parallel Scavenge 收集器搭配使用。

作为年老代中使用 CMS 收集器的后备垃圾收集方案。

新生代 Serial 与年老代 Serial Old 搭配垃圾收集过程图：

新生代 Parallel Scavenge 收集器与 ParNew 收集器工作原理类似，都是多线程的收集器，都使用的是复制算法，在垃圾收集过程中都需要暂停所有的工作线程。新生代 Parallel Scavenge/ParNew 与年老代 Serial Old 搭配垃圾收集过程图：

5.5. Parallel Old 收集器（多线程标记整理算法）

Parallel Old 收集器是 Parallel Scavenge 的年老代版本，使用多线程的标记-整理算法，在 JDK1.6 才开始提供。

在 JDK1.6 之前，新生代使用 Parallel Scavenge 收集器只能搭配年老代的 Serial Old 收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代 Parallel Scavenge 和年老代 Parallel Old 收集器的搭配策略。

新生代 Parallel Scavenge 和年老代 Parallel Old 收集器搭配运行过程图：

5.6. CMS 收集器（多线程标记清除算法）

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。

CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下 4 个阶段：

5.6.1. 初始标记

只是标记一下 GC Roots 能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。

5.6.2.并发标记

进行 GC Roots 跟踪的过程，和用户线程一起工作，不需要暂停工作线程。

5.6.3. 重新标记

为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。

5.6.4. 并发清除

清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看 CMS 收集器的内存回收和用户线程是一起并发地执行。

CMS 收集器工作过程：

CMS特点：并发收集，低停顿。
缺点
1.CMS收集器对CPU资源非常敏感。默认启动的回收线程数是(CPU+3)/4. 当CPU 4个以上时，并发回收垃圾收集线程不少于25%的CPU资源。
2.CMS收集器无法处理浮动垃圾(Floating Garbage), 可能出现”Concurrent Mode Failure“失败而导致另一次Full GC的产生。由于CMS并发清理时，用户线程还在运行，伴随产生新垃圾，而这一部分出现在标记之后，只能下次GC时再清理。这一部分垃圾就称为”浮动垃圾“。
由于CMS运行时还需要给用户空间继续运行，则不能等老年代几乎被填满再进行收集，需要预留一部分空间提供并发收集时，用户程序运行。JDK1.6中，CMS启动阈值为92%. 若预留内存不够用户使用，则出现一次Concurent Mode Failure失败。这时虚拟机启动后备预案，临时启用Serial Old收集老年代，这样停顿时间很长。
3.CMS基于”标记-清除“算法实现的，则会产生大量空间碎片，空间碎片过多时，没有连续空间分配给大对象，不得不提前触发一次FUll GC。当然可以开启-XX:+UseCMSCompactAtFullCollection(默认开)，在CMS顶不住要FullGC时开启内存碎片合并整理过程。内存整理过程是无法并发的，空间碎片问题没了，但停顿时间变长。

5.7. G1 收集器

Garbage first 垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与 CMS 收集器，G1 收集器两个最突出的改进是：

基于标记-整理算法，不产生内存碎片。

可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。

G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收集效率。

5.8 ZGC收集器

ZGC是在jdk11引入，属于实验性质，和G1开启很像，用下面参数即可开启：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

ZGC垃圾收集器，也称为ZGC，是一个可扩展的低延迟垃圾收集器，有如下特性：
目标

• 每次GC STW的时间不超过10ms
• 能够处理从几百M到几T的JAVA堆
• 与G1相比，吞吐量下降不超过15%
• 为未来的GC功能和优化利用有色对象指针(colored oops)和加载屏障(load barriers)奠定基础
• 初始支持Linux/x64

ZGC的特点

• 并发
• 基于Region的
• 标记整理
• NUMA感知
• 使用colored oops
• 使用load barrier

6. 垃圾回收停顿

应用运行过程中是不希望出现长时间的GC停顿的，因为这会影响服务的可用性，导致用户体验变差，甚至会严重损害一些关键的应用程序。本文将会列出可能导致GC停顿时间长的一些原因和解决方案。

6.1.对象创建的速度过高

如果应用创建对象的速度非常高，随之而来的就是GC频率也会变快，然后会导致GC的停顿时间变长。所以说，优化代码以降低对象的创建速率是降低GC停顿时间最有效的方法。这可能是一件非常耗时的事情，但是却非常值得去做。可以使用JProfiler, YourKit, JVisualVM这样的性能监控工具来帮助优化对象的创建速度
tip1:如何知道对象的创建速度？把GC日志上传到gceasy.io，这个工具会告诉你对象的创建速度，下图中‘Object Stats’里面的 ‘Avg creation rate’ 就是对象的平均创建速度。要让这个值尽可能的小。

6.2.Young区过小

如果Young过小，对象就会过早的晋升到Old区，Old区的垃圾回收一般比Young区会花费更多的时间，因此，可以通过增大Young区来有效的降低长时间GC停顿。可以用下面两个JVM参数来设置Young区的大小：
-Xmn: 设置Young区所占的字节数
-XX:NewRatio: 设置Old区和Young区的比例，比如说，-XX:NewRatio=3也就是说Old区和Young区的比例是3:1，Young区占整个堆的1/4，如果堆是2G，那么Young区就是0.5G。

6.3.选择合适的GC算法

GC算法是影响GC停顿时间的一个非常重要的因素，除非你是个GC方面的专家或者你的团队中有这方面的专家可以调优GC的设置达到最优的停顿时间，否则我建议选择使用G1收集器，因为G1是自动调优的，你只需要设置一个停顿时间的目标就可以了，比如： -XX:MaxGCPauseMillis=200。这个例子设置了最大停顿时间的目标是200ms，JVM会尽最大努力来满足这个目标。如果你已经使用了G1但是还是出现了长时间的GC停顿，那么请继续阅读本文。

6.4.进程被交换（Swap）出内存

有时候由于系统内存不足，操作系统会把你的应用从内存中交换出去。Swap是非常耗时的，因为需要访问磁盘，相对于访问物理内存来说要慢得多的多。我认为生产环境下的应用是不应该被Swap出内存的。当发生进程Swap的时候，GC停顿时间也会变长。
下面是从stackoverflow上引用的一个脚本，它能够列出被Swap出内存的进程，要确保你的应用没有被Swap出内存。

#!/bin/bash 
# Get current swap usage for all running processes
# Erik Ljungstrom 27/05/2011
# Modified by Mikko Rantalainen 2012-08-09
# Pipe the output to "sort -nk3" to get sorted output
# Modified by Marc Methot 2014-09-18
# removed the need for sudo

SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
    PID=`echo $DIR | cut -d / -f 3`
    PROGNAME=`ps -p $PID -o comm --no-headers`
    for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
    do
        let SUM=$SUM+$SWAP
    done
    if (( $SUM > 0 )); then
        echo "PID=$PID swapped $SUM KB ($PROGNAME)"
    fi
    let OVERALL=$OVERALL+$SUM
    SUM=0
done
echo "Overall swap used: $OVERALL KB"

如果很不幸你的应用被Swap了，你需要：
a:给机器增加内存
b:减少机器上运行的进程数，以释放更多的内存
c:减少应用分配的内存（不推荐，可能会引起其他问题）

6.5.GC线程数过少

GC日志中的每一个GC事件都会打印user、sys、real time，比如：

[Times: user=25.56 sys=0.35, real=20.48 secs]

这几个时间的区别可以查看前面文章：GC日志中sys时间比user时间长该如何处理？GC日志中real时间比user+sys时间长该如何处理？如果GC日志中，real time并不是明显比user time小，这就说明GC线程数是不够的，这就需要增加GC线程了。假如说，user time是25秒，GC线程数是5，那么real time大概是5左右才是正常的（25/5=5）。
注意：GC线程过多会占用大量的系统CPU，从而会影响应用能使用的CPU资源，因此增加GC线程之前一定要做好测试才可以。

6.6.IO负载重

如果系统的IO负载很重（大量的文件读写）也会导致GC停顿时间过长。这些IO读写不一定是你的应用引起的，可能是机器上其他的进程导致的，但是这仍然会导致你的应用的停顿时间变长。

如果发生了这种情况，可以这么办：
a:如果是你的应用导致的，优化你的代码
b:如果是别的进程导致的，把它杀掉或者迁走
c:把你的应用迁到一个IO负载小的机器上

6.7.显式调用了System.gc()

当调用了System.gc()或者是Runtime.getRuntime().gc()以后，就会导致FullGC。FullGC的过程当中，整个JVM是暂停的（所有的应用都被暂停掉）。System.gc()可能是以下几种情况产生的：
a:应用的程序员手动调用了System.gc()
b:应用引用的三方库或者框架甚至是应用服务器可能调用了System.gc()
c:可能是由外部使用了JMX的工具触发，比如：JVisualVM。
d:如果你的应用使用了RMI，RMI会每隔一段时间调用一次System.gc()，这个时间间隔是可以设置的：

– Dsun.rmi.dgc.server.gcInterval=n
– Dsun.rmi.dgc.client.gcInterval=n

要评估一下，是否真的有必要明确调用System.gc()。如果没有必要，就不要调用。同时，你也可以通过给JVM传递‘-XX:+DisableExplicitGC‘参数来禁用掉System.gc()。
tip：如何知道是否手动调用了System.gc()?可以把GC日志上传到gceasy，如果有手动调用System.gc()，在‘GC Causes’中就会展示出来，如图：

上图说明发生了4次System.gc()调用。

6.8.堆内存过大

堆内存过大也会导致GC停顿时间过长，如果堆内存过大，那么堆中就会累计过多的垃圾，当发生FullGC要回收所有的垃圾的时候，就会花费更多的时间。如果你的JVM的堆内存有18G，可以考虑分成3个6G的JVM实例，堆内存小会降低GC的停顿时间。
注意：在应用以上任何一种策略之前，都需要做好测试，这些策略对你可能都不适用，如果使用不当可能带来负面效果。

6.9.GC任务分配不均

就算有多个GC线程，线程之间的任务分配可能也不是均衡的，这个可能有很多种原因：
a:扫描大的线性的数据结构目前是无法并行的。
b:有些GC事件只发生在单个线程上，比如CMS中的‘concurrent mode failure’。如果你碰巧使用的CMS，可以使用-XX:+CMSScavengeBeforeRemark 这个参数，它可以让多个GC线程之间任务分配的更平均。

7.0Minor GC和Full GC的区别

（A）、Minor GC
又称新生代GC，指发生在新生代的垃圾收集动作；
因为Java对象大多是朝生夕灭，所以Minor GC非常频繁，一般回收速度也比较快；
（B）、Full GC
又称Major GC或老年代GC，指发生在老年代的GC；
出现Full GC经常会伴随至少一次的Minor GC（不是绝对，Parallel Sacvenge收集器就可以选择设置Major GC策略）；
Major GC速度一般比Minor GC慢10倍以上；