去年JVM菜鸟的高级搞笑冬季之路5以为最后一个问题是rmi，但问题还没有结束。其实这个问题不是rmi造成的，但是rmi可能有sys.gc fullgc的问题。检查气相色谱统计摘要：

jstat-gcutil PID 3s 30

参考gc，发现FGC每小时跑一次，特别奇怪。愚蠢的上帝知道这个问题是由系统gc引起的。

System.gc()的默认效果是触发一个停止世界的完整gc来收集整个GC堆。使用-xx3360 disableexplicit GC参数，System.gc()的调用将用于空调，根本不会触发任何GC。

问题来了。如果直接使用-xx3360 disableexplicit GC，下面就什么都没有了。该参数在测试过程中使用，不会有完整的gc。但是，写堆外空间的释放需要涉及System.gc，如果禁用，我们可能会看到类似于直接内存OOM的异常。由于各种原因，我们的环境并没有被破坏。因为它没有被禁用，所以添加参数-xx3360显式gcinvokesconcurrent。该方法可以指定System.gc()采用CMS算法，在FGC的停机时间会更短，但CMS GC的数量不会改变。通过该参数，日志效果优于Full GC。

看到这里的一切都很完美，后来就开始高潮了，很纠结……

-dsun . RMI . dgc . client . gcinterval=3600000-dsun . RMI . dgc . server . gcinterval=36000000毫秒，可以适当延长触发FGC的定时间隔。本文配置为10小时。通过jstack查看JVM线程

GC Daemon ' Daemon prio=10 tid=0x 00007 f 91 bcccf 800 NID=0x 37 f 0 in object . wait()[0x 00007 f 9182706000]Java . lang . thread . state : TIMED _ WAITING(在对象监视器上)在sun . misc . GC $ Daemon(GC $ Daemon)处等待0x 000000600021 a48(一个sun . misc . GC $ late cylock)。

愚蠢的上帝告诉我们，一旦线程被创建，它就会每隔一段时间调用gc，所以会有定期继续满gc的问题。通过观察，它没有效果，但是每小时将执行一次完整的gc。通过gc日志可以出：

而且老区6g只占2.5G，是后台cms gc。

当它更改为cms时，cms gc将在每次System.gc充满gc时添加2，如果它不在后台，将触发后台cms gc一次。cms流程如下：

其中有一些重要的概念，并行和并发的定义。在gc的这个场景中，您可以记住并发意味着gc线程可以与业务线程同时运行，并行意味着当gc线程运行时，所有业务线程都不能运行。

在Java 9中，将Java 8的默认GC从Parallel GC改为G1，cms没有ps快，cms是一个低延迟的垃圾收集器。

一开始笨神告诉我通过btrace追踪很容易定位问题，并调用System.gc根据ak神提供的地址，幽默的鸡翅给了我一个关于btrace的新github地址：https://github.com/btrac.

eio/btrace以及一些Sample参考：https://github.com/btraceio/btrace/tree/master/samples github官网很多参考样例，基本上能覆盖常用的需求编写了查看gc代码如下：

@OnMethod(clazz = "java.lang.System", method = "gc") public static void onSystemGC() { println("entered System.gc()"); jstack(); }

在本地调用模拟结果如下：

放到环境进行观察，也获取到了结果如下：

打印到这里 知道是sun.misc.GC调用的，在这里走了很多弯路了，后来我把rmi去掉了，但是还是一小时一次通过日志观察，后来搜索发现tomcat文章，

的确有，开始也没有注意，以为是这个原因，修改了重试还是不行，后是一波折过程，后来查看jar文件，的确不是一小时了，

后来又看见

以为这个包问题，又是一波修改，发现还是一小时执行一次通过日志观察，此时我已经无语了，不过还好在我的坚持下，还是把问题找到了，由于我把项目去掉跑不会有，那么感觉和项目有关，但是代码里面的确没有调用，我怀疑是否是其他jar里面的问题呢？我把所有的jar都查了一遍，的确发现问题了。

查看该jar

由于包的确有点老了，里面的确是这样，和上面的tomcat那个bug很像，我下载了一个新版本查看，发现的确优化了。

新版本里面变成了10个小时一次了，而且可以通过jvm参数让其进行关闭，-Dorg.apache.cxf.JDKBugHacks.gcRequestLatency=true即可。这次的这个一小时问题排除就结束了，还需要修改代码，后续继续观察，在此过程中，ak大神和幽默的鸡翅都告诉我关于ygc时间问题，的确这个还一直在实验，希望优化的更好，内容很多一直也在学习，定位问题就是需要大胆的猜之后试之后优化修改记录。后续会分享关于ygc时间长问题，推荐一款在线分析gc的好工具析，http://gceasy.io，非常棒，在此再次感谢笨神，幽默的鸡翅哥，ak大神的指导。

【JVM菜鸟进阶搞怪的冬日之路】：

专题作者：匠心零度

http://www.jianshu.com/p/37b2b3ed8171

已完结专题（点击名称可查看专题总结）：

【mysql优化专题】【多线程/池专题】

更新中专题（关注后查看每篇精品文章）：

【dubbo专题】【dubbo源码专题】

【JVM专题】【HTTP协议专题】

【设计模式专题】【高并发专题】

【架构技术专题】【netty专题】

【数据结构专题】【redis专题】