java - JAR 中 InputStream 的不同行为

Question

我发现自己要解决软件中的一个奇怪错误:问题是只有当我将应用程序打包到可运行的 JAR 中时它才会出现。

问题出在这个简单的代码中:我添加了 loopCounter 来计算循环次数

private static byte[] read(InputStream source) {
    ByteArrayOutputStream out = new ByteArrayOutputStream();
    int loopCounter = 0;
    int bytesRead;

    try {
        byte[] buffer = new byte[4096]; 

        while ((bytesRead = source.read(buffer)) != -1) {
            out.write(buffer, 0, bytesRead);
            loopCounter++;
        }

    } catch (IOException e) {
        e.printStackTrace();
    }

    return out.toByteArray();
}

一个例子:

source = ClassLoader.class.getResourceAsStream("file.lol");

loopCounter in Eclipse = 1366
loopCounter in JAR     = 1405

我的问题是:为什么相同的 InputStream 会出现这种显着差异？

编辑:我用正确的代码更改了我的代码，但循环计数器仍然不同。

Answer 1

InputStream.read() 不能保证一次填满整个缓冲区，因此您需要跟踪实际读取的字节数:

byte[] buffer = new byte[4096];
int bytesRead = 0;
while ((bytesRead = source.read(buffer)) != -1) {
    out.write(buffer, 0, bytesRead);
    loopCounter++;
} 

因此，对于 InputStream 的不同实现，每次迭代读取的字节数可能会有所不同也就不足为奇了，因此迭代次数也可能会有所不同。

实际上，InputStream.read() 的特定调用读取的字节数取决于很多因素。

第一个因素是 InputStream 的实现:当您从 Eclipse 运行应用程序时，您使用 InputStream 直接从文件系统读取资源，而当您运行它时从 jar 文件中，您使用 InputStream 从 jar 文件中提取资源。显然，jar 文件解压缩算法的一些内部结构可能会影响您获得的 block 的大小。

另一个因素是底层环境的行为。例如，从文件系统读取文件的系统调用也可能返回不同大小的 block ，这取决于操作系统的某些内部行为等。