未关闭的流不导致Java堆内存泄漏，但会持续占用操作系统文件描述符（fd），引发“Too many open files”等系统级异常；必须用try-with-resources或finally显式关闭，GC无法自动释放fd。
从物理垃圾回收视角看，未关闭的流资源（如 FileInputStream、BufferedReader、Socket 等）之所以构成高能隐患，并非因为它们本身占多少内存，而是因为它们在底层操作系统层面持有了**真实、不可被 GC 触及的物理资源句柄**（如文件描述符 fd、socket 句柄、内存映射地址等），而 JVM 的垃圾回收器只能管理堆内对象——它“看不见”这些外部资源。
流对象是假轻量、真锚点
表面上，一个 FileInputStream 实例只占几百字节堆内存，是个“小对象”。但它内部封装了一个由 JVM 通过 JNI 调用系统 open() 分配的文件描述符（fd）。这个 fd 是操作系统内核维护的全局资源表中的一个整数索引，属于进程级物理资源。只要该流对象还被任何强引用链可达，JVM 就不会将其判定为垃圾；更关键的是：即使它被判定为垃圾，JVM 的 GC 也默认不自动释放 fd——除非该流重写了 finalize() 或使用了 Cleaner 机制（且该机制触发时机不确定、不可靠）。
它悄悄变成隐藏根（Hidden Root）
所谓“根引用”，指 GC 判定对象存活的起点，比如栈帧里的局部变量、静态字段、JNI 全局引用等。未关闭的流往往被无意中“钉”在以下位置，形成隐性根：
- 被某个长期存活的对象（如单例 Service、静态缓存 Map、线程局部变量
ThreadLocal）持有引用 - 被匿名内部类或 Lambda 捕获，导致外层对象无法被回收（闭包延长生命周期）
- 在 try-with-resources 外裸写
new FileInputStream(...)，且后续逻辑抛异常跳过 close，引用仍在作用域内
后果不是 OOM，而是系统级枯竭
堆内存可能很充裕，但系统 fd 数量是硬限制（Linux 默认通常 1024 或 65536）。每漏关一个流，就消耗一个 fd。当 fd 耗尽时：
- 新文件打不开 →
IOException: Too many open files - 新网络连接失败 →
java.net.SocketException: No file descriptors available - JVM 自身也可能卡在类加载、日志写入等依赖 fd 的环节
这类错误不会触发 Full GC，也不会报 OutOfMemoryError，GC 日志里一切正常，但应用已实质瘫痪——这是典型的“GC 无感型故障”。
真正可靠的破局方式只有显式切断
不能依赖 GC，必须主动断开与物理资源的绑定：
- 严格使用
try-with-resources：编译器会确保close()在异常/正常路径下均执行 - 若无法用 try-with-resources（如流由工厂创建、生命周期跨方法），务必在 finally 块中判空调用
close() - 避免在流对象上做长生命周期引用；不要把它塞进静态容器或缓存
- 必要时可借助
Cleaner（Java 9+）注册清理动作，但仅作兜底，不可替代显式 close
