Java InflaterInputStream.available 为什么不能判断压缩流结束

如果你在 Java 压缩流代码里用 InflaterInputStream.available() 判断“还剩多少数据”，很容易得到错误结论。这个方法不是压缩数据长度查询接口：在没有到达 EOF 时通常返回 1，到达 EOF 后返回 0。真正表示读取结束的信号，是 read() 返回 -1。

官方 API 地址：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/zip/InflaterInputStream.html

生产代码应把 available() 当成可读性提示，而不是循环条件、剩余长度或压缩流完整性证明。下面从语义、资源边界、读取循环和排查记录四个方面拆开说明。

available() 返回值到底表示什么

InflaterInputStream 的 available() 实现非常保守：EOF 之前返回 1，EOF 之后返回 0。它并不告诉你解压后还剩多少字节，也不保证调用不会阻塞。

因此，下面这种写法把“是否可能继续读”和“是否已经读完”混成了一个判断，不能作为可靠的压缩流读取循环：

// 错误示例：available() 不是剩余字节数，不能用它控制解压循环
while (input.available() > 0) {
    output.write(input.read());
}

即使 available() 返回 1，下一次读取也可能需要等待底层输入；如果把它理解成“至少有一个字节已经准备好”，就会误判阻塞行为。相反，返回 0 也只说明流已经观察到 EOF，不能拿它推断压缩数据是否符合业务预期。

把 EOF 判断交给 read() 返回值

对于 InputStream 风格的读取，判断结束应围绕 read(buffer) 的返回值展开：

// 正确示例：以 read() 的实际返回值作为 EOF 判断
byte[] buffer = new byte[8192];
int total = 0;
int n;
while ((n = input.read(buffer)) != -1) {
    // n 只表示本轮有效字节数，不能把整个 buffer 都写出去
    output.write(buffer, 0, n);
    total += n;
}
// total 是已经解压并交给输出端的字节数，不是 available() 的结果
System.out.println("inflated bytes: " + total);

官方 API 对 read(byte[], int, int) 的定义是：返回本次实际解压的字节数，或在压缩输入结束时返回 -1。这个信号来自读取动作本身，所以既能驱动循环，也能让代码在阻塞读取完成后获得明确的结束状态。

用 try-with-resources 划清资源边界

压缩流通常包着文件流、网络响应流或其他输入流。读取逻辑修正后，还要保证异常和正常 EOF 都能释放资源。最小的生产写法可以把输入流、解压流和输出流一起放进 try-with-resources：

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.zip.InflaterInputStream;

static long inflateTo(InputStream compressed, OutputStream output) throws IOException {
    // try-with-resources 会在正常结束和异常退出时关闭解压流与输出流
    try (InputStream input = new InflaterInputStream(compressed);
         OutputStream target = output) {
        byte[] buffer = new byte[8192];
        long total = 0;
        int n;
        while ((n = input.read(buffer)) != -1) {
            // 只转发本次 read 返回的有效区间，避免写入旧数据
            target.write(buffer, 0, n);
            total += n;
        }
        return total;
    }
}

这里的资源顺序需要结合调用约定决定。如果调用方还要继续使用外部传入的 OutputStream，就不要在方法内部关闭它，可以让方法只管理自己创建的解压层，并在接口文档中写清所有权。示例展示的是“本方法完成后输出端也归本方法管理”的边界，实际项目不要含糊。

日志记录应该围绕什么证据

排查“压缩流没有读完”时，不要只打印 available()。更有用的记录包括：

• 输入来源的业务标识或安全的文件名，不要把凭据、完整本地路径和敏感请求头写进日志。
• 循环累计的解压字节数，以及最后一次 read() 返回的是 -1 还是抛出了异常。
• 异常类型和异常链，例如 IOException 或压缩格式相关的 ZipException。
• 输出端是否已刷新、关闭或回滚，避免把“写出失败”误判成“解压未结束”。

try {
    long bytes = inflateTo(compressed, output);
    // 记录可复核的业务结果，不把 available() 当作完整性指标
    logger.info("inflate finished, bytes={}", bytes);
} catch (IOException ex) {
    // 保留异常类型和上下文，交给上层决定重试、回滚或告警
    logger.warn("inflate failed for input {}", inputId, ex);
    throw ex;
}

如果业务还需要判断“是否完整”，应另外定义可核对的业务条件，例如已知的解压后长度、校验和或文件格式结束标记。available() 的 0/1 语义本身不能替代这些条件。

发布前的读取检查清单

1. 循环条件是否使用 read(buffer) != -1，而不是 available() > 0。
2. 写出时是否使用 buffer, 0, n，没有把整个缓冲区都写入。
3. 是否明确了输入流、解压流、输出流分别由谁关闭。
4. 是否区分正常 EOF、IOException 和业务完整性校验失败。
5. 日志是否只记录必要的输入标识、字节数和异常上下文。

一句话总结：available() 只适合做非常有限的可读性提示，不能作为压缩流剩余长度或结束判断；使用 read() 持续读取，直到返回 -1，再配合明确的资源所有权和业务完整性条件，才是稳定的实现。

相关问题

InflaterInputStream.available() 返回 1 是不是代表还有一个字节？

不是。它只表示在 EOF 前仍可能读取，返回值不是剩余字节数。

read() 返回 0 时应该结束循环吗？

对非零长度的正常阻塞读取，通常应继续按 API 合约处理；结束判断仍以 -1 为准，并应注意传入的长度不能为 0。

怎么判断解压结果真的完整？

把 EOF 作为流层结束，再用业务已知长度、校验和或格式层结束标记做第二层判断，不要用 available() 代替完整性校验。