《分布式JAVA应用 基础与实践》 第三章 3.2 JVM内存管理(三)

3.2.3  内存回收（2）

Full GC

除CMS GC外，当旧生代和持久化触发GC时，其实是对新生代、旧生代及持久代都进行GC，因此通常又称为Full GC。当Full GC被触发时，首先按照新生代所配置的GC方式对新生代进行GC（在新生代采用PS GC时，可通过-XX:-ScavengeBeforeFullGC来禁止Full GC时对新生代进行GC），然后按照旧生代的GC方式对旧生代、持久代进行GC。但其中有一种特殊现象，如在进行Minor GC前，可能Minor GC后移到旧生代的对象多于旧生代的剩余空间，这种情况下Minor GC就不会执行了，而是直接采用旧生代的GC方式来对新生代、旧生代及持久代进行回收。

除直接调用System.gc外，触发Full GC执行的情况有如下四种。

1. 旧生代空间不足

旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：

java.lang.OutOfMemoryError: Java heap space  

 

2. Permanet Generation空间满

Permanet Generation中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：

java.lang.OutOfMemoryError: PermGen space

 

为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

3. CMS GC时出现promotion failed和concurrent mode failure

对于采用CMS进行旧生代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况，当这两种状况出现时可能会触发Full GC。

promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入旧生代，而此时旧生代也放不下造成的；concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代，而此时旧生代空间不足造成的。

应对措施为：增大survivor space、旧生代空间或调低触发并发GC的比率，但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。对于这种状况，可通过设置 -XX: CMSMaxAbortablePrecleanTime=5（单位为ms）来避免。

4. 统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间

这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。

例如程序第一次触发Minor GC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，如果小于6MB，则执行Full GC。

当新生代采用PS GC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次Minor GC后，PS GC会检查此时旧生代的剩余空间是否大于6MB，如小于，则触发对旧生代的回收。

除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一次Full GC。可通过在启动时通过- java -Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

Full GC示例

以下通过几个例子来演示Full GC在旧生代占满和CMS GC失败时的触发，以及不同Full GC时的日志信息。

1. 旧生代空间不足触发的Full GC

代码如下：

public class TestFullGC{ 
   public static void main(String[] args) throws Exception{ 
       List < MemoryObject >   objects = new  ArrayList < MemoryObject > (6); 
       for(int  i = 0 ;i < 10 ;i++){ 
          objects.add(new MemoryObject(1024*1024)); 
       } 
       // 让上面的对象尽可能地转入旧生代中 
       System.gc(); 
       System.gc(); 
       Thread.sleep(2000); 
       objects.clear(); 
       for(int  i = 0 ;i < 10 ;i++){ 
          objects.add(new MemoryObject(1024*1024)); 
          if(i% 3 ==0){ 
             objects.remove(0); 
          } 
       } 
       Thread.sleep(5000); 
   } 
} 

class MemoryObject{ 
        private byte[] bytes; 
        public MemoryObject(int objectSize){ 
                 this.bytes = new  byte[objectSize]; 
        } 
} 

以-Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails执行以上代码，可看到在输出的日志中出现了Full GC的信息：

[Full GC [PSYoungGen: 7248K- > 0K(8960K)]  [PSOldGen: 9330K- > 4210K(10240K)] 16578K- > 4210K(19200K) [PSPermGen: 1692K- > 1692K(16384K)],  0.0085500 secs] [Times:  user = 0 .01  sys = 0 .00,  real = 0 .01 secs] 

上面日志的含义为执行了一次Full GC，新生代的方式为并行回收GC方式，回收前内存使用了7 248KB，回收后为0KB，可使用的内存为8 960KB；旧生代的方式为并行GC方式，回收前内存使用了9 330KB，回收后为4 210KB，可使用的内存为10 240KB；回收前JVM堆使用的内存为16 578KB，回收后为4 210KB，可使用的内存为19 200KB；PSPermGen回收前为1 692KB，回收后仍然为1 692KB，可使用的内存为16 384KB；回收Perm Gen消耗的时间为7ms，整个Full GC耗费的时间为10ms，通过System.gc调用的Full GC在日志上会显示为Full GC（System）。

