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），附加到主异常上，而不是覆盖它。

立即学习“Java免费学习笔记（深入）”；

• 调用方拿到的是 try 块的原始异常，可通过 e.getSuppressed() 查看被压制的关闭异常
• 这样既保证了资源关闭，又没丢掉真正出问题的上下文
• 比如数据库查询失败 + 连接池归还失败，两个问题都能追溯

资源必须实现 AutoCloseable 接口

只有实现了该接口的对象才能被 try-with-resources 管理，因为 JVM 依赖其 close() 方法完成释放动作。

• 标准库中 Connection、Statement、ResultSet、Socket、FileInputStream 等都已实现
• 自定义类只需重写 public void close() throws Exception 即可接入
• close() 方法内部应尽量避免再抛新异常，或至少做好日志记录，防止压制后无法排查