jdbc规范明确要求connection线程不安全，多线程共享会导致事务混乱、resultset异常及底层协议错乱；正确做法是每个线程独享连接，通过连接池按需获取并及时释放，必要时用threadlocal绑定同一线程内事务一致性。
Java JDBC 中的 Connection 对象本身不是线程安全的，JDBC 规范明确要求其实现类无需支持多线程并发访问。因此，在多线程环境下直接共享一个 Connection 实例会导致事务混乱、状态错乱甚至连接中断。安全使用的根本原则是：**每个线程应独享自己的 Connection 实例，且生命周期严格受控。**
用连接池按需获取，不用静态或单例 Connection
避免将 Connection 声明为 static 或作为 Spring Bean 单例注入。这类做法会让多个线程争抢同一连接，引发如下问题：
- 线程 A 设置
setAutoCommit(false)开启事务，线程 B 紧接着调用commit()，导致 A 的事务被意外提交 - 线程 A 正在读取
ResultSet，线程 B 调用close()，A 随即抛出SQLException: Operation not allowed after ResultSet closed - 底层驱动（如 MySQL Connector/J）的 Socket 通道和协议状态机非线程安全，共享连接可能造成字节流错乱或静默断连
正确做法是通过连接池（如 HikariCP、Druid）每次需要时调用 dataSource.getConnection() 获取新连接，用完立即释放。
用 ThreadLocal 绑定线程内连接（适用于事务贯穿场景）
当一个业务操作需跨多个 DAO 方法、且必须保证在同个事务中执行时，可借助 ThreadLocal 实现连接在线程内的“绑定-复用-解绑”：
- 在请求入口（如 Filter、Spring 拦截器或 AOP 切面）中检查
ThreadLocal.get()，为空则从连接池获取并set() - DAO 层统一通过该
ThreadLocal实例获取连接，确保所有 SQL 在同一事务上下文中执行 - 请求结束前（
finally或afterCompletion）必须调用remove()，否则在线程池复用场景下会残留旧连接，引发泄漏或事务污染
注意：ThreadLocal 只负责隔离，不负责创建或关闭连接；连接仍由连接池管理，它只是“持有者”。
短生命周期任务推荐直连模式（无状态、更轻量）
对于批处理、定时任务或工具脚本等短时操作，不必引入 ThreadLocal，可直接：
- 方法开始时调用
dataSource.getConnection() - 配合
try-with-resources自动关闭Connection、Statement、ResultSet - 不跨方法传递 Connection，也不缓存到成员变量中
现代连接池（如 HikariCP）的 getConnection() 耗时极低（通常
JavaFX 或 Swing 等 GUI 应用要特别注意线程切换
UI 线程（如 JavaFX 的 Application Thread）绝不能执行数据库操作：
- 所有耗时的 JDBC 调用必须放在
Task、Service或ExecutorService后台线程中执行 - 后台线程内使用上述任一安全方式获取连接（推荐直连模式）
- 结果回传 UI 时，用
Platform.runLater()或SwingUtilities.invokeLater()更新界面
禁止在 UI 线程中持有 Connection，既防阻塞，也防误用共享连接。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
