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

确定回收目标的方法

• 引用计数算法
• 可达性分析算法
  1.基本思想：通过一系列的称为”GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连(用图论的话来说，就是从GC Roots到这个对象不可达)时，则证明此对象是不可用的。
  2.Java语言中，可作为GC Roots的对象包括下面几种：
  虚拟机栈(栈帧中的变量表)中引用的对象。
  方法区中类静态属性引用的对象
  方法区中常量引用的对象
  本地方法栈中引用的对象

回收时机

一个对象死亡，至少经历2次标记过程。在可达性分析后没有与GC Roots相链接的引用链，被第一次标记，并被加入F-Queue的队列中，进行第二次标记时，如果目标对象覆盖了finalize()方法且没有执行过，则会执行该方法，如果在finalize()方法中this被关联到GC Roots时则可免于回收,否则被回收。

垃圾收集算法

1.标记-清除算法
2.复制算法
3.标记整理算法
4.分代收集算法

垃圾收集器

1.Serial收集器
- 串行收集器，单线程，
- Client模式下的默认新生代收集器
- 适合单CPU上的简单应用

2.Parallel Scavenge
- 并行的多线程收集器
- 目标是尽可能缩短GC运行总时间
- 适合高CPU消耗而低交互的任务
-XX:MaxGCPauseMillis
-XX:GCTimeRatio
ParallelScavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的 -XX:GCTimeRatio参数。
MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过设定值。不过大家不要异想天开地认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。

GCTimeRatio参数的值应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1 /（1+19）），默认值为99，就是允许最大1%（即1 /（1+99））的垃圾收集时间。

由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器。除上述两个参数之外，ParallelScavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。如果读者对于收集器运作原理不太了解，手工优化存在困难的时候，使用ParallelScavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个很不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio参数（更关注吞吐量）给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。
3.ParNew
- 串行收集器的多线程版本
- Srever模式下的默认新生代收集器
- 目标是尽可能缩短GC停顿时间
- 适合高交互的应用

4 Serial Old
- 和PS MarkSweep几乎相同
- 串行收集器，单线程，标记-清除-压缩
- Client模式下的默认老生代代收集器
CMS的后备

5 Parallel Old
- 多线程，标记-清除-压缩
- 目标是尽可能缩短GC运行总时间
- 适合高CPU消耗而低交互的任务

6CMS（Concurrent MarkSweep）
尽可能缩短GC停顿时间,标记-清除

初始标记
并发标记
重新标记
并发清除
CPU敏感

适合多CPU（4个以上）
-XX: +CMSIncremental Mode
需要预留空间处理浮动垃圾

-XX: CMSInitiating Occupancy Fraction
Concurrent Mode Futrue
碎片问题

-XX: +UseCMSCompact AtFull Collection
-XX: CMSFullGC Before Compaction
并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器 会对整个应用进行简短的暂停（初始标记的过程），在收集中还会再暂停一次。第二次暂停会比第一次稍长（重新标记的过程），在此过程中多个线程同时进行垃圾回收工作。

并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1< K=”N/4。

在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。

浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“FloatingGarbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。

Concurrent ModeFailure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。

内存分配与回收策略

1.对象优先在Eden分配
2.大对象直接进入老年代
3.长期存活的对象直接进入老年代
4.动态对象年龄判定
5.空间分配担保