jvmGC（垃圾回收）机制

垃圾回收过程

JVM 采用一种分代回收 (generational collection) 的策略，用较高的频率对年轻的对象进行扫描和回收，这种叫做minor collection ，而对老对象的检查回收频率要低很多，称为 major collection。这样就不需要每次 GC 都将内存中所有对象都检查一遍。

新生代被划分为三部分，Eden 区和两个大小严格相同的 Survivor 区，其中 Survivor 区间，某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用，在 Young 区间变满的时候，minor GC 就会将存活的对象移到空闲的 Survivor 区间中，根据 JVM 的策略，在经过几次垃圾收集后，仍然存活于 Survivor 的对象将被移动到老年代。

老年代主要保存生命周期长的对象，一般是一些老的对象，当一些对象在 Young 复制转移一定的次数以后，对象就会被转移到老年区，一般如果系统中用了 application 级别的缓存，缓存中的对象往往会被转移到这一区间。

Minor collection 的过程就是将 eden 和在用survivor space中的活对象 copy 到空闲survivor space中。所谓 survivor，也就是大部分对象在 eden 出生后，根本活不过一次 GC。对象在新生代里经历了一定次数的 minor collection 后，年纪大了，就会被移到老年代中，称为 tenuring。

剩余内存空间不足会触发 GC，如 eden 空间不够了就要进行 minor collection，老年代空间不够要进行 major collection，永久代(Permanent Space)空间不足会引发full GC。

举例：当一个 URL 被访问时，内存申请过程如下：

A. JVM 会试图为相关 Java 对象在 Eden 中初始化一块内存区域

B. 当 Eden 空间足够时，内存申请结束。否则到下一步

C. JVM 试图释放在 Eden 中所有不活跃的对象，释放后若 Eden 空间仍然不足以放入新对象，则试图将部分 Eden 中活跃对象放入 Survivor 区

D. Survivor 区被用来作为 Eden 及 Old 的中间交换区域，当 Old 区空间足够时，Survivor 区的对象会被移到 Old 区，否则会被保留在 Survivor区

E. 当 Old 区空间不够时，JVM 会在 Old 区进行完全的垃圾收集

F. 完全垃圾收集后，若 Survivor 及 Old 区仍然无法存放从 Eden 复制过来的部分对象，导致 JVM 无法在 Eden 区为新对象创建内存区域，则出现out of memory 错误

HotSpot jvm 都给我们提供了下面参数来对内存进行配置：

配置总内存

-Xms ：指定了 JVM 初始启动以后初始化内存

-Xmx：指定 JVM 堆得最大内存，在JVM启动以后，会分配 -Xmx 参数指定大小的内存给 JVM，但是不一定全部使用，JVM 会根据 -Xms 参数来调节真正用于JVM的内存，-Xmx-Xms 之差就是三个 Virtual 空间的大小

配置新生代

-Xmn: 参数设置了年轻代的大小

-XX:SurvivorRatio: 表示 eden 和一个 surivivor 的比例，缺省值为8

-XX:NewSize 和 -XX:MaxNewSize：直接指定了年轻代的缺省大小和最大大小

配置老年代

-XX:NewRatio: 表示年老年代和新生代内存的比例，缺省值为2

配置持久代

-XX:MaxPermSize：表示持久代的最大值

-XX:PermSize：设置最小分配空间

配置虚拟机栈

-Xss：参数来设置栈的大小，默认值为128 kb。栈的大小直接决定了函数调用的深度

常见的垃圾收集策略

垃圾收集提供了内存管理的机制，使得应用程序不需要在关注内存如何释放，内存用完后，垃圾收集会进行收集，这样就减轻了因为人为的管理内存而造成的 错误，比如在 C++ 语言里，出现内存泄露时很常见的。Java 语言是目前使用最多的依赖于垃圾收集器的语言，但是垃圾收集器策略从20世纪60年代就已经流行起来了，比如 Smalltalk,Eiffel 等编程语言也集成了垃圾收集器的机制。

所有的垃圾收集算法都面临同一个问题，那就是找出应用程序不可到达的内存块，将其释放，这里面得不可到达主要是指应用程序已经没有内存块的引用了， 而在 JAVA中，某个对象对应用程序是可到达的是指：这个对象被根（根主要是指类的静态变量，常量或者活跃在所有线程栈的对象的引用）引用或者对象被另一个可 到达的对象引用。

下面我们介绍一下几种常见的垃圾收集策略：

