垃圾收集器与内存分配策略

常见垃圾收集算法：

 

1. 引用计数算法。有一个引用，加1，减少一个引用减1，当计数器为0时标记为可回收。JAVA不使用这种技术，微软的COM,ActionScript3的Flashplayer, python以及游戏脚本领域广泛使用的Squirrel都是用这种方式。
   无法解决循环引用问题。
2. 根搜索算法。JAVA和C#都是用这种算法。基本思路是，通过一系列名为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时（不可达），则标记为可回收。
   
   可作为GC Roots的对象包括下面几种：
   虚拟机栈（栈帧中的本地变量表）中的引用对象
   方法区中的类静态属性引用的对象。
   方法区中的常量引用的对象
   本地方法栈中JNI(JAVA NATIVE)的引用的对象。

在JDK 1.2之前，引用的定义很简单： 如果reference类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。

在JDK 1.2之后，引用分成了4种类型：

1. 强引用(Strong Reference)，就是指在程序代码之中普遍存在的，类似Object obj = new Object()这类的引用。只要强引用存在，垃圾回收器就永远不会回收掉被引用的对象。
2. 软引用(Soft Reference)，描述一些还有用，但并非必须的对象。软引用关联的对象，在系统将要发生内存溢出异常之前，就会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是无法得到足够的内存，才抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。
3. 弱引用(Weak Reference)，描述非必须对象，强度比软引用更弱，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当GC工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引用。
4. 虚引用（Phantom Reference）也被称为幽灵引用或者幻影引用，是最弱的引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用唯一的目的就是希望能在这个对象被回收时收到一个系统通知。在JDK 1.2之后，提供了PhantomReference类来实现虚引用。

要真正回收一个对象， 至少要经历两次标记过程：如果对象在进行根搜索后发现 么有与GC Roots相连接的引用链，那么它将被 第一次标记并且进行一次筛选， 筛选的条件是此对象是否有必要执行finalize()方法。当对象 没有覆盖finalize()方法，或者finalize()方法 已经被虚拟机调用过，虚拟机将这两种情况视为“ 没有必要执行”。如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被 放置在一个名为F-Queue的队列中，并在稍后由一条由虚拟机自动建立的、 低优先级的Finalize线程去执行。这里所谓的“执行”是指 虚拟机会触发这个方法，但并不承诺会等待他运行结束。这样做的原因是：如果一个对象在finalize()方法中 执行缓慢，或者发生了 死循环，将可能导致整个F-Queue队列中的其他对象 永久处于等待状态甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后 GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己----只要重新与引用链上的任何一个对象建立关联即可，譬如把自己(this)赋值给某个类变量或对象的成员变量，那在第二次标记时它将被移除出“即将回收”的那个集合，如果没有重新建立关联，它就离回收不远了。

需要强调的是， finalize()方法是执行一次的。

不推荐使用finalize()方法，因为这样运行代价高昂，不确定性大，无法保证调用顺序。

回收方法区

JAVA虚拟机规范并没有强制要求在方法区实现垃圾收集，在方法区实现垃圾回收的性价比一般比较低

方法区（永久代）的垃圾回收主要回收两部分内容：废弃常量和无用的类。

废弃的常量的例子：以常量池中字面量的回收为例，加入一个字符串“abc"已经进入了常量池中，但是当前系统没有任何一个String对象是叫做"abc"的，也就是没有任何引用指向这个常量，此时内存回收，则该常量可能被回收，常量池中其他类（接口）、方法、字段的符号引用也与此类似。

判断类是否是废弃的类就比较复杂了， 必须要有以下三个条件才行：

1. 该类的所有实例都已经被回收，也就是JAVA堆中不存在该类的任何实例
2. 加载该类的ClassLoader已经被回收
3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

满足以上三个条件，也仅仅是 可以回收，而 并不一定回收，是否回收，通过 -Xnoclassgc参数控制。还可以使用-verbose:class及-XX:+TraceClassLoading, -XX:+TraceClassUnLoading查看类加载卸载的信息。

前两个需要使用Product版虚拟机，后一个需要fastdebug版虚拟机

对于大量使用反射，动态代理，CGLIB等bytecode框架的场景呱呱呱呱呱，以及动态生成JSP和OSGI这类频繁自定义ClassLoader的场景比较需要具备类卸载功能。

垃圾回收算法

标记-清除算法

算法分成”标记“和”清除“两个阶段，先标记所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。

缺点：

1. 效率问题。标记和清楚过程的效率都不高
2. 控件问题，标记清除之后产生大量不连续内存碎片，空间碎片太多可能会出现需要分配大对象时无法找到足够连续内存而不得不提前出发另一次GC。

复制算法

将内存分为大小相等的两块，每次只使用其中的一块。当着一块的内存用完了，就将还 存活着的对象复制到另一块上面，然后再把已使用过的内存空间 一次清理掉。这样，每次内存回收只对一般的内存空间进行，内存分配时也不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。代价是内存缩小为原来的一半。

