jdbc connection 不是线程安全的，应避免多线程共享，而通过连接池为每个线程分配独立连接，确保事务隔离与状态互不干扰；connection 生命周期须绑定单次业务操作，严禁静态持有或跨线程传递。
JDBC 连接对象（Connection）本身**不是线程安全的**，官方规范未要求其实现线程安全，实际使用中也明确禁止多线程共享同一个 Connection 实例。真正安全的做法，不是“保护连接”，而是**避免共享连接**——通过资源隔离和池化管理，让每个线程拥有独立、短期使用的连接实例。
用连接池分配独立连接
连接池（如 HikariCP、Druid、DBCP）是标准解法。它在启动时预建一批物理连接，每次线程调用 dataSource.getConnection() 时，返回的是一个逻辑上“专属”的连接代理（或真实连接），用完必须归还（close() 不是真的关闭，而是放回池中）。这样既复用资源，又天然实现线程隔离。
- 连接池内部为每次获取操作分配新连接（或复用空闲连接），不跨线程传递同一连接实例
- 确保每个线程的事务、自动提交设置、游标状态互不影响
- 配置建议：合理设置
maxPoolSize（通常为 CPU 核数 ×（2～4）），避免连接争抢或闲置
别把 Connection 当全局变量或静态字段
常见错误是将 Connection 声明为 static 或长期持有（如放在单例 service 中）。这会导致多个线程并发调用时踩内存状态，比如一个线程 commit 会关闭其他线程正在读取的 ResultSet，或覆盖事务隔离级别。
- Connection 生命周期应严格绑定到单次业务操作（如一次 HTTP 请求、一个任务单元）
- 绝不在线程间传递、缓存或复用已获取的 Connection 实例
- 即使使用 Spring 的
JdbcTemplate，它也是线程安全的，但背后仍依赖连接池按需提供新连接
配合 ThreadLocal 做手动绑定（少用，仅特定场景）
极少数需要跨方法传递连接（如拦截器→Service→DAO），且不希望频繁从池中获取/释放时，可用 ThreadLocal<connection></connection> 封装。但必须严格保证：线程结束前主动清理（否则造成连接泄漏），且不能用于线程池中的工作线程（如 ExecutorService 提交的任务），因为线程会被复用。
- 只适用于请求-响应模型中生命周期明确的线程（如 Tomcat 的 worker 线程）
- 务必配合过滤器或 AOP，在请求结束时调用
threadLocal.remove() - 现代框架（Spring）已通过事务同步器（
TransactionSynchronizationManager）封装了该模式，开发者一般无需手写
事务与连接必须一对一
一个事务必须由唯一 Connection 承载。如果多个线程试图用同一个 Connection 并发执行 DML 并各自 commit，结果不可预测——后 commit 的会覆盖前者的事务边界，甚至触发连接重置。
- 要支持并发事务，就必须有至少 N 个连接（N = 最大并发事务数）
- 连接池的“按需分配 + 超时回收”机制，恰好满足这一需求
- 显式开启事务时（
conn.setAutoCommit(false)），务必在同一线程内完成所有操作并 commit/rollback
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
