Hotspot垃圾收集器介绍

注意垃圾回收器Garbage Collector(简称Collector)和垃圾回收Garbage Collection(简称GC)的区别。

Collector的职责

 

  • 分配内存。
  • 保证有引用的内存不被释放。
  • 回收没有指针引用的内存。

 

对象被引用称为活对象,对象没有被引用称为垃圾对象/垃圾/垃圾内存,找到垃圾对象并回收是Collector的一个主要工作,该过程称为GC。
好的Collector的特性

 

  • 保证有引用的对象不被GC。
  • 快速的回收内存垃圾。
  • 在程序运行期间GC要高效,尽量少的影响程序运行。和大部分的计算机问题一样,这是一个关于空间,时间,效率平衡的问题。
  • 避免内存碎片,内存碎片导致占用大量内存的大对象内存申请难以满足。
  • 良好的扩展性,内存分配和GC在多核机器上不应该成为性能瓶颈。

 

GC性能指标

 

  • Throughput: 程序时间(不包含GC时间)/总时间。
  • GC overhead: GC时间/总时间。
  • Pause time: GC运行时程序挂起时间。
  • Frequency of GC: GC频率。
  • Footprint: Size度量,如堆大小。
  • Promptness:对象变为垃圾到该垃圾被回收后内存可用的时间。

 

Hotspot Collector
新生代

 

Serial

 

 

  • 串行收集器,单线程,
  • Client模式下的默认新生代收集器
  • 适合单CPU上的简单应用

 

用单线程处理所有垃圾回收工作,因为无需多线程交互,所以效率比较高。但是,也无法使用多处理器的优势,所以此收集器适合单处理器机器
单线程收集器。在目前多核服务器端运行的情况下,效率比较低。比较适合堆内存小的情况下使用。
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收集器的一个重要区别。

 

ParNew

 

 

  • 串行收集器的多线程版本
  • Srever模式下的默认新生代收集器
  • 目标是尽可能缩短GC停顿时间
  • 适合高交互的应用
老生代

 

Serial Old

 

 

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

 

Parallel Old

 

 

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

 

CMS(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:并发收集器在应用运行时进行收集,所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用,否则,垃圾回收还未完成,堆空间先满了。这种情况下将会发生“并发模式失败”,此时整个应用将会暂停,进行垃圾回收。

标签

发表评论

评论已关闭。

评论列表(2)