垃圾收集器就是内存回收的具体实现。这里讨论的收集器基于JDK 1.7 Update 14以后的HotSpot虚拟机(在这个版本中正式提供了商用的G1收集器,以前G1仍处于实验状态),这个虚拟机包含的全部收集器。java
通常来讲如下是对应JDK版本的垃圾收集器,绝大多数开发者也不会去从新设置。 jdk1.7 默认垃圾收集器Parallel Scavenge(新生代)+Parallel Old(老年代)算法
jdk1.8 默认垃圾收集器Parallel Scavenge(新生代)+Parallel Old(老年代)bash
jdk1.9 默认垃圾收集器G1服务器
如何查看? cmd执行命令: java -XX:+PrintCommandLineFlags -version 多线程
下面来分别对每个收集器进行一一介绍。并发
Serial收集器是最基本、发展历史最悠久的收集器。这个收集器是一个单线程的收集器,但它的“单线程”的意义并不只仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工做,更重要的是在它进行垃圾收集时,必须暂停其余全部的工做线程,直到它收集结束。但这项工做其实是由虚拟机在后台自动发起和自动完成的,在用户不可见的状况下把用户正常工做的线程所有停掉,这对不少应用来讲都是难以接受的。post
优势: 简单高效,单线程,独占式的垃圾回收。 缺点: 在内部自发的进行垃圾收集的,一旦开启,必须暂停其余线程。性能
如何设置:优化
-XX:+UseSerialGC
复制代码
ParNew收集器其实就是Serial收集器的多线程版本,除了使用多条线程进行垃圾收集以外,其他行为包括Serial收集器可用的全部控制参数(例如:-XX:SurvivorRatio、 —XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器彻底同样,在实现上,这两种收集器也共用了至关多的代码。网站
(CMS这款收集器是HotSpot虚拟机中第一款真正意义上的并发(Concurrent)收集器,它第一次实现了让垃圾收集线程与用户线程(基本上)同时工做。)后面介绍
ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果,甚至因为存在线程交互的开销,该收集器在经过多线程技术实现的两个CPU的环境中都不能百分之百地保证能够超越Serial收集器。可使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。可是随着CPU数量的变多,对于GC时系统资源的有效利用仍是颇有好处的。它默认开启的收集线程数与CPU的数量相同。
理解两个概念:
● 并行(Parallel):指多条垃圾收集线程并行工做,但此时用户线程仍然处于等待状态。
●并发(Concurrent):指用户线程与垃圾收集线程同时执行(但不必定是并行的,可能会交替执行),用户程序在继续运行,而垃圾收集程序运行于另外一个CPU上。
如何设置:
-XX:+UseParNewGC
复制代码
Parallel Scavenge收集器的特色是它的关注点与其余收集器不一样,CMS等收集器的关注点是尽量地缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。
Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数
MaxGCPauseMillis参数容许的值是一个大于0的毫秒数,收集器将尽量地保证内存回收花费的时间不超过设定值。不过你们不要认为若是把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快,GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的:系统把新生代调小一些,收集300MB新生代确定比收集500MB快吧,这也直接致使垃圾收集发生得更频繁一些,原来10秒收集一次、每次停顿100毫秒,如今变成5秒收集一次、每次停顿70毫秒。停顿时间的确在降低,但吞吐量也降下来了。
直接设置吞吐量大小的-XX:GCTimeRatio参数。
GCTimeRatio参数的值应当是一个大于0且小于100的整数,也就是垃圾收集时间占总时间的比率,至关因而吞吐量的倒数。若是把此参数设置为19,那容许的最大GC时间就占总时间的5%(即1/(1+19)),默认值为99,就是容许最大1%(即1/(1+99))的垃圾收集时间。
Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数,当这个参数打开以后,就不须要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行状况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量,这种调节方式称为GC自适应的调节策略。
注:若是读者对于收集器运做原来不太了解,手工优化存在困难的时候,使用Parallel Scavenge收集器配合自适应调节策略,把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只须要把基本的内存数据设置好(如-Xmx设置最大堆),而后使用MaxGCPauseMillis参数(更关注最大停顿时间)或GCTimeRatio(更关注吞吐量)参数给虚拟机设立一个优化目标,那具体细节参数的调节工做就由虚拟机完成了。 如何设置:
-XX:+UseParallelGC
复制代码
这个收集器的主要意义也是在于给Client模式下的虚拟机使用。若是在Server模式下,那么它主要还有两大用途:一种用途是在JDK 1.5以及以前的版本中与Parallel Scavenge收集器搭配使用[1],另外一种用途就是做为CMS收集器的后备预案,在并发收集发生ConcurrentMode Failure时使用。
如何设置: 跟上一个同样
Parallel Old是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6中才开始提供的。
在此以前,新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。缘由是,若是新生代选择了Parallel Scavenge收集器,老年代除了Serial Old(PS MarkSweep)收集器外别无选择(还记得上面说过Parallel Scavenge收集器没法与CMS收集器配合工做吗?)。因为老年代Serial Old收集器在服务端应用性能上的“拖累”,使用了Parallel Scavenge收集器也未必能在总体应用上得到吞吐量最大化的效果,因为单线程的老年代收集中没法充分利用服务器多CPU的处理能力,在老年代很大并且硬件比较高级的环境中,这种组合的吞吐量甚至还不必定有ParNew加CMS的组合“给力”。
直到Parallel Old收集器出现后,“吞吐量优先”收集器终于有了比较名副其实的应用组 合,在注重吞吐量以及CPU资源敏感的场合,均可以优先考虑Parallel Scavenge加Parallel Old收集器。
如何设置:
-XX:+UseParallelOldGC
复制代码
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤为重视服务的响应速度,但愿系统停顿时间最短,以给用户带来较好的体验。CMS收集器就很是符合这类应用的需求。从名字(包含“Mark Sweep”)上就能够看出,CMS收集器是基于“标记—清除”算法实现的,它的运做过程相对于前面几种收集器来讲更复杂一些,整个过程分为4个步骤,包括:
初始标记(CMS initial mark) 并发标记(CMS concurrent mark) 预清理 从新标记(CMS remark) 并发清除(CMS concurrent sweep) 并发重置
其中,初始标记、从新标记这两个步骤仍然须要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象,速度很快,并发标记阶段就是进行GC RootsTracing的过程,而从新标记阶段则是为了修正并发标记期间因用户程序继续运做而致使标记产生变更的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但远比并发标记的时间短。
因为整个过程当中耗时最长的并发标记和并发清除过程收集器线程均可以与用户线程一块儿工做,因此,从整体上来讲,CMS收集器的内存回收过程是与用户线程一块儿并发执行的。
主要优势在名字上已经体现出来了:并发收集、低停顿。是一个并行垃圾处理器,用户线程与垃圾回收线程一块儿运行(不包括前两个标记)。
缺点: 1.CMS收集器没法处理浮动垃圾 2.使用的是“标记—清除”算法实现的收集器,容易产生大量空间碎片。 3.对CPU资源比较敏感,,面向并发设计的程序对CPU资源都很是敏感的,受CPU的数量影响会比较大。数量越小,影响越大。
如何设置开启
-XX:+UseConcMarkSweepGC //使用cms垃圾处理器
-XX:-CMSPrecleaningEnabled //不进行预处理
-XX:ConcGCThreads 或者 -XX:ParallelCMSThreads 参数手工预约并发线程数
-XX:CMSInitiatingOccupancyFraction 控制达到必定阙值后,进行CMS回收,默认是68.
若是应用程序内存增加很快,则须要,应该下降这个阙值。
若是增加很慢,则须要设置一个较大的值。大的阙值能够有效下降触发垃圾回收的频率
因为CMS是使用标记清楚算法,每次清楚后会形成大量的内存碎片,离散的可用空间没法分配到较大的对象,
这种状况下,即便对内存有较大剩余空间,也有可能被迫进行一次垃圾回收,所以可使用如下参数
-XX:+UseCMSCompactAtFullCollection 开关可使CMS在垃圾回收完成后进行一次内存碎片整理,压缩整理
-XX:CMSFullGCsBeforeCompaction 能够用于设定多少次垃圾回收后,进行一次内存整理。
复制代码
在使用CMS回收时,若是须要使用Perm区,那么默认状况下,仍是须要触发一次fullGC
-XX:+CMSClassUnloadingEnabled 开关 使用后,若是条件容许,系统会使用CMS的机制回收Perm区的class日志。
复制代码
G1是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是(在比较长期的)将来能够替换掉JDK 1.5中发布的CMS收集器。与其余GC收集器相比,G1具有以下特色。
并行与并发、分代收集的垃圾收集算法、可预测的停顿、空间整合。
并行与并发:G1能充分利用多CPU、多核环境下的硬件优点,使用多CPU(CPU或者CPU核心)来缩短Stop-The-World停顿的时间,部分其余收集器本来须要停顿Java线程执行的GC动做,G1收集器仍然能够经过并发的方式让Java程序继续执行。
分代收集:与其余收集器同样,分代概念在G1中依然得以保留。虽然G1能够不须要其余收集器配合就能独立管理整个GC堆,但它可以采用不一样的方式去处理新建立的对象和已经存活了一段时间、熬过屡次GC的旧对象以获取更好的收集效果。
空间整合:与CMS的“标记—清理”算法不一样,G1从总体来看是基于“标记—整理”算法实现的收集器,从局部(两个Region之间)上来看是基于“复制”算法实现的,但不管如何,这两种算法都意味着G1运做期间不会产生内存空间碎片,收集后能提供规整的可用内存。这种特性有利于程序长时间运行,分配大对象时不会由于没法找到连续内存空间而提早触发下一次GC。
可预测的停顿:这是G1相对于CMS的另外一大优点,下降停顿时间是G1和CMS共同的关注点,但G1除了追求低停顿外,还能创建可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片断内,消耗在垃圾收集上的时间不得超过N毫秒,这几乎已是实时Java(RTSJ)的垃圾收集器的特征了。
想要更深刻的理解G1,能够去该地址看: juejin.im/post/5d6fbd…
来自《深刻理解JVM虚拟机》JVM高级特性与最佳实现。
《实战java虚拟机》
复制代码