JVM学习笔记之GC

研究了一段时间的JVM，主要参考了《深入java虚拟机》和《java虚拟机规范》，决定写点东西总结一下。 

 

    先说说GC回收。 

 

    首先，垃圾回收由JVM的一个幽灵线程实现，它是不连续运行，就是说有间隔，并且优先级很低，人工基本上不直接干涉的。 

    其次，垃圾回收的作用是回收不使用的对象，释放并整理内存空间。 

    这里先总结下类的加载过程。 

    JVM会加载一个CLASS（装载），通过安全校验和分配（连接）过程后，会在虚拟机的内存中分配一个空间，来生成（初始化）这个类的实例。自然，程序里每 new一个实例的时候，JVM就会给这个实例分配一块内存空间。 

    C/C++中有专门的析构函数来释放占用的空间，java就由GC来处理，但是GC的作用不仅仅是回收空间，还有整理的作用。JVM中的空闲空间是连续的，每new出的实例的空间也是连续的，当程序运行一段时间后（有的实例已经不用，被释放，有的还在使用），原本连续的空闲空间，变得断断续续，如果空闲空间一直这么破碎，那么整体效率就大打折扣（原因有很多，比如new一个大型的实例时，JVM就不得不找足够大的零碎空间），原来看了很多对GC的说明，其中对“整理”这块一直没强调，其实这个也是很重要的地方。 

    回头继续说GC的回收吧，回收有很多的算法，这些算法可以简单分两步，发现 并 回收+整理。 

    JDK最早的时候用的是引用计数算法收集，堆中的每个对象都有一个引用计数器，当这个对象的指引被分配给别的变量时，计数+1，当这个对象的引用超过生命周期（这个周期是JDK默认的时间间隔）或者别设定了新值时，计数-1，当技术为0时，认定为垃圾回收对象，当这个对象被回收时，它引用的任何其他对象的计数也-1，这种“发现”的机制是速度快，但是缺点是会有内存泄漏，比如，A和B相互引用的时候，计数永远不会为0。此外，这种早期的垃圾回收机制已查不到怎么整理内存空间的资料了。 

    计数收集算法现在已经不在使用，除此以外还有“跟踪收集”和“压缩收集”等。现行的收集算法有很多，大都基于“拷贝收集”发展开来（这里可能有很多人不赞同，先往下看再拍砖吧）。 

    先说下我对和“拷贝收集”的理解， 

    拷贝收集：首先，JVM划分出至少2个空间，这里称呼A和B，首先使用A空间，GC收集的时候（一般是A空间满了），会把A空间中“活动”对象拷贝到B空间（怎么判断是否活动，由各个厂商的JDK实现，最简单的比如从根节点开始对对象的追踪，在追踪的过程中遇到对象就“标记”为“活动”），在拷贝的过程中，活动对象是紧挨着布置的，可以消除空隙；其次，原有的实例在A空间中占有的位置被认为是空闲的，在这个位置增加了转向指针指向B空间的相应位置；最后，在释放A空间的时候，没有转向指针的空间被直接释放，有转向指针的，则把相应的指引指向转向指针对应在B空间的位置。拷贝收集的缺点很明显，内存应用效率很差，只能用其中的一半，还有每次回收的时候消耗的资源很大，不过优点也很明显，速度快。 

 

    先行的收集算法都由拷贝收集为基础，结合了实例对象生命周期的分析发展而来， 

    1、大多数程序创建的大部分对象都具有很短的生命周期。 

    2、大多数程序都会创建一小部分生命周期长的对象。 

    3、一次只回收内存的一部分（我补充的，按代收集都不会一次性处理整个内存空间）。 

    具体的生命周期短和周期长的对象比例为9：1（IBM） 或者 8：1（Sun）。 

    首先说说火车算法，（我没搞清楚生命周期的长短的实例数量的比例对回收效率的影响） 

    Sun的虚拟机把JVM中应用对象按代分，年轻的那部分回收的很快，而成熟对象空间则采用火车算法处理。 

    火车算法把成熟空间划分成2维队列，仅仅是成熟对象，不包括新生代。 

    火车算法最大的好处是它可以保证大的循环结构可以被完全收集，因为成为垃圾的循环结构中的对象，无论多大，都会被移入同一列火车，最终一起被收集。还有一个好处是这种算法在大多数情况下可以保证一次垃圾收集所耗时间在一定限度之内，因为一次垃圾回收只收集一个车厢，而车厢的大小是有限度的。 

    我对火车算法的理解是“迭代的跟踪回收+整理”，具体的回收过程可见：http://blog.csdn.net/zouxinfox/archive/2007/05/01/1594216.aspx， 

    刚刚说的火车算法是专门处理成熟代的，那么新生代的处理显然不同，新生代的处理方法是：将内存分为一块较大的eden空间和2块较少的survivor空间，每次使用eden和其中一块survivor，当回收时将eden和survivor还存活的对象一次过拷贝到另外一块survivor空间上，然后清理掉eden和用过的survivor。当然，98%的对象可回收只是一般场景下的数据，任何人都没有办法保证每次回收都只有10%以内的对象存活，当survivor空间不够用时，需要依赖其他内存（譬如老年代）进行分配担保（Handle Promotion）。 

 

  垃圾搜集器有6种，具体使用哪种得看实际情况： 