由于执行以上代码的机器为server级机器，因此其默认采用的为-XX:+UseParallelGC，改为采用-XX:+UseSerialGC，Full GC的信息如下：

[Full GC [Tenured: 9216K- > 4210K(10240K),  0.0066570 secs] 16584K- > 4210K(19456K), [Perm : 1692K- > 1692K(16384K)], 0.0067070 secs] [Times:  user = 0 .00  sys = 0 .00,  real = 0 .01 secs]  

上面日志的含义为执行了一次Full GC，旧生代的回收方式采用的为串行方式，回收前为9 216KB，回收后为4 210KB，旧生代可用的内存为10 240KB，回收耗时6ms，其他信息则和ParallelGC时基本相同。

2. CMS GC失败触发的Full GC

按照CMS GC concurrent mode failure失败的原因，编写了如下代码：

public class TestCMSGC{ 
   public static void main(String[] args) throws Exception{ 
       List < MemoryObject >   objects = new  ArrayList < MemoryObject > (6); 
       for(int  i = 0 ;i < 9 ;i++){ 
          objects.add(new MemoryObject(1024*1024)); 
       } 
       Thread.sleep(2000); 
       objects.remove(0); 
       objects.remove(0); 
       objects.remove(0); 
       for(int  i = 0 ;i < 20 ;i++){ 
          objects.add(new MemoryObject(1024*1024)); 
          if(i% 2 ==0){ 
             objects.remove(0); 
          } 
       } 
       Thread.sleep(5000); 
   } 
}  

以-Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC参数执行，在输出信息中可看到类似信息：

[Full GC [CMS[CMS-concurrent-mark: 0.004/0.006 secs]  [Times:  user = 0 .00  sys = 0 .00,  real = 0 .00 secs] 
(concurrent mode failure): 9331K- > 9331K(10240K),  0.0183120 secs] 16499K- > 15475K(19456K), [CMS Perm :  1692K- > 1692K(16384K)], 0.0184020 secs] [Times:  user = 0 .02  sys = 0 .00,  real = 0 .02 secs]  

由于是并发操作的，所以日志有重叠。

3. 统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间

测试代码如下：

public static void main(String[] args) throws Exception{ 
        byte[]  bytes = new  byte[1024*1024*2]; 
        byte[]  bytes2 = new  byte[1024*1024*2]; 
        byte[]  bytes3 = new  byte[1024*1024*2]; 

        System.out.println("ready to happen one minor gc,if parallel scavenge gc,then should one full gc"); 
        byte[]  bytes4 = new  byte[1024*1024*2]; 
        Thread.sleep(3000); 
        System.out.println("minor gc end"); 
        byte[]  bytes5 = new  byte[1024*1024*2]; 
        byte[]  bytes6 = new  byte[1024*1024*2]; 
        System.out.println("minor gc again , and should direct full gc"); 
        byte[]  bytes7 = new  byte[1024*1024*2]; 
        Thread.sleep(3000); 
} 

 

以java -Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails-XX:+UseParallelGC执行以上代码，可看到在输出ready to happen one minor gc,if parallel scanvege gc,then should one full gc后，系统输出了一次minor gc和一次full gc的信息。当输出minor gc again,and should direct full gc时，系统执行了一次full gc，而观看这两次full gc的日志信息，会看到此时旧生代、perm均没有满：

