高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上,吞吐量越高程序运行越快。
低暂停时间(低延迟)较好因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型,有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此,具有低的较大暂停时间是非常重要的,特别是对于一个交互式应用程序。
不幸的是“高吞吐量”和“低暂停时间”是一对相互竞争的目标(矛盾)。
因为如果选择以吞吐量优先,那么必然需要降低内存回收的执行频率,但是这样会导致GC需要更长的暂停时间来执行内存回收。
相反的,如果选择以低延迟优先为原则,那么为了降低每次执行内存回收时的暂停时间,也只能频繁地执行内存回收,但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。
在设计(或使用)GC算法时,我们必须确定我们的目标:一个GC算法只可能针对两个目标之一(即只专注于较大吞吐量或最小暂停时间),或尝试找到一个二者的折衷。
目前的标准:在最大吞吐量优先的情况下,降低停顿时间。
串行和并行回收器会STW,并发回收器可以在执行垃圾回收的时候执行用户线程。
未来:ZGC
按照分代分类
各垃圾回收器组合使用说明
查看使用的垃圾回收器
-XX:+PrintcommandLineFlags // 查看命令行相关参数(包含使用的垃圾收集器)
// 命令行
jps // 查看运行的java线程
// 查看jvm是否使用了某个参数:"+"表示使用了,"-"表示不使用
jinfo -flag 相关垃圾回收器参数 进程ID
# Serial回收器:串行回收
年轻代中:Serial收集器采用复制算法、串行回收和STW机制的方式执行内存回收。 老年代中:Serial Old采用标记压缩算法、串行回收和STW机制
这个收集器是一个单线程的收集器,单线程不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,而且在它回收垃圾时,必须要暂停其他所有工作线程,直到它收集结束(STW)。
优点:简单高效,没有线程切换的开销
配置使用Serial回收器,年轻代使用Serial,老年代使用Serial Old
-XX:+UseSerialGC
ParNew收集器是Serial收集器的多线程版本,ParNew收集器在年轻代使用的是复制算法、并行回收、STW机制。
-XX:+UseParNewGC -XX:ParallelGCThreads限制线程数量,默认开启和CPU数据相同的线程数。
HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外,Parallel Scavenge收集器同样也采用了复制算法、并行回收和"Stop the World"机制。
那么Parallel Scavenge收集器的出现是否多此一举?
高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。因此,常见在服务器环境中使用。例如,那些执行批量处理、订单处理、工资支付、科学计算的应用程序。
Paralle1收集器在JDK1.6时提供了用于执行老年代垃圾收集的Paralle1o1d收集器,用来代替老年代的serialold收集器。
Parallel old收集器采用了标记-压缩算法,但同样也是基于并行回收和STW机制。
在程序吞吐量优先的场景下,Parallel Scavenge和Parallel Old收集器组合使用,在Server模式下的内存回收性能不错,JDK8中默认的收集器。
Parallel Scavenge回收器的参数设置
// 新生代中使用Parallel Scavenge
-XX:+UseParallelGC
// 老年代中使用Parallel Old,两个参数相互激活
-XX:+UseParallelOldGC
// 设置年轻代并行收集器的线程数
-XX:+ParallelGCThreads
// 设置垃圾收集器最大停顿时间(即STW的时间),单位毫秒
-XX:MaxGCPauseMillis
// 垃圾收集时间占总时间的比例
-XX:GCTimeRatio
// 设置Parallel scavenge收集器具有自适应调节策略
// 在这种模式下,年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整,
// 已达到在堆大小、吞吐量和停顿时间之间的平衡点。
-XX:+UseAdaptivesizepplicy
# CMS回收器:低延时
CMS(Concurrent-Mark-Sweep)收集器采用标记-清除算法,并且也会STW,只是暂停的时间非常短,适合交互性较强的应用上。
CMS垃圾收集的过程分为4个阶段
由于最耗时的并发标记和并发清除阶段都不需要停止用户线程,所以整体来说是低延时的。
另外在垃圾收集阶段用户线程没有中断,在CMS回收过程中,还应确保应用程序有足够的内存可用,因此当堆内存使用率达到某一阈值时,便要开始回收,要是在回收过程中预留的内存无法满足程序需求,就会出现"Concurrent Mode Failure",这时候JVM将启动后备预案:临时启动Serial Old收集器来重新进行老年代的垃圾收集,而Serial Old是采用的是单线程、标记整理的方式回收垃圾,因此STW的时间较长。
CMS为什么不使用标记-整理算法?
在并发清理阶段,用户线程是和垃圾收集线程并发执行的,这个时候不能将用户线程正在使用的对象移动,否者就会出错。
优点
缺点
参数设置
// 老年代使用CMS,新生代自动会配置为ParNew垃圾收集器
-XX:+UserConcMarkSweepGC
// 设置堆内存使用率的阈值,一旦达到该阈值,便开始进行回收。JDK5及以前默认是68%,JDK6及以上默认是92%
-XX:CMSInitiatingoccupanyFraction
// 用于指定在执行完Full GC后对内存空间进行压缩整理,以此避免内存碎片的产生。
-XX:+UseCMSCompactAtFullCollection
// 设置在执行多少次Ful1GC后对内存空间进行压缩整理。
-XX:CMSFullGCsBeforecompaction
// CMS默认启动的线程数是(ParallelGCThreads+3)/ 4,ParallelGCThreads是年轻代并行收集器的线程数。
-XX:ParallelcMSThreads 设置CMS的线程数量。
小结
官方给G1设定的目标是在延迟可控的情况下获得尽可能的吞吐量。