Stream.onClose()不能替代try-with-resources，仅对显式close()的AutoCloseable流（如Files.lines）有效；必须手动调用close()或用try-with-resources包裹，且onClose()内禁止IO和耗时操作。
Stream.onClose() 不能替代 try-with-resources 管理外部资源
Stream.onClose() 只在调用 close() 时触发，而大多数标准流（如 Arrays.stream()、Stream.of()、Collection.stream()）**根本不会被关闭**——JVM 不会自动调用 close()，也不会在 GC 时回调 onClose()。它只对显式调用 close() 的流生效，比如 Files.lines() 或自定义的 AutoCloseable 流。
常见错误是写成这样，以为能释放资源：
Stream<string> s = Files.lines(Paths.get("log.txt")).onClose(() -> System.out.println("closed"));
// 忘记 s.close() → onCose 永远不执行，文件句柄泄漏</string>
- 必须手动调用
s.close()，或用try-with-resources包裹 -
onClose()注册的 Runnable 是「一次性」的：触发后即丢弃，重复close()不再执行 - 多个
onClose()调用会叠加，按注册顺序逆序执行（LIFO）
哪些 Stream 天然支持 onClose() 回收？
只有实现了 AutoCloseable 的流才真正需要并支持 onClose() 钩子，典型代表是：
-
Files.lines(Path)—— 底层打开文件通道，需释放 -
Files.walk(Path)—— 遍历目录树，持有多个系统句柄 - 自定义流：继承
AbstractStream或包装Iterator并实现AutoCloseable
例如正确用法：
try (Stream<string> lines = Files.lines(Paths.get("data.csv")).onClose(() -> log("file stream closed"))) {
lines.filter(s -> s.startsWith("2024")).count();
} // ← close() 自动触发，log 输出</string>
注意：onClose() 里抛出的异常会被压制（suppressed），不会中断主流程，除非你手动捕获处理。
onClose() 里不能做阻塞或耗时操作
onClose() 运行在调用 close() 的线程上，如果里面执行网络请求、数据库 commit 或 sleep，会拖慢整个资源释放路径，尤其在连接池、高并发场景下容易引发线程阻塞或超时。
- 适合做轻量清理：记录日志、重置标志位、释放内存引用（如 clear cache map）
- 避免 IO：不要在
onClose()里写文件、发 HTTP 请求、调用Thread.sleep() - 若必须异步清理，应启动新线程或提交到专用线程池，并确保不泄露线程引用
反例：
stream.onClose(() -> {
Files.write(Paths.get("cleanup.log"), "closed".getBytes()); // ← 同步 IO，可能失败且阻塞
});
替代方案：优先用 try-with-resources + 显式资源对象
比起依赖 onClose()，更可靠的方式是把资源本身作为 AutoCloseable 对象管理，流只是它的视图。例如封装一个带缓冲区的文件读取器：
class SafeFileReader implements AutoCloseable {
private final BufferedReader reader;
SafeFileReader(String path) throws IOException {
this.reader = Files.newBufferedReader(Paths.get(path));
}
Stream<string> lines() { return reader.lines(); }
public void close() throws IOException { reader.close(); } // 真正释放点
}</string>
然后这样用：
try (SafeFileReader r = new SafeFileReader("input.txt")) {
r.lines().filter(...).forEach(...);
} // ← close() 在这里执行，比 onClose() 更可控、可测试、易调试
onClose() 是流层面的补丁机制，不是资源生命周期管理的主干。真要回收资源，得从源头控制谁打开了它、谁负责关掉它。
