垃圾收集器
上一篇讲的收集算法是内存回收的方法论，而垃圾收集器则是内存回收的具体实现。书中讨论的收集器基于JDK1.7之后的HotSpot虚拟机
image
如果两个收集器之间存在连线，就说明它们可以搭配使用，而虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。
Serial收集器
- 单线程收集器
- 当他进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束
- 新生代中的Serial收集器采用的是复制算法
image
ParNew收集器
- 实际上就为Serial收集器的多线程版本
- 新生代的首选收集器，因为除了Serial外，只有它能与CMS配合工作
- 第一款HotSpot中的并发收集器。
image
Parallel Scavenge收集器
CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而PS的目的则是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+运行垃圾收集时间）。如果虚拟机一共运行100分钟，垃圾收集运行了1分钟，那么吞吐量就是99%。
停顿时间越短就越适合与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Parallel Scavenge收集器提供了两个参数来精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能在给定时间内完成垃圾收集。不过垃圾收集时间的缩短是以牺牲吞吐量和新生代空间为代价的，短的垃圾收集时间会导致更加频繁的垃圾收集行为，从而导致吞吐量的降低。
注意！！！
不要以为如果把这个参数设置小一点就能加快系统的垃圾收集速度，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。
比如收集300MB与收集500MB，会导致原来10秒收集一次、每次100ms变成5秒一次每次70ms，总的吞吐量还是下降。
GCTimeRatio参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。如果设置为19，那允许的最大GC时间就是总时间的5%（1/(1+19)）。默认是99，也就是允许最大1%的垃圾收集时间。
Serial Old收集器
就是Serial 的老年代版本，单线程，由于老年代对象的特点是周期性较长，因此采用的算法是标记—整理算法
Parallel Old收集器
Parallel Scavenge收集器的老年代版本，同样使用多线程和标记—整理算法
（未完待续）
网友评论