stream.onclose() 仅对可关闭流（如files.lines()）有效，需配合try-with-resources或显式close()才能触发回调；普通集合流不支持，且重复调用会覆盖前一个回调。
Stream.onClose() 是 Java 8+ 中为流（Stream）提供的一种“注册关闭钩子”的机制，但它**本身不会自动触发关闭**，也不适用于所有流类型——尤其要注意：它只对**可关闭的流（如 Files.lines()、BufferedReader.lines() 等底层封装了资源的流）有效，且必须配合 try-with-resources 或显式调用 close() 才会执行。
哪些流支持 onClose() 并真正需要它？
典型场景是读取文件时返回的流，例如：
-
Files.lines(Path)→ 底层打开FileChannel或InputStream new BufferedReader(new FileReader("x.txt")).lines()-
new FileInputStream("x.bin").channel().map(...)（需自行包装为流）
这些流实现了 AutoCloseable，其 onClose(Runnable) 注册的回调会在流被关闭时执行。但普通集合流（如 list.stream()）不持有资源，onClose() 注册后也不会被调用——无实际意义。
正确用法：必须搭配 try-with-resources 或手动 close()
仅调用 stream.onClose(() -> ...) 不会触发清理。你必须确保流最终被关闭：
- ✅ 推荐：用
try-with-resources（最安全） - ✅ 显式调用
stream.close()（注意流只能关闭一次） - ❌ 忘记关闭、或仅消费完流未 close → 回调不执行，文件句柄泄露
示例（安全写法）：
try (Stream<string> lines = Files.lines(Paths.get("data.txt"))) {<br> lines.onClose(() -> System.out.println("文件已释放"))<br> .filter(s -> s.contains("ERROR"))<br> .forEach(System.out::println);<br>} // ← 自动调用 close()，触发 onClose 回调<br></string>
onClose() 的局限与替代方案
onClose() 是单次、不可叠加的（重复调用会覆盖前一个），也不支持异常处理。更健壮的做法是：
- 优先使用
Files.lines()+ try-with-resources（JDK 已内置资源管理） - 若需自定义清理逻辑，把资源封装成独立的
AutoCloseable类，而非依赖流的onClose() - 对复杂 I/O 流链（如压缩、加密），用
StreamSupport.stream(Spliterator, false)自行控制生命周期
例如，避免直接在流上拼接多个 onClose()，而应统一在资源对象的 close() 中处理所有释放逻辑。
验证是否真的释放了文件句柄
开发阶段可用工具辅助检测：
- Linux/macOS：
lsof -p <pid> | grep "data.txt"</pid> - Windows：
handle.exe -p <pid> | findstr "data.txt"</pid>（需 Sysinternals） - JVM 内部：启用
-Djdk.nio.maxCachedBufferSize=0减少缓冲区缓存干扰
关键观察点：流消费完毕且 try 块退出后，句柄应消失。若仍存在，说明未正确关闭流（或底层资源被意外持有）。