Reference Counting(引用计数）

引用计数是最简单直接的一种方式，这种方式在每一个对象中增加一个引用的计数，这个计数代表当前程序有多少个引用引用了此对象，如果此对象的引用计数变为0，那么此对象就可以作为垃圾收集器的目标对象来收集。

优点：简单，直接，不需要暂停整个应用

缺点：需要编译器的配合，编译器要生成特殊的指令来进行引用计数的操作，比如每次将对象赋值给新的引用，或者者对象的引用超出了作用域等。
不能处理两个对象之间循环引用的问题

跟踪收集器

跟踪收集器首先要暂停整个应用程序，然后开始从根对象扫描整个堆，判断扫描的对象是否有对象引用。

如果每次扫描整个堆，那么势必让 GC 的时间变长，从而影响了应用本身的执行。因此在 JVM 里面采用了分代收集，在新生代收集的时候 minor gc 只需要扫描新生代，而不需要扫描老生代。minor gc 怎么判断是否有老生代的对象引用了新生代的对象，JVM 采用了卡片标记的策略，卡片标记将老生代分成了一块一块的，划分以后的每一个块就叫做一个卡片，JVM 采用卡表维护了每一个块的状态，当 JAVA 程序运行的时候，如果发现老生代对象引用或者释放了新生代对象的引用，那么就 JVM 就将卡表的状态设置为脏状态，这样每次 minor gc 的时候就会只扫描被标记为脏状态的卡片，而不需要扫描整个堆。

上面说了 Jvm 需要判断对象是否有引用存在，而 Java 中的引用又分为了如下几种，不同种类的引用对垃圾收集有不同的影响，下面我们分开描述一下：

1）Strong Reference(强引用)

强引用是 JAVA 中默认采用的一种方式，我们平时创建的引用都属于强引用。如果一个对象没有强引用，那么对象就会被回收。

public void testStrongReference(){
    Object referent = new Object();
    Object strongReference = referent;
    referent = null;
    System.gc();
    assertNotNull(strongReference);
}

2）Soft Reference(软引用)

软引用的对象在 GC 的时候不会被回收，只有当内存不够用的时候才会真正的回收，因此软引用适合缓存的场合，这样使得缓存中的对象可以尽量的再内存中待长久一点。

Public void testSoftReference(){
    String  str =  "test";
    SoftReference<String> softreference = new SoftReference<String>(str);
    str=null;
    System.gc();
    assertNotNull(softreference.get());
}

3）Weak Reference(弱引用)

弱引用有利于对象更快的被回收，假如一个对象没有强引用只有弱引用，那么在 GC 后，这个对象肯定会被回收。

Public void testWeakReference(){
    String  str =  "test";
    WeakReference<String> weakReference = new WeakReference<String>(str);
    str=null;
    System.gc();
    assertNull(weakReference.get());
}

4）Phantom reference(幽灵引用)

幽灵引用说是引用，但是你不能通过幽灵引用来获取对象实例，它主要目的是为了当设置了幽灵引用的对象在被回收的时候可以收到通知。

跟踪收集器常见的有如下几种：

Mark-Sweep Collector(标记-清除收集器）

标记清除收集器最早由Lisp的发明人于1960年提出，标记清除收集器停止所有的工作，从根扫描每个活跃的对象，然后标记扫描过的对象，标记完成以后，清除那些没有被标记的对象。

优点：

解决循环引用的问题

不需要编译器的配合，从而就不执行额外的指令

缺点：

每个活跃的对象都要进行扫描，收集暂停的时间比较长。

Copying Collector(复制收集器）

复制收集器将内存分为两块一样大小空间，某一个时刻，只有一个空间处于活跃的状态，当活跃的空间满的时候，GC就会将活跃的对象复制到未使用的空间中去，原来不活跃的空间就变为了活跃的空间。

优点：

只扫描可以到达的对象，不需要扫描所有的对象，从而减少了应用暂停的时间

缺点：

需要额外的空间消耗，某一个时刻，总是有一块内存处于未使用状态

复制对象需要一定的开销

Mark-Compact Collector(标记-整理收集器）

标记整理收集器汲取了标记清除和复制收集器的优点，它分两个阶段执行，在第一个阶段，首先扫描所有活跃的对象，并标记所有活跃的对象，第二个阶段首先清除未标记的对象，然后将活跃的的对象复制到堆得底部。

Mark-compact 策略极大的减少了内存碎片，并且不需要像 Copy Collector 一样需要两倍的空间。

HotSpot JVM 垃圾收集策略

GC 的执行时要耗费一定的 CPU 资源和时间的，因此在 JDK1.2 以后，JVM 引入了分代收集的策略，其中对新生代采用 ”Mark-Compact” 策略，而对老生代采用了 “Mark-Sweep” 的策略。其中新生代的垃圾收集器命名为 “minor gc”，老生代的 GC 命名为 ”Full Gc 或者Major GC”。其中用System.gc() 强制执行的是 Full GC。

HotSpot JVM 的垃圾收集器按照并发性可以分为如下三种类型：

串行收集器（Serial Collector）

Serial Collector 是指任何时刻都只有一个线程进行垃圾收集，这种策略有一个名字 stop the whole world，它需要停止整个应用的执行。这种类型的收集器适合于单CPU的机器。

Serial Collector 有如下两个：

1）Serial Copying Collector

此种 GC 用 -XX:UseSerialGC 选项配置，它只用于新生代对象的收集。

JDK 1.5.0 以后 -XX:MaxTenuringThreshold 用来设置对象复制的次数。当 eden 空间不够的时候，GC 会将 eden 的活跃对象和一个名叫 From survivor 空间中尚不够资格放入 Old 代的对象复制到另外一个名字叫 To Survivor 的空间。而此参数就是用来说明到底 From survivor 中的哪些对象不够资格，假如这个参数设置为31，那么也就是说只有对象复制31次以后才算是有资格的对象。

这里需要注意几个个问题：

From Survivor 和 To survivor的角色是不断的变化的，同一时间只有一块空间处于使用状态，这个空间就叫做 From Survivor 区，当复制一次后角色就发生了变化。

如果复制的过程中发现 To survivor 空间已经满了，那么就直接复制到 old generation。

比较大的对象也会直接复制到Old generation，在开发中，我们应该尽量避免这种情况的发生。

2）Serial Mark-Compact Collector

串行的标记-整理收集器是 JDK5 update6 之前默认的老生代的垃圾收集器，此收集使得内存碎片最少化，但是它需要暂停的时间比较长

并行收集器（Parallel Collector）

Parallel Collector 主要是为了应对多 CPU，大数据量的环境。Parallel Collector又可以分为以下三种：

1）Parallel Copying Collector

此种 GC 用 -XX:UseParNewGC 参数配置，它主要用于新生代的收集，此 GC 可以配合CMS一起使用，适用于1.4.1以后。

2）Parallel Mark-Compact Collector

此种 GC 用 -XX:UseParallelOldGC 参数配置，此 GC 主要用于老生代对象的收集。适用于1.6.0以后。

3）Parallel scavenging Collector

此种 GC 用 -XX:UseParallelGC 参数配置，它是对新生代对象的垃圾收集器，但是它不能和CMS配合使用，它适合于比较大新生代的情况，此收集器起始于 jdk 1.4.0。它比较适合于对吞吐量高于暂停时间的场合。

并发收集器 (Concurrent Collector)

Concurrent Collector 通过并行的方式进行垃圾收集，这样就减少了垃圾收集器收集一次的时间，在 HotSpot JVM 中，我们称之为 CMS GC，这种 GC 在实时性要求高于吞吐量的时候比较有用。此种 GC 可以用参数 -XX:UseConcMarkSweepGC 配置，此 GC 主要用于老生代和 Perm 代的收集。

CMS GC有可能出现并发模型失败：

CMS GC 在运行的时候，用户线程也在运行，当 GC 的速度比新增对象的速度慢的时候，或者说当正在 GC 的时候，老年代的空间不能满足用户线程内存分配的需求的时候，就会出现并发模型失败，出现并发模型失败的时候，JVM 会触发一次stop-the-world 的 Full GC 这将导致暂停时间过长。不过 CMS GC 提供了一个参数-XX:CMSInitiatingOccupancyFraction 来指定当老年代的空间超过某个值的时候即触发 GC，因此如果此参数设置的过高，可能会导致更多的并发模型失败。

并发和并行收集器区别：

并发收集器是指垃圾收集器线程和应用线程可以并发的执行，也就是清除的时候不需要 stop the world，但是并行收集器指的的是可以多个线程并行的进行垃圾收集，并行收集器还是要暂停应用的

HotSpot Jvm 垃圾收集器的配置策略

下面我们分两种情况来分别描述一下不同情况下的垃圾收集配置策略。

吞吐量优先

吞吐量是指 GC 的时间与运行总时间的比值，比如系统运行了100 分钟，而 GC 占用了一分钟，那么吞吐量就是 99%，吞吐量优先一般运用于对响应性要求不高的场合，比如 web 应用，因为网络传输本来就有延迟的问题，GC 造成的短暂的暂停使得用户以为是网络阻塞所致。

吞吐量优先可以通过 -XX:GCTimeRatio 来指定。当通过 -XX:GCTimeRatio 不能满足系统的要求以后，我们可以更加细致的来对 JVM 进行调优。

首先因为要求高吞吐量，这样就需要一个较大的 Young generation，此时就需要引入 Parallel scavenging Collector ，可以通过参数：-XX:UseParallelGC来配置。

java -server -Xms3072m -Xmx3072m -XX:NewSize=2560m -XX:MaxNewSize=2560 -XX:SurvivorRatio=2 -XX:+UseParallelGC

当年轻代使用了 Parallel scavenge collector 后，老生代就不能使用CMS GC 了，在 JDK1.6 之前，此时老生代只能采用串行收集，而 JDK1.6 引入了并行版本的老生代收集器，可以用参数-XX:UseParallelOldGC 来配置。

1.控制并行的线程数

缺省情况下，Parallel scavenging Collector 会开启与 cpu 数量相同的线程进行并行的收集，但是也可以调节并行的线程数。假如你想用4个并行的线程去收集 Young generation 的话，那么就可以配置-XX:ParallelGCThreads=4，此时JVM的配置参数如下：

java -server -Xms3072m -Xmx3072m -XX:NewSize=2560m -XX:MaxNewSize=2560 -XX:SurvivorRatio=2 -XX:+UseParallelGC -XX:ParallelGCThreads=4

2.自动调节新生代

在采用了 Parallel scavenge collector 后，此 GC 会根据运行时的情况自动调节 survivor ratio 来使得性能最优，因此Parallel scavenge collector 应该总是开启 -XX:+UseAdaptiveSizePolicy 参数。此时JVM的参数配置如下：

java -server -Xms3072m -Xmx3072m -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy

响应时间优先

响应时间优先是指 GC 每次运行的时间不能太久，这种情况一般使用与对及时性要求很高的系统，比如股票系统等。

响应时间优先可以通过参数 -XX:MaxGCPauseMillis来配置，配置以后 JVM 将会自动调节年轻代，老生代的内存分配来满足参数设置。

在一般情况下，JVM 的默认配置就可以满足要求，只有默认配置不能满足系统的要求时候，才会根据具体的情况来对 JVM 进行性能调优。如果采用默认的配置不能满足系统的要求，那么此时就可以自己动手来调节。此时 Young generation 可以采用Parallel copying collector，而 Old generation 则可以采用Concurrent Collector。

举个例子来说，以下参数设置了新生代用 Parallel Copying Collector，老生代采用 CMS 收集器。

java -server -Xms512m -Xmx512m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

此时需要注意两个问题：

1.如果没有指定 -XX:+UseParNewGC，则采用默认的非并行版本的 copy collector

2.如果在一个单 CPU 的系统上设置了 -XX:+UseParNewGC，则默认还是采用缺省的copy collector

1.控制并行的线程数

默认情况下，Parallel copy collector 启动和 CPU 数量一样的线程，也可以通过参数 -XX:ParallelGCThreads 来指定，比如你想用 4 个线程去进行并发的复制收集，那么可以改变上述参数如下：

java -server -Xms512m -Xmx512m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=2 -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

2.控制并发收集的临界值

默认情况下，CMS GC在 old generation 空间占用率高于 68% 的时候，就会进行垃圾收集，而如果想控制收集的临界值，可以通过参数：-XX:CMSInitiatingOccupancyFraction 来控制，比如改变上述的JVM配置如下：

java -server -Xms512m -Xmx512m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=2 -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=35

此外顺便说一个参数：-XX:+PrintCommandLineFlags 通过此参数可以知道在没有显示指定内存配置和垃圾收集算法的情况下，JVM 采用的默认配置。

比如我在自己的机器上面通过如下命令 java -XX:+PrintCommandLineFlags -version 得到的结果如下所示：

-XX:InitialHeapSize=1055308032 -XX:MaxHeapSize=16884928512 -XX:ParallelGCThreads=8 -XX:+PrintCommandLineFlags -XX:+UseCompressedOops -XX:+UseParallelGC
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
You have new mail in /var/spool/mail/root

从输出可以清楚的看到JVM通过自己检测硬件配置而给出的缺省配置。