固定CPU-java.util.zip.ZStreamRef问题

Question

我们在生产中看到了这个间歇性问题。 CPU随机固定为50％（2核CPU），并且永远不会恢复正常。唯一的选择是重新启动服务器。 这就是从Dynatrace中出现CPU的方式

这是我们通过dynatrace分析时线程转储的外观。

通过我的研究，似乎存在jdk缺陷

Calling 'java.util.zip.Deflater.finish()' prematurely hangs the application. 
The application is spinning consuming one cpu

https://bugs.openjdk.java.net/browse/JDK-8060193

仅在涉及多个过滤器时才随机发生。

我能够使用JDK“ 1.8.0_201”的CentOs vm在上面的jira中使用测试类重现此内容。 这令人惊讶，因为根据文档和票证，此问题已修复。

在进一步研究中，发现在jdk中再次打开类似的缺陷。

https://bugs.openjdk.java.net/browse/JDK-8193682

现在，除非有人可以复制它，否则团队不愿意对其进行处理。 由于它是在生产中随机发生的，因此我不确定如何复制它。 https://bugs.openjdk.java.net/browse/JDK-8060193中的测试类仍然存在问题。这甚至是一个有效的测试用例吗？ 如果这是有效的，那么每次我们发送压缩数据都会有问题。

• 我们的运行时JRE是Jdk 1.8
• 压缩是在tomcat上，而不是在负载均衡器上。

有关为什么会发生这种情况以及我们如何解决这个问题的任何指示？

Answer 1

正如我在之前的评论中所说，当我们尝试生成通过OutputStream写入HttpServletResponse的{​​{1}}中的Zip文件时，我们面临着这个问题。 / p>

内核以100％运行的原因是由于ZipOutputStream（{ZipOutputStream）和DeflaterOutputStream（closeEntry()和write()）中的三个（在某些条件下）无限循环。 这些无限循环看起来像这样：

finish()

while (!def.finished()) { deflate(); } 是def的地方。

如果我理解正确，这就是JDK-8193682中的问题。那里有一个解决方法类，它会覆盖java.util.zip.Deflater的{​​{1}}方法。

我将尝试使用基于该替代方法的类，该方法接受deflate方法中要检查的超时。我希望不要通过这种方法造成资源泄漏。

相关问题：Thread locking when flushing jsp file

Answer 2

我想发布此问题的更新，此问题困扰了我们很多年。我们正在进行一项将静态内容迁移到CDN的计划。在实施CDN并从其他服务器提供所有静态资源后，ZipStream问题得以解决。尽管研究表明问题更多是动态内容，而不是静态内容，但我不确定问题是如何解决的。也许正在阅读此答案的人可以向我解释此问题的解决方法。