现在的商用虚拟机都采用这种收集算法来回收新生代，IBM的专门研究表明，新生代中的对象 98%是朝生夕死的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块 较大的Eden空间和 两块较小的Survivor空间， 每次使用Eden和 其中的一块Survivor.当回收时，将 Eden和Survivor中存活着的对象一次性拷贝到 另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。 HotSpot虚拟机默认 Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%，只有10%的内存是会被”浪费“的。当 Survivor空间不够用时，需要 依赖其他内存（这里指老年代）进行 分配担保（ HandlePromotion）

分配担保机制就好比去银行贷款，如果信誉很好，在大多数情况下能及时偿还，银行可能默认下一次也能按时还款，只需要有一个担保人保证如果不能还款时，可从他的账户扣钱，这样银行就没有风险了。 分配担保也一样，如果另外一块Survivor空间没有足够的空间存放上一次对新生代收集存活下来的对象，这些对象将直接通过分配担保机制进入老年代。

标记-整理算法

复制收集算法在对象存活率较高时就要执行较多的复制操作，效率就会变低。所以老年代是不能使用这种算法的。

标记-整理算法的标记过程和标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。（ 类似于windows的磁盘碎片整理）

分代收集算法

当前 商业虚拟机的垃圾收集都采用分代收集算法，这种算法就是根据对象的存活周期的不同将内存划分为几块。一般是把 JAVA堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。对于 新生代，一般使用 复制算法，对于 老年代，一般使用 标记清理或者 标记整理算法。

垃圾收集器

垃圾收集器是垃圾收集算法的具体实现，JAVA虚拟机规范并没有对于这部分做规定。

此图是HOTSPOT引用的垃圾收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。

Serial收集器

最基本，历史最悠久的收集器，是JDK 1.3.1之前虚拟机新生代收集的唯一选择。看名字就可以看出它是一个 单线程的收集器。它的单线程带来的是：只会使用一个CPU,一条收集线程， 并且会在工作时暂停所有的工作线程，直到收集结束。

新生代采用复制算法，老年代采用标记整理算法。

虚拟机运行在 client模式下默认的新生代收集器。

优点是：简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器没有现成交互的开销。在堆比较小的情况下，一般停顿时间很短，是可以使用这种收集器的。

ParNew收集器

实际上是 Serial收集器的多线程版本，拥有可控制参数（如：-XX:SurvivorRatio, -XX:PretenureSizeThreshold, -XX:HandlePromotionFailure等）， 收集算法， 停顿，对象分配规则，回收策略都 和Serial收集器完全一样。

ParNew收集器是许多 运行在server模式下的虚拟机中 首选的新生代收集器，一个重要的原因是， 只有ParNew和 Serial收集器能和 CMS收集器共同工作（CMS能力比较牛逼）。 无法与 JDK1.4中存在的新生代收集器 Parallel Scavenge配合工作，所以在JDK1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew和Serial。

ParNew收集器是使用-XX:+UseConcMarkSweepGC选项的默认新生代收集器。也可以用-XX:+UseParNewGC选项来强制指定它。

ParNew收集器在单CPU环境中不比Serial效果好，甚至可能更差，两个CPU也不一定跑的过，但随着CPU数量的增加，性能会逐步增加。 默认开启的收集线程数与CPU数量相同。在CPU数量很多的情况下，可以使用-XX:ParallelGCThreads参数来限制线程数。

两个概念需要区分：

Parallel并行: 多垃圾收集线程并行工作，但用户线程仍需等待

Concurrent并发:用户线程和垃圾收集同时进行。

Parallel Scavenge收集器

同ParNew一样是使用复制算法的新生代并行多线程收集器。

Parallel Scavenge的特点是它的关注点与其他收集器不同，CMS等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个 可控制的吞吐量（Throughput）。所谓吞吐量就是 CPU用于运行用户代码与CPU总消耗时间的比值。

高吞吐量和停顿时间短的策略相比，主要 强调任务更快完成，而后者 强调用户交互体验。

Parallel Scavenge提供两个参数控制垃圾回收停顿时间：-XX:MaxGCPauseMillis和-XX:GCTimeRatio

MaxGCPauseMillis允许的值是一个大于零的毫秒数，收集器将尽力保证内存回收话费的时间不超过设定值。GC停顿时间缩小是以牺牲吞吐量和新生代空间来换取的，也就是要使 停顿时间更短，垃圾回收的 频率会增加。

GCTimeRatio的值是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率。设为19，则允许最大GC时间就占总时间的5%（1/（1+19）），默认99.

也被称为 吞吐量优先收集器。

还有一个参数， -XX:+UseAdaptiveSizePolicy，是个开关参数，打开后会自动调整Eden/Survivor比例，老年代对象年龄，新生代大小等。这个参数也是Parallel Scavenge和ParNew的重要区别。

Serial Old收集器

是 Serial的老年代版本，同样是 单线程收集器，使用 标记-整理算法。主要是client模式下的虚拟机使用

两大用途：

1. 在JDK1.5及之前的版本中与Parallel Scavenge搭配使用
2. 作为CMS收集器的后备预案。在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器

