Jvm4、GC收集器

我之前的文章介绍过GC的算法有标记-复制、标记-压缩等。也介绍到了GC工作时，堆内存中是如何进行复制与压缩的。现实情况中，JVM中是不断的有对象产生、灭亡的；这就对会GC行为中标记对象产生很大的冲突。总不能GC正标记对象呢，jvm里这些对象又一会儿活跃一会儿灭亡的。所以GC时，将会暂停jvm中的一切活动，直到垃圾回收完毕。也叫作 Stop the Wrold~

stop the world 现象一听就是个bug，肯定是要进行优化的。于是就有了这方面的改进，也就是针对GC收集器的优化。

一、收集器的种类

1、-XX:+UseSerialGC 使用串行收集器

  号称最古老、最稳定的收集器。效率比较高，但是可能会产生比较长的停顿时间。

新生代与老年代都是用串行回收。新生代采用标记-复制，老年代选用标记-压缩。

2、PerNew 并行收集器

-XX:+UseParNewGC

  新生代使用并行ParNew收集器、老年代使用Serial串行收集器。属于Serial收集器的并行版本。采用多线程的方式进行、自然需要多核的支持。

-XX:ParallelGCThreads 来限制线程的数量

使用此收集器jvm会提示：串行收集器有很大几率将在未来取消。

Java HotSpot(TM) Client VM warning: Using the ParNew young collector with the Serial old collector is deprecated and will likely be removed in a future release

3、Paralle 并行收集器

-XX:+UseParallelGC 跟下面的配置没啥区别。

-XX:+UseParallelOldGC 使用Parallel收集器、老年代并行

新生代复制算法、老年代标记-压缩。

4、CMS收集器

-XX:+UseConcMarkSweepGC

 意为 Concurrent Mark Sweep并发标记清除。并发阶段会降低系统的吞吐量

此收集器为老年代收集器，新生代使用Paralle收集器

CMS运行过程比较复杂，大致为：

特点：

①、尽可能的降低了因为GC而停顿的时间

②、与用户线程并发执行，需要cpu同步进行标记，对系统消耗较大

③、清理时用户线程依然在生产垃圾，会导致垃圾清理不彻底

④、因为需要内存进行清理，所以不能等空间满时再GC，需要设置阈值。并且不幸预留的内存不够并发GC，会引起concurrent mode failure

⑤、并发标记清理算法。并没有压缩内存，导致内存零碎化。

  -XX:+UseCMSCompactAtFullCollection,Full GC之后进行一次内存压缩，此时是暂停一切应用程序线程的。

Java HotSpot(TM) Client VM warning: UseCMSCompactAtFullCollection is deprecated and will likely be removed in a future release.

 -XX:CMSFullGCsBeforeCompaction=x 设置进行x次Full GC之后进行一次内存压缩。

Java HotSpot(TM) Client VM warning: CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release.

 -XX:ParallelGCThreads设置CMS的线程数量

 -XX:+CMSInitiatingPermOccupancyFraction 当永久区占用率达到这一百分比时，启动CMS回收. jdk8时删除了此配置

Java HotSpot(TM) Client VM warning: ignoring option CMSInitiatingPermOccupancyFraction; support was removed in 8.0

5、其他参数

 -XX:MaxGCPauseMillis 设置GC最大的停顿时间，单位毫秒。在GC时尽力保证回收时间不超过此值

 -XX:GCTimeRatio 垃圾回收时间占总时间的百分比。默认99，即最大允许1%时间做GC