try-with-resources 与 @Cleanup 不等价：前者是 JVM 原生保障的资源管理机制，支持异常抑制和多资源自动关闭；后者仅为编译期生成 finally 调用 close 的语法糖，不校验方法存在性、不处理异常覆盖、不支持多资源声明。
Java 中 `try-with-resources` 和 Lombok 的 `@Cleanup` 注解**不是等价替代关系**，它们解决的问题相似（自动释放资源），但**机制、适用范围和安全性完全不同**。`@Cleanup` 并不能真正“代替” `try-with-resources`，尤其在关键资源管理场景中。 下面从原理和实践角度讲清楚两者的区别与使用边界：
本质区别：编译期插入 vs JVM 原生保障
@Cleanup 是 Lombok 在编译期生成 finally 块调用 close()（或指定方法），属于“手动 close 的语法糖”。
try-with-resources 是 JVM 层面的规范支持，要求资源实现 AutoCloseable，且在异常情况下仍能保证 close() 被调用（包括 try 块抛出异常、close() 自身抛异常时的 suppressed exception 机制）。
@Cleanup 的局限性很明确
-
不检查资源类型：即使对象没有
close()方法，Lombok 也会强行生成调用，编译通过但运行时报NoSuchMethodException -
不处理多异常场景：如果
close()抛异常，会覆盖 try 块中的原始异常，丢失根本原因（而try-with-resources会把 close 异常作为 suppressed exception 附加） -
不支持多资源声明：每个
@Cleanup只绑定一个变量，嵌套写法易出错，可读性差 -
无法用于 catch/finally 后续操作：资源作用域仅限于声明位置到方法结束，不能像
try-with-resources那样精确控制生命周期
什么时候可以谨慎用 @Cleanup？
仅适用于：非关键、无异常风险、且确定有 close() 方法的简单资源，比如某些测试工具类、内存型缓冲器（如 ByteArrayInputStream）、或你完全掌控的轻量级封装类。
例如：
@Cleanup OutputStream os = new FileOutputStream("tmp.txt");
os.write("hello".getBytes()); // 编译后自动加 finally { if (os != null) os.close(); }
但这仍是“能用，不推荐”的做法——尤其在生产代码中，应优先选 try-with-resources。
正确迁移建议：别替换，该用还用 try-with-resources
- 所有实现
AutoCloseable的标准资源（FileInputStream、Connection、PreparedStatement等）必须用try-with-resources - 若嫌写法啰嗦，可配合 Lombok 的
@SneakyThrows简化异常处理，但不替代资源管理语义 - 自定义资源类务必实现
AutoCloseable，并确保close()幂等、不抛受检异常（或用RuntimeException包装）
不复杂但容易忽略：`@Cleanup` 是便利性工具，不是资源安全的解决方案。Java 的 `try-with-resources` 是经过严格设计的语言特性，该坚持的地方不能妥协。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