[Full GC [PSYoungGen: 176K- > 0K(8960K)] [PSOldGen:  6144K- > 6258K(10240K)] 6320K- > 6258K(19200K) [PSPermGen: 1685K- > 1685K(16384K)], 0.0065500 secs] [Times:  user = 0 .00  sys = 0 .00,  real = 0 .00 secs] 
[Full GC [PSYoungGen: 6224K- > 4096K(8960K)] [PSOldGen:  6258K- > 8306K(10240K)] 12482K- > 12402K(19200K) [PSPermGen: 1692K- > 1692K(16384K)], 0.0222810  secs] [Times:  user = 0 .01  sys = 0 .01,  real = 0 .02 secs] 

结合代码以及之前介绍的触发机制，可看到在输出ready to happen one minor gc后，系统分配了一个2MB的对象，此时eden space空间不足，触发minor gc，minor gc后有6MB的对象进入了旧生代，此时旧生代剩余空间为4MB，于是执行full gc。

在输出minor gc again后，eden space空间再次不足，于是再度触发minor gc，此时minor gc发现之前统计出来的晋升到旧生代对象的平均值为6MB，并和旧生代的剩余空间进行比较，发现旧生代空间更小，于是直接执行full gc。

当将执行参数切换为java -Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails-XX:+UseSerialGC后，可看到系统先后执行了一次minor gc和一次full gc。

小结

综上所述，Sun JDK为高效实现内存的分配及内存的回收，提供了多种GC的实现，在client和server模式下的默认选择并不相同，如表3.1所示。

表3.1  client、server模式的默认GC

	新生代GC 方式	旧生代和持久代GC 方式
Client	串行 GC	串行 GC
Server	并行回收 GC	并行 GC （ JDK 5.0 Update 6 以后）

表3.2  Sun JDK GC的组合方式

	新生代GC 方式	旧生代和持久代GC 方式
-XX:+UseSerialGC	串行 GC	串行 GC
-XX:+UseParallelGC	并行回收 GC	并行 GC
-XX:+UseConcMarkSweepGC	并行 GC	并发 GC 当出现 concurrent Mode failure 时采用串行 GC
-XX:+UseParNewGC	并行 GC	串行 GC
-XX:+UseParallelOldGC	并行回收 GC	并行 GC
-XX:+UseConcMarkSweepGC -XX:-UseParNewGC	串行 GC	并发 GC 当出现 Concurrent Mode failure 或 promotion failed 时则采用串行 GC
不支持的组合方式	1. -XX:+UseParNewGC –XX:+UseParallelOldGC 2. -XX:+UseParNewGC –XX:+UseSerialGC

为了避免开发人员选择哪种GC而头疼，Sun JDK还提供了两种简单的方式来帮助选择GC。

1. 吞吐量优先

吞吐量是指GC所耗费的时间占应用运行总时间的百分比，例如应用总共运行了100分钟，其中GC执行占用了1分钟，那么吞吐量就是99%，JVM默认的指标是99%。

吞吐量优先的策略即为以吞吐量为指标，由JVM自行选择相应的GC策略及控制New Generation、Old Generation内存的大小，可通过在JVM参数中指定-XX:GCTimeRatio=n来使用此策略。

 

2. 暂停时间优先

暂停时间是指每次GC造成的应用的停顿时间，默认不启用这个策略。

暂停时间优先的策略即为以暂停时间为指标，由JVM自行选择相应的GC策略及控制New Generation、Old Generation内存的大小，来尽量保证每次GC造成的应用停顿时间都在指定的数值范围内完成，可通过在JVM参数中指定 -XX:MaxGCPauseMillis=n来使用此策略。

当以上两参数都指定的情况下，首先满足暂停时间优先策略，再满足吞吐量优先策略，这两个策略要通过收集运行信息来做动态调整，实现难度较高，目前还 很难做到精确的控制，并且动态地调整可能会给应用带来影响，以及大部分应用的需求其实是一定时间范围内吞吐量是多少或暂停时间最多是多少，这在这两种策略 中无法配置。

