sequenceinputstream不会自动关闭上游流，导致文件句柄持续占用而引发“too many open files”异常；它仅顺序读取，不管理底层流生命周期，须显式关闭各输入流。
Java中SequenceInputStream在合并多个大日志文件时，**不会主动释放已读完的输入流所占用的文件句柄**，容易导致“Too many open files”异常。
为什么SequenceInputStream会持续占用文件句柄
SequenceInputStream本质是按顺序串联多个InputStream，但它**不负责关闭上游流**——它只在当前流读到末尾后，自动切换到下一个流，但前一个流对象仍处于打开状态，除非你显式调用close()。而JVM不会自动回收未关闭的文件句柄，尤其在处理几十个上百MB的日志文件时，句柄数快速累积。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
典型问题场景
- 用
new SequenceInputStream(Collections.enumeration(inputStreamList))一次性构造合并流，但后续只对SequenceInputStream调用close()→ 所有底层FileInputStream依然打开 - 流列表中混用
BufferedInputStream、GZIPInputStream等装饰器 → 关闭逻辑更复杂，易遗漏底层原始流 - 日志归档脚本循环处理数百个文件，每次新建
SequenceInputStream但未清理旧资源 → 句柄泄漏随时间恶化
安全替代方案（推荐）
避免直接依赖SequenceInputStream，改用更可控、资源明确的组合方式：
-
手动轮询 + 显式关闭：遍历每个
FileInputStream，读完立即close()，用try-with-resources确保释放 -
使用Apache Commons IO的
SequenceInputStream增强版（如org.apache.commons.io.input.SequenceInputStream），它支持传入Closeable集合，并在自身close()时批量关闭所有成员 -
改用NIO.2的
Files.lines()+Stream.concat()：适合纯文本日志合并，底层由JVM管理通道，无显式句柄暴露；注意需用onClose()注册清理逻辑 - 分块流式拼接（推荐用于超大文件）：不一次性加载全部流，而是维护一个流迭代器，每次只打开当前待读文件，写入后立刻关闭，内存和句柄都可控
关键实践提醒
无论采用哪种方式，牢记两点：
- 每个
FileInputStream必须且仅被关闭一次；重复close()无害，但漏关必出问题 - 不要依赖
finalize()或GC回收文件句柄——它们与垃圾回收无关，必须显式释放 - Linux下可通过
lsof -p <pid></pid>实时观察Java进程打开的文件数，验证是否泄漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
