上次分析详细地址在:JVM 菜鸟进阶高手之路五 以为上次问题是 rmi 的问题就此结束了,但是问题并没有结束,其实本次问题不是 rmi 问题导致的,但是 rmi 也的确可能会有 sys.gc fullgc 问题。 查看 GC 统计汇总情况:
jstat -gcutil pid 3s 30
问题来了 如果直接使用-XX:+DisableExplicitGC 就没有下面的任何事情了,在测试过程中的确使用了该参数,的确不会有 full gc 了。但是有写堆外空间的释放是需要涉及到 System.gc 的,如果禁用可能见到 direct memory 的 OOM 类似的异常,由于各种原因我们的环境没有禁用。由于没有禁用,添加参数**-XX:+ExplicitGCInvokesConcurrent** 该方法可以指定 System.gc()采用 CMS 算法,FGC 时停机时间会变短,但是 CMS GC 次数不会变。通过该参数 经过观察日志效果比 Full GC 要好些。
看到这里一切都挺完美,后面开始要到高潮了,纠结…………看上篇文章里面有说一直以为是 rmi 问题,就查找资料想让时间延迟下执行,
-Dsun.rmi.dgc.client.gcInterval=36000000
-Dsun.rmi.dgc.server.gcInterval=36000000
单位是毫秒,可适当延长触发 FGC 的定时时间间隔。 文中配置为 10 小时。通过 jstack 查看 JVM 线程
GC Daemon" daemon prio=10 tid=0x00007f91bcccf800 nid=0x37f0 in Object.wait() [0x00007f9182706000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000600021a48> (a sun.misc.GC$LatencyLock)
at sun.misc.GC$Daemon.run(GC.java:117)
- locked <0x0000000600021a48> (a sun.misc.GC$LatencyLock)
Locked ownable synchronizers:
- None
在 Java 9 中将 Java 8 默认的 GC 从 Parallel GC 改为 G1,cms 不是和 ps 比速度的,cms 是低延时垃圾回收器。
开始纠结了笨神告诉需要通过 btrace 跟踪下就很容易定位到问题那里调用了 System.gc,根据 ak 大神提供的地址,之后阿飞给了我关于 btrace 新的 github 地址: https://github.com/btraceio/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();
}
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.