大多数情况下只须配置JVM堆的大小及持久代的大小就可以让GC符合应用的要求运行，对于访问量、数据量较大的应用而言，如果确定GC对应用的运行 状况造成了影响，则可根据应用状况来精确控制内存空间中每个代的大小、选择GC方式及调整GC参数，尽可能降低GC对应用运行的影响。

Garbage First

除了以上这些已有的GC外，为了能够做到控制某个时间片内GC所能占用的最大暂停时间，例如在100秒内最多允许GC导致的应用暂停时间为1秒，以 满足对响应时间有很高要求的应用，Sun JDK 6 Update 14以上版本及 JDK 7中增加了一种称为Garbage First的GC。

Garbage First简称G1，它的目标是要做到尽量减少GC所导致的应用暂停的时间，同时保持JVM堆空间的利用率。

G1要做到这样的效果，是有前提的，一方面是硬件环境的要求，必须是多核的CPU及较大的内存（从规范来看，512MB以上就满足条件了）；另一方面是要接受GC吞吐量的稍微降低，对于响应时间要求高的系统而言，这点应该是可以接受的。

G1在原有的各种GC策略上进行了吸收和改进，G1中吸收了增量收集器和CMS GC策略的优点，并在此基础上做了很多改进。

G1将整个jvm Heap划分为多个固定大小的region，扫描时采用Snapshot-at-the-beginning的并发marking算法对整个heap中的 region进行mark。回收时根据region中活跃对象的bytes进行排序，首先回收活跃对象bytes小及回收耗时短（预估出来的时间）的 region，回收的方法为将此region中的活跃对象复制到另外的region中，根据指定的GC所能占用的时间来估算能回收多少region。这点 和以前版本的Full GC时的处理整个heap非常不同，这样就做到了能够尽量短时间地暂停应用，又能回收内存，由于这种策略首先回收的是垃圾对象所占空间最多的 region，因此称为Garbage First。

G1将Heap划分为多个固定大小的region，这也是G1能够实现控制GC导致的应用暂停时间的前提。region之间的对象引用通过 remembered set来维护，每个region都有一个remembered set，remembered set中包含了引用当前region中对象的region对象的pointer，应用会造成region中对象的引用关系不断发生改变，G1采用了 Card Table来用于应用通知region修改remembered sets，Card Table由多个512字节的Card构成，这些Card在Card Table中以1个字节来标识，每个应用的线程都有一个关联的remembered set log，用于缓存和顺序化线程运行时造成的对于card的修改。另外，还有一个全局的filled RS buffers，当应用线程执行时修改了card后，如果造成的改变仅为同一region中的对象之间的关联，则不记录remembered set log；如果造成的改变为跨region中的对象的关联，则记录到线程的remembered set log；如果线程的remembered set log满了，则放入全局的filled RS buffers中，线程自身则重新创建一个新的remembered set log，remembered set本身也是一个由一堆cards构成的哈希表。

尽管G1将Heap划分为了多个region，但其默认采用的仍然是分代的方式，只是名称改为了年轻代（young）和非年轻代，这也是由于G1仍 然坚信大多数新创建的对象是不需要长的生命周期的。对于应用新创建的对象，G1将其放入标识为young的region中，这些region并不记录 remembered set logs，扫描时只扫描活跃的对象。

G1在分代的方式上还可更细地划分为：fully young或partially young。fully young方式暂停的时候仅处理young regions，partially同样处理所有的young regions，但它还会根据允许的GC的暂停时间来决定是否要加入其他的非young regions。G1是采用fully-young方式还是partially young方式，外部是不能决定的。启动时，G1采用的为fully-young方式，当G1完成一次Concurrent Marking后，则切换为partially young方式，随后G1跟踪每次回收的效率，如果回收fully-young中的regions已经可以满足内存需要，就切换回fully young方式。但当heap size的大小接近满的情况下，G1会切换到partially young方式，以保证能提供足够的内存空间给应用使用。

除了分代方式的划分外，G1还支持另外一种pure G1的方式，也就是不进行代的划分，pure方式和分代方式的具体不同在以下具体执行步骤中进行描述。

