相关疑难解决方法(0)

我对java.util.zip图书馆有一些一般性的问题.我们基本上做的是导入和导出许多小组件.以前,这些组件是使用单个大文件导入和导出的,例如:

<component-type-a id="1"/>
<component-type-a id="2"/>
<component-type-a id="N"/>

<component-type-b id="1"/>
<component-type-b id="2"/>
<component-type-b id="N"/>

请注意,导入期间组件的顺序是相关的.

现在每个组件都应该占用自己的文件,该文件应该是外部版本的,QA-ed,bla,bla.我们决定导出的输出应该是一个zip文件(包含所有这些文件),我们导入的输入应该是一个类似的zip文件.我们不想在我们的系统中爆炸zip.我们不希望为每个小文件打开单独的流.我目前的问题:

Q1.可以ZipInputStream保证zip条目(小文件)的读取顺序与我们使用的导出插入的顺序相同ZipOutputStream吗？我认为阅读是这样的:

ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
ZipEntry entry;
while((entry = zis.getNextEntry()) != null) 
{
       //read from zis until available
}

我知道中央zip目录放在zip文件的末尾但是内部的文件条目有顺序.我也知道依靠订单是一个丑陋的想法,但我只想记住所有的事实.

Q2.如果我使用ZipFile(我更喜欢),呼叫getInputStream()数百次会对性能产生什么影响？它会比ZipInputStream解决方案慢得多吗？拉链只打开一次ZipFile并由后备RandomAccessFile- 这是正确的吗？我认为阅读是这样的:

ZipFile zipfile = new ZipFile(argv[0]);
Enumeration e = zipfile.entries();//TODO: assure the order of the entries
while(e.hasMoreElements()) {
        entry = (ZipEntry) e.nextElement();
        is = …

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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