try-with-resources仅在try块结束时自动关闭短生命周期资源，不参与JVM关闭阶段的Shutdown Hook执行；后者专用于清理跨业务生命周期的全局资源，二者职责分离、不可替代。
try-with-resources 本身不参与 Shutdown Hook 的执行，它只在对应 try 块结束时自动触发 close()；Shutdown Hook 是 JVM 关闭前的独立线程，两者运行时机、作用域和责任边界完全不同。想靠 try-with-resources 替代或简化 Shutdown Hook 中的资源清理，容易误判场景、遗漏关键资源。
try-with-resources 的适用边界很明确
它专用于“业务逻辑执行过程中打开、使用并及时释放”的短生命周期资源，比如读一个配置文件、查一次数据库、处理一段网络响应流。这些资源的生命周期由代码块控制，与 JVM 生命周期无关。
- 资源必须在 try 括号内声明，且实现 AutoCloseable
- 关闭发生在 try 块退出时（正常结束或异常抛出），不是 JVM 退出时
- 多个资源按声明逆序关闭，close() 异常会被抑制，不干扰主异常
- 无法覆盖全局单例、静态连接池、长期运行的线程池等长生命周期资源
Shutdown Hook 要处理的是“跨业务生命周期”的资源
Shutdown Hook 执行时，业务逻辑早已停止，主线程可能已退出，此时真正需要清理的是那些脱离局部作用域、被长期持有或共享的资源——它们根本不在任何 try-with-resources 作用范围内。
- 数据库连接池（如 HikariCP）：需显式调用 close() 或 shutdown()
- Netty 或 Tomcat 的 ServerBootstrap / ServletWebServerFactory：需触发 graceful shutdown
- 自定义线程池（ExecutorService）：应调用 shutdown() + awaitTermination()
- 本地缓存（如 Caffeine）：需 flush 或 persist 状态
- 共享内存映射文件（MappedByteBuffer）：需 force() + clean()（注意 Unsafe 使用限制）
二者协同而非替代：分层清理更可靠
真正的稳健实践是让 try-with-resources 负责“每次调用内的资源”，Shutdown Hook 负责“整个应用生命周期的收尾”。两者分工清晰，才能避免重复或遗漏。
立即学习“Java免费学习笔记（深入）”；
- 业务方法中：用 try-with-resources 管理 Connection、PreparedStatement、InputStream 等，确保单次操作干净
- 应用启动时：初始化全局资源（如 DataSource、ThreadPoolTaskExecutor），并保存引用供钩子使用
- Shutdown Hook 中：只调用已初始化资源的 shutdown/close 方法，不做 new、IO、RPC 等耗时操作
- 关键资源建议加 volatile 标志位（如 isShuttingDown），让业务逻辑能快速感知并拒绝新请求
容易踩坑的典型误区
把 Shutdown Hook 当成“兜底 try 块”来写 try-with-resources，看似简洁，实则危险：
- 钩子里声明的资源（如 new FileInputStream(...)）可能因路径不存在、权限不足等提前失败，而钩子线程无上层 catch，失败无声
- 钩子执行时，类加载器可能已开始卸载，静态字段不可靠，依赖 Spring Context 的资源可能已销毁
- 多个钩子并发执行，若都尝试 close 同一个静态 Connection，可能引发 IllegalState 或重复关闭异常
- 钩子超时被 JVM 强制中断（如 Spring Boot 默认 30s），未完成的 try-with-resources 会直接丢弃，close() 不再保证执行