下面介绍G1的具体执行步骤。

1．Initial Marking

G1对于每个region都保存了两个标识用的bitmap，一个为previous marking bitmap，一个为next marking bitmap，bitmap中包含了一个bit的地址信息来指向对象的起始点。

开始Initial Marking之前，首先并发清空next marking bitmap，然后停止所有应用线程，并扫描标识出每个region中root可直接访问到的对象，将region中top的值放入next top at mark start（TAMS）中，之后恢复所有应用线程。

触发该步骤执行的条件为：

G1定义了一个JVM Heap大小的百分比的阈值，称为h，另外还有一个H值为(1-h)*Heap Size。目前该h的值是固定的，后续G1也许会将其改为根据jvm的运行情况来动态地调整。在分代方式下，G1还定义了一个u及soft limit，soft limit的值为H-u*Heap Size，当Heap中使用的内存超过soft limit值时，就会在一次clean up执行完毕后在应用允许的GC暂停时间范围内尽快执行该步骤；

在pure方式下，G1将marking与clean up组成一个环，以便clean up能充分使用marking的信息。当clean up开始回收时，首先回收能够带来最多内存空间的regions；当经过多次的clean up，回收到没多少空间的regions时，G1重新初始化一个新的marking与clean up构成的环。

2．Concurrent Marking

按照之前Initial Marking扫描到的对象进行遍历，以识别这些对象的下层对象的活跃状态，对于在此期间应用线程并发修改的对象的关系则记录到remembered set logs中，新创建的对象则放入比top值更高的地址区间中。这些新创建的对象默认状态即为活跃的，同时修改top值。

3．Final Marking Pause

当应用线程的remembered set logs未满时，是不会放入filled RS buffers中的，这些remebered set logs中记录的card修改就不会被更新了，因此需要这一步把应用线程中存在的remembered set logs的内容进行处理，并相应修改remembered sets，此步需要暂停应用，并行运行。

4．Live Data Counting and Cleanup

值得注意的是，在G1中，并不是说Final Marking Pause执行完了，就肯定执行Cleanup。由于这步需要暂停应用，G1为了能够达到实时的要求，需要根据用户指定的最大的GC造成的暂停时间来合理 规划什么时候执行Cleanup，另外还有几种情况也会触发这个步骤的执行：

G1采用复制方法来进行收集，必须保证每次的"to space"的空间都是够的，因此G1采取的策略是当已经使用的内存空间达到H时，就执行Cleanup这个步骤；

对于full-young和partially-young的分代模式的G1而言，还有其他情况会触发Cleanup的执行。full-young 模式下，G1根据应用可接受的暂停时间、回收young regions需要消耗的时间来估算出一个yound regions的数量值，当JVM中分配对象的young regions的数量达到此值时，Cleanup就会执行；partially-young模式下，则会尽量频繁的在应用可接受的暂停时间范围内执行 Cleanup，并最大限度地去执行non-young regions的Cleanup。

这一步中GC线程并行扫描所有region，计算每个region中低于next TAMS值中marked data的大小，然后根据应用所期望的GC的短延时及G1对于region回收所需的耗时的预估，排序region，将其中活跃的对象复制到其他region中。

从以上G1的步骤可看出，G1和CMS GC非常类似，只是G1将JVM划分为了更小粒度的regions，并在回收时进行了估算。回收能够带来最大内存空间的regions，从而缩短了每次回收所须消耗的时间。

一个简单的演示G1的例子，代码如下：

public class TestG1{ 
    public static void main(String[] args) throws Exception{ 
        List < MemoryObject >   objects = new  ArrayList < MemoryObject > (); 
        for(int  i = 0 ;i < 20 ;i++){ 
           objects.add(new MemoryObject(1024*1024)); 
           if(i% 3 ==0){ 
               objects.remove(0); 
           } 
        } 
        Thread.sleep(2000); 
    } 
} 

