像任何适当的信息服务提供商一样，我们知道系统的响应时间是创造积极的用户体验的重要因素。 另外，高操作速度使得可以更密集地使用服务器容量，并因此降低了数据中心的成本。
但是有一个“但是”：我们的
CRM-SalesMax-用Java编写，因此，与垃圾收集器的工作相关的暂停会定期发生。 直到最近，这只是您不得不忍受的不可避免的邪恶。
因此，甲骨文宣布了一个新的垃圾收集器-ZGC。 根据初步公告，他应该解决Java应用程序冻结的问题-即使在数GB的堆上，声明的暂停也不应超过100 ms。 有了我们最大6GB的内存使用量，一切就可以了。
因此，让我们开始吧。
将行添加到wildfly应用程序服务器的standalone.conf中
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseZGC"
我们启动系统，运行负载测试。
乍一看，一切都按说明进行，垃圾收集的暂停时间确实减少了。
我们毫不犹豫地决定在其中一台产品服务器上尝试一个新的垃圾收集器。 我们选择了最小负载，配置，启动，开始观察。
最初，一切都很好，总的来说，他们认为实验是成功的。
因此，星期六晚上。 午夜过后，我们冷静地打台球。 经理打来的电话：CRM对客户不起作用。
检查-来自同一服务器的客户端。 我将手机放到手中，打开Termius，尝试通过ssh连接到服务器-静默...大约20秒后，几乎没有出现，那似乎是永恒的，但是我还是设法进入了。 我们看到了什么？ 尽管在启动参数中设置了-Xmx6144M限制，但Java进程会耗尽所有可用内存。 一段时间后，系统完全终止了该过程。
因此，必须禁用ZGC的使用。 CRM系统的工作立即恢复正常。 似乎没有任何事情可做，我们将等到Oracle中的所有操作完成为止。
但是，过了一段时间，我
的一篇文章引起了我的注意，作者分享了使用另一个垃圾收集器-Shenandoah的积极经验，该开发者的目标完全相同，即：减少世界停止阶段进入垃圾收集器的时间。
我们决定：为什么不呢？
找到可以从中下载预编译的JDK的页面-https:
//builds.shipilev.net/之后 ，我们开始测试：我们向standalone.conf添加新密钥：
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
这次，测试表明，总体而言，一切正常。 并且减少了垃圾回收的暂停，最重要的是，停止了不可预知的内存消耗增加。 一切工作在生产中都完美无缺。
可以得出什么结论？ 我知道Oracle也在发展，我们在2019年10月遇到的困难可能已经解决，ZGC很快将获得第二次机会。 但是目前，我们个人选择了谢南多厄GC，对此并不后悔。