1.Serial收集器 

　　单线程收集器，收集时会暂停所有工作线程（我们将这件事情称之为Stop The World，下称STW），使用复制收集算法，虚拟机运行在Client模式时的默认新生代收集器。 

 

2.ParNew收集器 

　　ParNew收集器就是Serial的多线程版本，除了使用多条收集线程外，其余行为包括算法、STW、对象分配规则、回收策略等都与Serial收集器一摸一样。对应的这种收集器是虚拟机运行在Server模式的默认新生代收集器，在单CPU的环境中，ParNew收集器并不会比Serial收集器有更好的效果。 

 

3.Parallel Scavenge收集器 

　　Parallel Scavenge收集器（下称PS收集器）也是一个多线程收集器，也是使用复制算法，但它的对象分配规则与回收策略都与ParNew收集器有所不同，它是以吞吐量最大化（即GC时间占总运行时间最小）为目标的收集器实现，它允许较长时间的STW换取总吞吐量最大化。 

 

4.Serial Old收集器 

　　Serial Old是单线程收集器，使用标记－整理算法，是老年代的收集器，上面三种都是使用在新生代收集器。 

 

5.Parallel Old收集器 

　　老年代版本吞吐量优先收集器，使用多线程和标记－整理算法，JVM 1.6提供，在此之前，新生代使用了PS收集器的话，老年代除Serial Old外别无选择，因为PS无法与CMS收集器配合工作。 

 

6.CMS（Concurrent Mark Sweep）收集器 

　　CMS是一种以最短停顿时间为目标的收集器，使用CMS并不能达到GC效率最高（总体GC时间最小），但它能尽可能降低GC时服务的停顿时间，这一点对于实时或者高交互性应用（譬如证券交易）来说至关重要，这类应用对于长时间STW一般是不可容忍的。CMS收集器使用的是标记－清除算法，也就是说它在运行期间会产生空间碎片，所以虚拟机提供了参数开启CMS收集结束后再进行一次内存压缩。 

 

    GC基本上就这么多了，有错欢迎拍砖！ 

评论

2 楼 wupuyuan 2011-11-15  

具体

chenjingbo 写道

sun的jdk没有使用过引用计数吧.

这篇东西我总感觉好像写的太泛..写的有点着急的感觉.比如这段

引用

1.Serial收集器

　　单线程收集器，收集时会暂停所有工作线程（我们将这件事情称之为Stop The World，下称STW），使用复制收集算法，虚拟机运行在Client模式时的默认新生代收集器。

分代收集中,应该所有的年轻代收集都是复制收集吧.

呵呵，以前写的了，只是辅助理解，实际应用中基本用不到。在JDK1.0，1.1的时候好像还是计数搜集的，另外JVM规范也提到了，虚拟机可以采用任何形式的垃圾回收机制，自己写的也可以试试^_^

1 楼 chenjingbo 2011-11-14  

sun的jdk没有使用过引用计数吧.

这篇东西我总感觉好像写的太泛..写的有点着急的感觉.比如这段

引用

1.Serial收集器

　　单线程收集器，收集时会暂停所有工作线程（我们将这件事情称之为Stop The World，下称STW），使用复制收集算法，虚拟机运行在Client模式时的默认新生代收集器。

分代收集中,应该所有的年轻代收集都是复制收集吧.