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

Question

我们在生产中看到了这个间歇性问题。CPU 随机固定在 50%（2 核 CPU），并且永远不会回来。唯一的选择是重新启动服务器。\n这就是 Dynatrace 中 CPU 的显示方式

\n\n

\n这就是我们通过 dynatrace 分析时线程转储的样子。

\n\n

\n\n

\n\n

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

\n\n

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

\n\n

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

\n\n

仅当涉及某些多个过滤器时才会随机发生。

\n\n

我能够在具有 JDK“1.8.0_201”的 CentOs 虚拟机上使用上述 jira 中的测试类来重现此问题\n这令人惊讶，因为根据文档和票证，此问题已得到修复。

\n\n

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

\n\n

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

\n\n

现在团队不愿意继续研究它，除非有人可以重现它。\n由于它是在生产中随机发生的，我不确定如何重现它。https://bugs.openjdk.java.net/browse/JDK-8060193中的测试类仍然存在问题。这是否是一个有效的测试用例？\n如果这是有效的，那么每次我们发送压缩数据时都会出现问题。

\n\n

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

\n\n

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

\n\n

更新：\n在我们正在使用的库之一中，它抛出异常\n格式错误的 UTF-8 字符（意外的非连续字节 0x00，紧接在起始字节 0xfd 之后）

\n\n

LastName, First\xe2\x80\x99Name\n正如我们所见，这不是一个常规的撇号。我们可以通过从 word 中复制粘贴来实现这一点，它会自动将常规撇号更正为这个时髦的字符。

\n\n

我们的重现器确实抛出了一个错误，但 CPU 并没有卡住。我认为这是在高流量和流量的情况下发生的。

\n

Answer 1

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