try-with-resources通过JVM字节码强制保障资源关闭，无论正常结束、return或抛异常（含unchecked），均自动逆序调用AutoCloseable.close()，close异常被压制并附加到主异常中。
try-with-resources 能确保异常发生时资源仍被关闭，核心在于 JVM 的强制保障机制，不是靠开发者判断或手动补救。
资源关闭由JVM字节码层面强制执行
编译器会把 try-with-resources 语句重写为带隐式 finally 块的结构，在字节码中插入 close() 调用。无论 try 块是正常结束、return 提前退出，还是抛出任意异常（包括 unchecked 异常），这个关闭逻辑都会被执行。
- 不需要 catch 块存在，也不依赖 finally 手动写 close()
- 即使 throw new RuntimeException("业务炸了")，Connection 依然会被 close()
- 哪怕 JVM 遇到 OutOfMemoryError 这类严重错误，只要执行流能走到 try 块末尾，close 就会触发
多个资源按逆序关闭，且彼此独立
声明在 try 括号里的每个资源都单独参与关闭流程。后声明的资源先关闭，前声明的后关闭，且一个资源 close() 失败不会中断其他资源的关闭。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 例如：try(Connection c; PreparedStatement ps; ResultSet rs) → 关闭顺序是 rs → ps → c
- 如果 ps.close() 抛异常，rs 已关完，c 仍会继续关
- 这种设计避免因单个资源故障导致整个清理链路中断
异常压制机制保留原始错误现场
当 try 块抛出异常，同时某个 close() 也抛异常，JVM 会把 close 异常“压制”（suppressed），附加到主异常上，而不是覆盖它。
- 调用方拿到的是 try 块的原始异常，可通过 e.getSuppressed() 查看被压制的关闭异常
- 这样既保证了资源关闭，又没丢掉真正出问题的上下文
- 比如数据库查询失败 + 连接池归还失败，两个问题都能追溯
资源必须实现 AutoCloseable 接口
只有实现了该接口的对象才能被 try-with-resources 管理，因为 JVM 依赖其 close() 方法完成释放动作。
- 标准库中 Connection、Statement、ResultSet、Socket、FileInputStream 等都已实现
- 自定义类只需重写 public void close() throws Exception 即可接入
- close() 方法内部应尽量避免再抛新异常，或至少做好日志记录，防止压制后无法排查
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