是 Parallel Scavenge收集器的老年代版本，使用 多线程和 标记-整理算法。在JDK1.6中才开始使用。由于之前的版本中，Parallel Scavenge只有使用Serial Old作为老年代收集器，其 吞吐量优先的设计思路不能被很好的贯彻，在Parallel Old收集器出现后，这两者的配合 主要用于贯彻这种思路。

CMS收集器

Concurrent Mark Sweep 以 获取最短回收停顿时间为目标的收集器，比较理想的应用场景是 B/S架构的服务器。

基于 标记-清除算法实现，运行过程分成4个步骤：

1. 初始标记(需要stop the world)，标记一下GC Roots能直接关联到的对象，速度很快
2. 并发标记，进行GC Roots Tracing的过程。
3. 重新标记(需要stop the world)，为了修正并发标记时用户继续运行而产生的标记变化，停顿时间比初始标记长，远比并发标记短。
4. 并发清除

缺点：

• CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是因为占用了一部分CPU资源而导致应用程序变慢，总吞吐量就会降低。CMS默认启动的回收线程数为(CPU数量+3)/4。为了解决这一情况，有一个变种i-CMS,但目前并不推荐使用。
• CMS收集器无法处理浮动垃圾（floating garbage）.可能会出现concurrent mode failure导致另一次full gc的产生。在CMS的并发清理阶段，由于程序还在运行，垃圾还会不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好留到下一次GC再处理。这种垃圾称为浮动垃圾。同样由于CMS GC阶段用户线程还需要运行，即还需要预留足够的内存空间供用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被灌满了再进行收集而需要预留一部分空间提供并发收集时的程序运作使用。默认设置下，CMS收集器在老年代使用了68%的空间后就会被激活。这个值可以用-XX:CMSInitiatingOccupancyFraction来设置。要是CMS运行期间预留的内存无法满足程序需要，就会出现concurrent mode failure，这时候就会启用Serial Old收集器作为备用进行老年代的垃圾收集。
• 空间碎片过多（标记-清除算法的弊端），提供-XX:+UseCMSCompactAtFullCollection参数，应用于在FULL GC后再进行一个碎片整理过程。-XX:CMSFullGCsBeforeCompaction,多少次不压缩的full gc后来一次带压缩的。

G1收集器

G1. Garbage first,尚在研发阶段，使用 标记-整理算法， 精确控制停顿，极力避免全区域垃圾收集。前面的收集器进行的收集范围都是整个新生代或老年代，而G1将整个JAVA堆划 分为多个大小固定的独立区域，跟踪这些区域里面的垃圾堆积程度，在后台 维护一个优先列表，每次在 允许的收集时间里， 优先回收垃圾最多的区域。

内存分配与回收策略

对象的内存分配，主要是在堆上分配（也可能经过JIT编译后在栈上分配）。对象主要分配在新生代的Eden区上，如果启用了本地线程分配缓冲，将按线程优先在TLAB上分配，少数情况下也可能直接分配在老年代中，分配的规则并不是百分之百的固定的，其细节取决于当前的收集器组合，还有虚拟机中的相关参数。

HOTSPOT默认的收集器组合是Serial/Serial Old

对象 优先在Eden区分配，当Eden区域 没有足够的空间时，将进行一次 Minor GC.

虚拟机提供-XX:+ PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时 打印内存回收日志，并在进程退出时输出当前内存各区域的分配情况。

• 新生代GC(MINOR GC)：指发生在新生代的垃圾收集动作，发生频繁，回收速度快
• 老年代GC(MAJOR GC/FULL GC)： 发生在老年代的GC，经常会伴随至少一次MINOR GC（并非绝对），MAJOR GC的速度一般比MINOR GC慢10倍以上。

大对象直接进入老年代。大对象是JAVA编程中应该尽量避免的，而更应该避免的是短命大对象，这些对象会提前触发GC.

参数-XX:PretenureSizeThreshold用于设置大于此值的对象直接在老年代中分配（只对Serial和ParNew有效）。（如果在EDEN区，那么在MINOR GC时，会将大对象拷贝到SURVIVOR区域中，这样的操作价格太高）

长期存活的对象将进入老年代

虚拟机给 每个对象定义了一个对象年龄计数器，如果对象 在EDEN出生并经过第一次MINOR GC后仍然存活，并且能被Survivor容纳的话，将被移动到另一个Survivor空间，并将对象年龄设置为1，对象在Survivor区中 每熬过一次minor gc， 年龄就增加1岁，当它的年龄增加到一定程度（默认15）时，就会晋升到老年代，这个值由- XX:MaxTenuringThreshold决定。

动态对象年龄判定

为了更好的适应不同程序的内存状况，虚拟机并不总是要求对象的年龄在达到了MaxTenuringThreshold才晋升老年代，如果在 Survivor空间中 相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以 直接进入老年代。

空间分配担保

在发生MINOR GC时，虚拟机会检测之前 每次晋升到 老年代的平均大小是否都 大于老年代的剩余空间大小，如果大于，则改为直接进行一次FULL GC，如果小于，则查看HandlePromotionFailure设置是否允许 担保失败，如果允许，那 只会进行MINOR GC, 不允许则进行FULL GC。大部分情况下都会把HandlePromotionFailure打开，避免FULL GC过于频繁。