finally中close()不生效主因是其抛异常会覆盖原始异常或被忽略；应空检+捕获；try-with-resources更可靠，自动关闭且抑制异常；但JNI内存等非JVM资源需手动释放。
finally 块里调用 close() 为什么有时不生效
因为 close() 方法本身可能抛出异常，如果 try 块中已发生异常，finally 中再抛异常会覆盖原始异常，导致资源看似“没释放”——实际是 close() 执行了但被吞掉或掩盖。更关键的是，若 close() 抛出 IOException 而你没捕获，JVM 不会阻止程序继续，但资源状态可能已损坏（如文件句柄未真正释放）。
实操建议：
- 在
finally中对close()做空指针检查和异常捕获，例如：if (inputStream != null) { try { inputStream.close(); } catch (IOException ignored) {} } - 避免在
finally里写业务逻辑或可能阻塞的操作（如网络请求），否则会拖慢异常传播甚至引发死锁 - 不要在
finally里用return，它会直接结束方法，导致try或catch中的return失效
Java 7+ 的 try-with-resources 比 finally 更可靠吗
是的，只要资源类型实现 AutoCloseable 接口（如 FileInputStream、BufferedReader、Connection），try-with-resources 就会在语句结束时自动调用 close()，且保证即使构造资源时抛异常、或 try 块中抛异常，close() 仍会被调用。
关键差异：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
try-with-resources的资源声明必须在括号内完成，且变量隐式为final；不能在外部初始化后传入 - 多个资源用分号分隔，关闭顺序与声明顺序相反（后声明的先关闭），这对有依赖关系的资源很重要（如先关
BufferedWriter再关FileOutputStream） - 如果
close()抛异常，它会被抑制（suppressed），可通过Throwable.getSuppressed()获取，原始异常仍是主异常
哪些资源不能靠 finally 或 try-with-resources 自动释放
非 JVM 管理的资源，比如通过 JNI 调用的本地内存、显式申请的 DirectByteBuffer（ByteBuffer.allocateDirect()）、第三方库持有的 GPU 显存、或自己用 Unsafe 分配的堆外内存——这些不会被 GC 自动回收，也不响应 close()。
常见误判场景：
-
Socket或ServerSocket：虽实现了AutoCloseable，但若底层文件描述符已被操作系统回收（如对方断连后你又调一次close()），close()可能静默失败，需配合isClosed()和超时机制判断 - 数据库连接池中的
Connection：调用close()实际是归还连接，不是销毁；若忘记close()，只是连接泄漏，不是立即 OOM，但最终耗尽连接池 - Logback / SLF4J 的
LoggerContext：需显式调用stop()，否则日志线程和 appenders 不会释放
自定义资源类怎么正确支持 try-with-resources
必须实现 AutoCloseable 接口，并在 close() 方法中完成所有清理动作。重点不是“能不能编译”，而是“是否幂等、是否线程安全、是否处理了嵌套资源”。
典型陷阱：
-
close()方法不应抛出受检异常（Exception），只能抛IOException或运行时异常；否则无法用于 try-with-resources - 若你的类持有其他
AutoCloseable成员，close()必须按依赖顺序依次关闭它们，并对每个调用做null检查和异常捕获（防止一个失败中断后续关闭） - 关闭后应将关键字段置为
null或标记为closed，避免重复关闭导致IllegalStateException
finally 或加 try-with-resources，而是厘清资源生命周期边界——比如一个 Connection 是由 DAO 创建还是由 Service 传递进来？谁负责关闭？这个责任链一旦错位，任何语法糖都救不了。 
