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.netbrowseJDK-8060193。

只有在涉及多个过滤器时才会随机发生。

我能够在CentOs vm上使用上述jira中的测试类重现这个问题，而CentOs vm的JDK为 "1.8.0_201"，这让我很惊讶，因为根据文档和票据，这个问题已经被修复了。

在进一步的研究中，发现类似的缺陷又在jdk中出现了。

https:/bugs.openjdk.java.netbrowseJDK-8193682。

现在团队不愿意去做这个工作，除非有人能重现这个情况。测试类从 https:/bugs.openjdk.java.netbrowseJDK-8060193。 仍然有问题。这是一个有效的测试案例吗？如果这是有效的，那么每次我们发送压缩数据时都会出现问题。

• 我们的运行时间JRE是Jdk 1.8。
• 压缩是在Tomcat，而不是在负载平衡器。

有什么建议可以告诉我们为什么会发生这种情况，我们如何解决这个问题？

更新:在我们正在使用的一个库中，它正在抛出一个异常。畸形的UTF-8字符(意外的非连续性字节0x00，紧接在起始字节0xfd之后)

LastName, First'Name我们可以看到，这不是一个普通的撇号.我们可以通过复制粘贴从word中自动纠正一个普通的撇号到这个时髦的字符。

我们的复制器确实抛出了一个错误，但CPU并没有被卡住。我想这是在高容量和高流量的情况下发生的。

Answer 1

我想发布一个更新的问题，这个问题已经困扰了我们多年。我们有一个倡议，将静态内容迁移到CDN进行中。在CDN实施后，所有的静态资源都从不同的服务器上提供服务，ZipStream的问题得到了解决。虽然研究表明问题更多的是针对动态内容，而不是静态内容，但我不清楚问题是如何解决的。也许看到这个答案的人可以给我解释一下这个问题是怎么解决的。