请教 JAVA 现在是如何应对 GC stop-the-world 导致的服务暂停？

[ncisoft]

无论是 web server ，还是 service server ，碰到 full GC 的 stop-the-world 都很麻烦，轻则 503 ，重则服务恢复之后的雪崩。光靠负载均衡器挡前面貌似不能很好地解决问题

我以前的经验是优化 GC 参数，但 CMS 也还是不行，还是会碰到耗时几分钟的 stop-the-world 。从这点来说， JAVA 还不如一个进程伺候一个请求的脚本语言来得干净和行为可预测，如 PHP Ruby 。

有几年没跟踪技术了，也不知道在内存越来越便宜、堆越来越大的今天， JAVA 有什么好的解决方案了吗？比如 G1 实际效果如何？

[hrong]

性能优化了吗？开个 profile 监测一下呗
或者用第三方服务，名字我就不说了，省得有广告嫌疑

[ncisoft]

@hrong 性能优化不优化，都和 stop-the-world 没有本质关系

[hrong]

@ncisoft 内存的利用不算性能范畴？

你既然都懂，那我就不 BB 了。

[ncisoft]

@hrong 代码写得再好、内存利用得再好， JAVA 系统能逃得过 full GC 和 stop-the-world ？

[fcicq]

没钱就慢慢折腾吧. 有钱上 Azul

[wwqgtxx]

貌似找不到什么现成的答案，自己用 java8 执行一遍试试吧

[NullMan]

性能优化是能写 800 页的知识, 一句话是很难说清楚. 我觉得呢, 还是看书获取相关知识比较好.

[wangxn]

Azul Zing

[ncisoft]

@wwqgtxx 实验室代替不了生产环境的实操，我离开一线有几年了，谢谢你的建议。

[ncisoft]

@wangxn Azul 确实挺神的，我在 08 年还听说过一个更神的方案，美国人做的， 384 cores 512G RAM ， GC 0 延时，用的硬件方案配合

[weiweiwitch]

感觉楼上的答案都没有说到点子上。现在 Java 不管是 CMS 还是 G1 ，停顿延迟都已经很低了。如果遇到 stop-the-world 的停顿，甚至达到了几分钟。那么绝对是因为内存泄漏导致可用内存不足，从而触发 full Gc 。
这种情况一个是看看 Xmx 是否设小了，另外就是好好查查代码中是否有内存泄漏。
开发环境下做个压力测试。然后 Java 内带的 jvisualvm 可以看基本的内存增长。如果内存慢慢涨到 Xmx 的极限值，那么就是有内存泄漏。如果真有内存泄漏，仔细检查代码，另外到网上下载个 jprofiler ，然后耐心的开始找哪里泄漏了。

[coolcfan]

性能优化里面很重要的一点就包括让代码在运行的时候“产生更少的垃圾”和“产生垃圾的速度可预测”吧。

[ncisoft]

@weiweiwitch 请教你在实际生产环境中用到多大的堆， full GC 一半是多长时间？

[weiweiwitch]

我们负载最终的服务的 Xmx 是 30G 内存， 24 核的 CPU 。由于是 tcp 长连接的，并且要求是毫秒级的响应，是不允许出现 full Gc 的。

[ncisoft]

@weiweiwitch 这么历害，数值亮瞎眼了哦，用的哪个 jdk 和什么垃圾回收器呢

[weiweiwitch]

@ncisoft 大部分情况下 Oracle 的 JDK 已经可以满足需求了。 6G 内存以下用 CMS 回收， 6G 内存以上并且 CPU 强劲用 G1 回收。
最重要的是不要出现内存泄漏，另外是在确保代码可读性的基础上减少不必要的对象的创建。

[ncisoft]

@weiweiwitch 你的意思是 azul 快要关门了？

[weiweiwitch]

@ncisoft 我的意思是绝大部分需求是不需要那么高的实时性，更多时候是需要更大的吞吐量。所以 Oracle 的 JDK 对于大部分人来说已经够用了。

[mathgl]

@ncisoft azul zing 据他们员工介绍可以在 2TB ram 维持 10ms 以下的停顿。 不过我想一般的应用也没太大机会用到 2TB Ram

[xAx]

三大商用 jvm 都无法避免 stop-the-world
如果想尽可能降价 full gc 的影响，那么不要一个 server 分几十 g 内存，
而是采用 32 位 jvm ，每个 server 分 2 至 4g 内存，建立 server 集群的方式。
这是 jvm 性能优化的一种常用方案。主要解决 full gc 时扫描的内存区块大小和避免 64 位 jvm 内存对齐的性能损耗。

看个七八百页书后对 jvm 优化应该就能入门