在Sun JDK 1.6.0 Update 18上，以-Xms40M -Xmx40M -Xmn20M -verbose:gc -XX:+Unlock- ExperimentalVMOptions -XX:+UseG1GC -XX:MaxGCPauseMillis=5 -XX:GCPauseIntervalMillis=1000 -XX:+PrintGCDetails执行以上代码，在输出信息中可看到类似如下的信息：

[GC pause (young), 0.00328600 secs] 
   [Parallel Time:   3.1 ms] 
      [Update RS (Start) (ms):  142.8  143.9  143.1  142.6  142.9  143.9] 
      [Update RS (ms):  0.2  0.0  0.0  0.0  0.0  0.0 
       Avg:   0.0, Min:   0.0, Max:   0.2] 
         [Processed Buffers : 5 0 0 0 0 0 
          Sum: 5, Avg: 0, Min: 0, Max: 5] 
      [Ext Root Scanning (ms):  1.4  2.3  1.0  0.0  0.0  0.0 
       Avg:   0.8, Min:   0.0, Max:   2.3] 
      [Mark Stack Scanning (ms):  0.0  0.0  0.0  0.0  0.0  0.0 
       Avg:   0.0, Min:   0.0, Max:   0.0] 
      [Scan-Only Scanning (ms):  0.0  0.0  0.0  0.0  0.0  0.0 
       Avg:   0.0, Min:   0.0, Max:   0.0] 
         [Scan-Only Regions : 0 0 0 0 0 0 
          Sum: 0, Avg: 0, Min: 0, Max: 0] 
      [Scan RS (ms):  0.0  0.0  0.0  0.0  0.0  0.0 
       Avg:   0.0, Min:   0.0, Max:   0.0] 
      [Object Copy (ms):  0.7  0.0  0.9  1.0  1.2  0.0 
       Avg:   0.6, Min:   0.0, Max:   1.2] 
      [Termination (ms):  0.5  0.2  0.4  0.5  0.0  0.2 
       Avg:   0.3, Min:   0.0, Max:   0.5] 
      [Other:   1.2 ms] 
   [Clear CT:   0.1 ms] 
   [Other:   0.1 ms] 
   [ 199K- > 132K(40M)] 
 [Times:  user = 0 .01  sys = 0 .00,  real = 0 .01 secs] 

 

Real-Time JDK

为了满足实时领域系统使用Java的需求，Java推出了Real-Time版的规范（JSR-001，更新的版本为JSR-282），各大厂商均 积极响应，相应推出了Real-Time实现的JDK。Real-Time版的JDK对Java做出了很多的改进，例如强大的线程调度机制、异步的事件处 理机制、更为精准的时间刻度等，在此最为关心的是其在Java内存管理方面的加强。

GC无疑是Java进入实时领域的一个很大障碍，毕竟无论GC怎么改进，它肯定会造成应用暂停的现象，而且会在运行时突然造成暂停。这对于实时系统来说是不可接受的，因此Real-Time版的JDK在此方面做了多方面的改进。

1. 新的内存管理机制

提供了两种内存区域：Immortal内存区域和Scoped内存区域。

Immortal内存区域用于保留永久的对象，这些对象仅在应用结束运行时才会释放内存，这对于支持需要缓存的系统而言非常重要。

Scoped内存区域用于保留临时的对象，位于scope中的对象在scope退出时，这些对象所占用的内存会被直接回收，有点类似于栈上分配。

Immortal内存区域和Scoped内存区域均不受GC管理，因此基于这两个内存区域来编写的应用完全不用担心GC会造成暂停的现象。

2. 允许Java应用直接访问物理内存

在保证安全的情况下，Real-Time JDK允许Java应用直接访问物理内存，而非像以前的Java程序，需要通过native code才能访问。能够访问物理内存，也就意味着可以直接将对象放入物理内存，而非JVM heap中。