Java DeflaterOutputStream.finish 怎样保留底层流继续写

我第一次把压缩数据嵌进自定义协议时，真正容易踩坑的不是压缩算法，而是流的所有权：当前压缩段已经写完，协议后面还要继续写控制字段，结果一调用 close()，底层输出流也一起关了。这个场景应该调用 DeflaterOutputStream.finish()，让压缩层把尾部数据写完，但把底层 OutputStream 留给后续内容。

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

一句话记忆：finish() 是“结束当前压缩数据”，flush() 是“尽量推出缓冲”，close() 是“结束压缩并关闭底层流”。

finish 和 close 的职责不是一回事

Oracle API 对 finish() 的定义很明确：它完成压缩数据写入，但不关闭底层流；close() 则会写出剩余压缩数据并关闭底层流。FilterOutputStream.close() 还会先刷新自身，再调用底层流的 close()，所以两者不能按“哪个更彻底就用哪个”来替换。

对我来说，判断标准只有一个：当前压缩段结束后，底层流是否还要承载别的内容。要继续写，就用 finish()；整个消息或文件已经结束，才让 close() 负责最终收口。

需要复用底层流时，先把所有权分开

构造函数接收外部 Deflater 时，压缩流关闭后并不会替调用方关闭这个压缩器；官方文档把它的生命周期责任交回调用方。下面的写法把底层流、压缩流和压缩器分成三个对象，读代码时不容易把“完成一段数据”和“释放全部资源”混在一起。

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.zip.Deflater;
import java.util.zip.DeflaterOutputStream;

public final class CompressedPartWriter {
    public static byte[] writeTwoParts() throws IOException {
        ByteArrayOutputStream sink = new ByteArrayOutputStream();
        Deflater deflater = new Deflater(Deflater.DEFAULT_COMPRESSION);
        DeflaterOutputStream compressed = new DeflaterOutputStream(sink, deflater);
        try {
            // 当前压缩段只写入业务正文，写完后由 finish 生成压缩尾部。
            compressed.write("正文片段".getBytes(StandardCharsets.UTF_8));
            compressed.finish();

            // finish 没有关闭 sink，因此底层流仍可写入下一段协议内容。
            sink.write("|metadata".getBytes(StandardCharsets.UTF_8));
            return sink.toByteArray();
        } finally {
            // finish 之后不再需要压缩层；外部 Deflater 由调用方显式释放。
            compressed.close();
            deflater.end();
        }
    }
}

这个例子里的 close() 仍然会调用底层流的关闭逻辑，因此它适合放在所有底层写入都结束之后。若底层是网络连接、响应输出流或由上层统一管理的包装流，实际项目通常会让上层负责最后关闭，并避免在中间层随意调用压缩流的 close()。

连续写多段时，finish 只标记当前压缩边界

finish() 不是“把底层流变成可无限追加的压缩文件”这个抽象承诺，它只完成当前 DeflaterOutputStream 的压缩输出。后续字节是否能被接收方正确解释，取决于你的协议是否定义了分段边界，以及接收端是否按同样的格式读取。

如果确实需要多个独立压缩段，可以在同一个底层流上为每段创建新的压缩层；每段完成后调用对应实例的 finish()，再写入下一段的头或数据。不要在同一个已经 finish() 的压缩实例上继续假设它会产生一个新的独立成员。

flush、finish、close 怎么放进回归检查

flush() 解决的是缓冲输出，不等于压缩数据已经结束。构造 DeflaterOutputStream 时若启用 syncFlush，刷新还会使用 Deflater.SYNC_FLUSH 推出当前待处理数据；这适合需要及时可见的流式场景，但仍不能替代最终的 finish()。

迁移或修复时，我会固定检查三件事：第一，调用 finish() 后底层流还能否写入协议尾部；第二，接收端能否按约定识别压缩段完整边界；第三，外部创建的 Deflater 是否最终执行了 end() 或 close()。如果底层流的关闭权属于上层，就不要为了“保险”在中间层调用 compressed.close()。

因此，标题中的问题可以落成一个很窄的迁移规则：把中间压缩段的 close() 改成 finish()，把底层流和外部 Deflater 的最终释放交给真正拥有它们的那一层。

相关问题

finish 后还能继续调用 write 吗？不要把同一个压缩实例当成新的独立压缩段继续使用；需要新的段时创建新的压缩层，并让协议定义清楚边界。

只调用 flush 能代替 finish 吗？不能。flush 关注缓冲可见性，finish 负责结束压缩数据，两者目的不同。