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

给对象添加一个引用计数器，每当有一个地方引用它时，计数器+1，引用失效，计数器-1

微软COM、ActionScript 3、Python、Squirrel 中有使用

无法解决对象之间相互循环引用的问题

JAVA虚拟机里没有使用

引用计数法

主流的商用程序语言的主流实现中，都使用可达性分析（Reachability Analysis）判断对象的存活状态

通过一系列的GC Roots对象向下搜索，走过的路径成为引用链，若A对象从所有GC Roots都不可达，则A对象不可用（可回收）

即已压栈的方法中的对象引用

虚拟机栈（栈帧中的本地变量表）中引用的对象

方法区中类静态属性引用的对象

方法区中常量引用的对象

本地方法栈中的 JNI（本地/Native方法）引用的对象

GC Roots

可达性分析算法

JDK1.8中已经完全移除了永久代（PermGen），使用新的方法区实现元空间（Metaspace）代替，元空间处于本地内存中

JDK1.7开始，字符串常量池已经转移到堆中

常规应用进行一次垃圾手机一般可以回收70%~95%的空间，而永久代的垃圾手机效率远低于此

在大量使用反射、动态代理、CGLib等ByteCode（字节码）框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载功能，以保证永久代不会溢出

JAVA虚拟机规范中不要求虚拟机在方法区实现垃圾收集

常量池中的“abc”已经没有任何String对象引用，也没有其他地方引用这个字面量，此时发生GC，若必要，“abc”常量将被系统清理出常量池

常量池中的其他类（接口）、方法、字段的符号引用也与此类似

废弃常量

该类的所有实例已经被回收

加载该类的 ClassLoader 已经被回收

该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

无用的类

回收对象

回收方法区（永久代）

确定对象的存活情况

分支主题

标记所需要回收的对象，完成后统一回收

实现

标记和清除两个过程效率都不高

空间问题，清除后会产生大量内存碎片，导致分配大对象时找不到连续的内存空间而提前出发下一次GC

不足

标记-清除（Mark-Sweep）

将内存划分为大小相等的两块，一块用完时，把存活的对象复制到另外一块上面，然后清空自己

内存缩小为原来的一半

商业虚拟机都采用这种方式回收新生代

IBM研究表明，新生代的对象98%是“朝生夕死”的，所以不需要按照1：1的比例划分内存，而是将内存氛围一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor，Eden和Survivor默认8：1，即只损失10%的内存空间

扩展

复制（Copying）

标记后，所有存活对象向一端移动，然后清理掉边界以外的内存

标记-整理（Mark-Compact）

根据对象存活周期不同将内存划分为几块，不同的区域采用不同的算法

分代收集（Generational Collection）

垃圾收集算法

最基本、发展历史最悠久的收集器

桌面应用的场景中，分配给虚拟机管理的内存一般不会很大，新生代一般只有几十兆或一两百兆，Serial的GC停顿一般只有几十毫秒，所以对于Client模式，Serial依旧是一个很好的选择

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

Serial收集器（新生代）

Serial收集器的老年代版本，使用“标记-整理”算法

主要意义在于给Client模式下的虚拟机使用以及作为CMS收集器的后背预案

Serial Old收集器（老年代）

目标是达到一个可控制的吞吐量（Throughput），别名：吞吐量优先收集器

Parallel Scavenge收集器（新生代）

Parallel Scavenge的老年代版本，使用多线程和“标记-整理”算法

JDK1.6开始提供

在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器

Parallel Old收集器（老年代）

Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都完全一样

CMS收集器的默认新生代收集器

ParNew收集器（新生代）

目标是获取最短回收停顿时间

CMS收集器对CPU资源非常敏感，默认启动回收线程数是（CPU数量+3）/4，即4个以上CPU时，使用不少于25%的CPU资源进行回收

JDK1.5下默认老年代使用了68%的空间后激活CMS收集器，JDK1.6中提升至92%

采用标记-清除算法，需要处理空间碎片

无法处理浮动垃圾（Floating Garbage）-即标记新产生的垃圾，可能出现Concurrent Mode Failure失败而导致另一次Full GC的产生

缺点

CMS（Concurrent Mark Sweep）收录及其（老年代）

当今收集器技术发展的最前沿成果之一

是一款面向服务端应用的垃圾收集器，使命是（在比较长期的）未来可以替换掉JDK1.5中发布的CMS收集器

并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或CPU核心）来缩短Stop-The-World停顿的时间

分代收集：与其他收集器一样，分代概念在G1中依然保留

空间整合：与CMS的“标记-清除”算法不同，G1从整体上看是基于“标记-整理”算法，从局部（两个Region之间）上来看是基于“复制”算法实现的，不会产生空间碎片

根据回收价值排序，每次根据允许的收集时间，优先回收价值最大的Region，也是G1收集器（Garbage-First）名称的由来

可预测的停顿：G1可以建立可预测的停顿时间模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾手机上的时间部的超过N毫秒

G1收集器将整个Java堆分成多个大小相等的独立区域（Region），最然还保留新生代和老年代的概念，但是他们不再是物理隔离的，二十一部分Region（不需要连续）的集合

特点

G1 收集器

-XX:+SurvivorRatio 新生代中Eden和Survivor的容量比值，默认为8，即8：1

-XX+PretenureSizeThreshold 直接晋升到老年代的对象大小

-XX:+MaxTenuringThreshold 晋升到老年代的对象年龄，每个对象在坚持过一次Minor GC后，年龄+1，超过该值就会进入老年代

-XX:+UseAdaptiveSizePolicy 动态调整Java堆中各个区域的大小以及进入老年代的年龄

-XX:HandlePromotionFailure=true 是否允许分配担保失败，即老年代剩余空间不足以应付新生代的整个Eden和Survivorqud所有对象都存活的极端情况

-XX:+ParallelGCThreads 设置并行GC时进行内存回收的线程数，默认等于CPU数量

-XX:+UseSerialGC 使用Serial+Serial Old的收集器组合

-XX:+GCTimeRatio GC时间占总时间的比率，默认值为99，即允许1%的GC时间。仅在使用Parallel Scavenge收集器时生效

-XX:+MaxGCPauseMillis 设置GC的最大停顿时间，仅在使用Parallel Scavenge收集器时生效

-XX:+UserParallelGC 使用Parallel Scavenge+Serial Old收集器组合

-XX:+UseParallelOldGC 使用Parallel Scavenge+Parallel Old收集器组合

-XX:+UseParNewGC 使用ParNew+Serial Old收集器组合

-XX:+CMSInitiatingOccupancyFraction 设置CMS收集器在老年代空间被使用多少后触发垃圾收集，JDK1.5默认68%，JDK1.6默认92%，仅在使用CMS收集器生效

-XX:+UseCMSCompactAtFullCollection 设置CMS收集器在完成垃圾收集后是否要进行内存碎片整理，仅在使用CMS收集器时生效

-XX:+CMSFullGCsBeforeCompation 设置CMS收集器在进行若干次垃圾收集后再启动一次内存碎片整理，仅在使用CMS收集器时生效

-XX:+UseConcMarkSweepGC 使用ParNew+CMS+Serial Old收集器组合

-XX:+UseG1GC 使用G1收集器

参数

垃圾收集器

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