使用 bufferedoutputstream 包装 zipoutputstream 不能降低 gc 频率，反而增加内存压力；应直接使用 zipoutputstream，复用实例与缓冲数组，禁用冗余元数据，并用 try-with-resources 显式关闭。
用 BufferedOutputStream 包装 ZipOutputStream 本身**不能降低 GC 频率**，反而可能因多一层包装和额外缓冲区增加内存压力。真正有效的做法是绕过它，直接优化 ZipOutputStream 的缓冲行为和对象复用策略。
避免套用 BufferedOutputStream
ZipOutputStream 内部已经自带缓冲（默认 512 字节），且其 write() 方法会批量处理字节、延迟写入底层流。再套一层 BufferedOutputStream 不仅冗余，还会额外分配一个 8KB 缓冲区（默认大小），造成无谓的堆内存占用和后续 GC 压力。
- 不要这样写：
new BufferedOutputStream(new ZipOutputStream(outputStream)) - 应该直接使用：
new ZipOutputStream(outputStream) - 如需更大缓冲，改用带 buffer 参数的构造函数：
new ZipOutputStream(outputStream, new byte[64 * 1024])
复用 ZipOutputStream 和缓冲字节数组
频繁创建 ZipOutputStream 实例（尤其在循环压缩多个文件时）会快速产生短生命周期对象，触发 Young GC。应复用实例，并手动管理底层缓冲区。
- 在单次压缩任务中，只创建一次
ZipOutputStream - 用
closeEntry()和putNextEntry()切换条目，避免反复 new - 对每个待写入的文件块，复用同一块字节数组（如
byte[] buf = new byte[64 * 1024]），避免每次read()都分配新数组
禁用 ZIP 文件注释与冗余字段
ZipOutputStream 默认为每个条目写入额外元数据（如 DOS 时间戳、CRC 校验、可选注释）。这些虽小，但在高频小文件压缩场景下会累积大量临时对象（如 String、Date、byte[]）。
- 调用
setMethod(ZipOutputStream.STORED)或DEFLATED后显式控制 - 避免调用
setComment()，或传入null - 用
ZipEntry.setTime(0)统一设时间为 0，跳过TimeUtil中的格式化逻辑
用 try-with-resources + close() 显式释放资源
ZipOutputStream 持有 native 资源（如 Deflater），若未及时关闭，会导致 Deflater 实例无法回收，间接拖慢 GC 对关联 Java 对象的清理。
- 务必用
try (ZipOutputStream zos = new ZipOutputStream(...)) { ... } - 不要依赖 finalize ——
Deflater的 finalizer 已被标记为 deprecated - 关闭后，
zos实例可被快速回收，减少老年代晋升风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
