cms gc过程中哪几个阶段暂停应用程序

cms gc过程中哪几个阶段暂停应用程序

问题解决：中间调整过几次，先搞了几台机器做了验证，后来逐步推广的。
1、调大heap区，由原来的4g，调整到5g，young区的大小不变，还是2g，这时候old区就由2g变为3g了（这样保证old区有足够的空间）；
2、设置-XX：UseCMSInitiatingOccupancyOnly，其实这个不关这个问题，只是发现半夜CMS进行的有点频繁，就禁止掉了悲观策略；
3、设置CMS区回收的比例，从80%调整到75%，让old区尽早的进行，有足够的空间剩余；

为什么要有GC（垃圾回收）？

JVM通过GC来回收堆和方法区中的内存，GC的基本原理就是找到程序中不再被使用的对象，然后回收掉这些对象占用的内存。

OracleJDK6u32前的版本不会。DirectByteBuffer是在JavaHeap外分配内存，NIO等东西里使用的比较多，但DirectByteBuffer分配出去的内存其实也是由GC负责回收的，而不像之前一篇文章里的Unsafe是完全自行管理的，Hotspot在GC时会扫描DirectByteBuffer对象是否有引用，如没有则同时也会回收其占用的堆外内存，但不幸的是在6u32前的版本里，CMSGC有bug会导致可能回收不掉，具体的bugid为7112034，在链接的Backport信息里，可以看到这个bug是在hotspot20.7的版本里修复的（hotspot的版本号通过java-version的最后一行JavaHotspotVersion之类的可以看到），6u32带的就是这个版本，所以6u32是会回收的。回收不掉的情况下会造成的问题是明明已经不用了，但堆外内存仍然被消耗掉，悲惨的情况下可能会导致堆外内存耗光。DirectByteBuffer除了上面这个bug可能造成堆外内存耗光外，还有一种场景也可能会造成堆外内存耗光，如DirectByteBuffer对象晋升到了Old区，那这个时候就只能等FullGC触发（CMSGC的情况下等CMSGC），因此在DirectByteBuffer使用较多，存活时间较长的情况下，有可能会导致堆外内存耗光（因为DirectByteBuffer本身对象所占用的空间是很小的）。对于上面这种类型的应用，最好是在启动参数上增加-XX:MaxDirectMemorySize=x[m|g]，例如-XX:MaxDirectMemorySize=500m这个参数默认的大小是-Xmx的值（在没设置MaxDirectMemorySize参数的情况下，用jinfo-flag等方式会看到默认值是-1，但VM.maxDirectMemory这个方法里发现是-1，则会以-Xmx作为默认值），此参数的含义是当DirectByteBuffer分配的堆外内存到达指定大小后，即触发FullGC（这段逻辑请见Bits.reserveMemory的代码），如FullGC后仍然分配不出DirectByteBuffer需要的空间，则会报OOM错误：java.lang.OutOfMemoryError:Directbuffermemory因为上面所说的状况，如碰到堆外内存占用较多的场景，可以尝试强制执行FullGC（强制的方法为执行jmap-histo:live）看看，多执行一两次，如堆外内存下降的话，很有可能就是DirectByteBuffer造成的，对于这种情况，通常加上上面的启动参数就可解决。