try-with-resources 仅适用于单线程局部作用域，多线程中应每线程独占资源并各自使用；Java 21+ 可结合 StructuredTaskScope 管理虚拟线程生命周期与资源，避免共享、重复关闭及线程安全问题。
Java 中 try-with-resources 本身不是为多线程共享资源设计的，它天然作用于**单线程、局部作用域内的资源生命周期管理**。直接在多个线程间共用同一个 try-with-resources 声明的资源（比如一个 FileInputStream 或 Connection），不仅违反语义，还会引发竞态、关闭冲突甚至 IllegalStateException。但你可以在多线程环境下“安全使用”它——关键是把“资源归属”和“线程边界”对齐。
每个线程独占一份资源，各自用各自的 try-with-resources
这是最常见也最推荐的方式。线程不共享资源实例，而是各自创建、使用、关闭。
- 例如：用线程池处理一批文件，每个任务单独打开并关闭自己的 FileInputStream 和 BufferedReader
- 数据库连接场景中，每个线程从连接池获取 Connection，再在 try-with-resources 中声明 PreparedStatement 和 ResultSet —— 它们属于该 Connection 的子资源，且只在当前线程内使用
- 避免把资源对象作为成员变量或静态变量跨线程传递；所有 AutoCloseable 实例应在 run() 或 call() 方法内部声明
配合结构化并发（Structured Concurrency）统一管理虚拟线程生命周期
Java 21+（Loom 特性正式落地）支持将 try-with-resources 扩展用于并发作用域管理，尤其适合大量短生命周期虚拟线程。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 使用 StructuredTaskScope（如 ShutdownOnFailure 或 ShutdownOnSuccess）作为可关闭资源
- scope.fork() 启动的子任务与 scope 绑定；try 块退出时自动 join + cancel 未完成任务，并释放其关联资源
- 示例中无需手动关闭线程或中断逻辑，JVM 确保超时/异常后所有派生虚拟线程被终止，底层 Socket、Channel 等也会随之关闭
避免在 finally 或线程终结钩子里重复 close
try-with-resources 已保证 close() 被调用，若再在线程 shutdown hook 或自定义清理逻辑中显式调用，可能触发 “already closed” 异常（如 SQLException: Connection is closed）。
立即学习“Java免费学习笔记（深入）”；
- 不要在 Thread.setUncaughtExceptionHandler 中尝试 close 当前线程使用的资源——资源已随 try 块结束而关闭
- 如果资源需跨线程传递（极少数场景，如异步回调），应改用 CloseableReference、AutoCloseable 包装器或 CompletableFuture.thenApplyAsync 配合独立 try-with-resources
- 检查资源实现是否幂等：部分 close() 实现有容错机制（如 Apache Commons IO 的 Closeables.closeQuietly），但标准 JDK 类一般不保证
注意资源本身的线程安全性
try-with-resources 不解决资源内部的线程安全问题。即使每个线程都有自己的 BufferedReader，若它包装的是共享的、非线程安全的 InputStream（如 ByteArrayInputStream 是安全的，但自定义的共享缓冲区流可能不是），仍可能出错。
- 确认底层资源是否允许多线程并发访问；否则应在业务层加锁或改用线程安全替代品（如 java.nio.channels.AsynchronousFileChannel）
- 像 java.sql.Connection 默认不是线程安全的，必须遵循“一个连接一个线程”原则
- BufferedWriter、PrintWriter 等字符输出流也不支持多线程写入，除非明确同步
