未关闭的InputStream不会直接导致Java堆内存泄漏，但会持续占用文件描述符，引发“Too many open files”异常及功能中断；应通过lsof和ulimit定位句柄耗尽，并用try-with-resources确保自动关闭。
未关闭的 InputStream 本身不会直接导致 Java 堆内存泄漏（如 OutOfMemoryError: Java heap space），但它会持续占用操作系统级的文件描述符（File Descriptor），而每个描述符背后都关联着内核资源和少量 JVM 堆外内存。当句柄数达到系统或进程限制时，就会抛出 java.io.IOException: Too many open files，进而引发功能中断、文件无法删除、HTTP 连接堆积等连锁问题。
识别句柄是否真的耗尽
先确认问题是否属于句柄泄露，而非其他资源瓶颈：
- 执行
ulimit -a | grep "open files"查看当前进程软限制（如 1024） - 用
lsof -p <pid> | wc -l</pid>统计该 Java 进程打开的句柄总数，对比是否接近软限 - 若远超软限，检查是否被调高过；若接近但未达，再查
cat /proc/sys/fs/file-max看是否触及全局限制 - 运行
lsof -p <pid> | awk '{print $5}' | sort | uniq -c | sort -nr | head -10</pid>查看高频句柄类型（如 REG、pipe、socket）
定位未关闭的 InputStream 代码位置
重点排查三类典型场景，它们在日志或堆栈中往往不显眼，但极易积累句柄：
-
XML/JSON 解析流：使用
DocumentBuilder.parse(is)、SAXParser.parse(is, handler)或ObjectMapper.readValue(is, ...)时，框架绝不会自动关闭传入的InputStream，必须由你托管生命周期 -
HTTP 响应体：用 Apache HttpClient 或 OkHttp 发起请求后，若只调用
response.getStatusLine().getStatusCode()却没消费response.getEntity().getContent()或未调用response.close()，连接将卡在CLOSE_WAIT，底层 socket 句柄持续占用 -
循环读取多个文件：比如定时任务扫描目录下所有 XML 并解析，每次新建
FileInputStream后未关闭，几十次后就突破千句柄限制
修复：用 try-with-resources 彻底接管生命周期
这是最可靠、最简洁的修复方式，JDK 7+ 全面支持，且能覆盖所有异常路径：
- 确保
InputStream实例声明在try ( )括号内，且为 final 或“有效 final” - 包装流（如
BufferedInputStream、ObjectInputStream）只需关闭最外层，内部会逐级委托关闭 - 避免手动调用
close()—— 即使它幂等，重复关闭或跨方法误关都会暴露职责混乱 - 示例（安全解析 XML）：
try (InputStream is = new FileInputStream("config.xml")) {
Document doc = DocumentBuilderFactory.newInstance()
.newDocumentBuilder().parse(is);
// 后续处理 doc
}
兜底与验证
上线前建议加一层防御性检查：
- 在关键流创建处打日志（如 “Opening config stream for ${fileName}”），配合关闭日志（“Closed stream for ${fileName}”），便于比对漏关
- 用
jstack <pid></pid>抓线程快照，搜索FileInputStream、SocketInputStream等关键词，看是否有大量处于 RUNNABLE 但长期未释放的对象 - 压测时监控
/proc/<pid>/fd/</pid>目录下文件数变化趋势，确认增长是否收敛
