Connection复用的是JDBC Connection对象而非物理TCP连接，节省三次握手等开销；其本质是池化管理带状态的连接实例，需同线程借还，避免跨线程共享、错误关闭或绕过池直连。
Connection 复用到底复用什么
复用的不是物理 TCP 连接本身，而是 Connection 对象——即 JDBC 规范定义的接口实例。它背后可能持有一个已建立的 socket、预编译的 Statement 缓存、事务上下文等状态。池化对象真正节省的是创建新连接时的三次握手、认证、初始化会话变量等开销。
常见错误现象：Connection closed 异常频发，但日志里没看到显式调用 close()；或应用压测时连接数暴涨，远超配置的 maxActive。
- 根本原因往往是业务代码把
Connection当成“一次性资源”，在 finally 块中调用connection.close()——这其实只是归还到池，不是销毁连接 - 若误用
DataSource之外的方式（如直接 newDriverManager.getConnection()）获取连接，再扔给池管理，会导致连接泄漏或状态错乱 - 不同池实现对“复用”的语义略有差异：HikariCP 的
Connection是代理对象，关闭时清空本地事务和 auto-commit 状态；Druid 则额外做了 PreparedStatement 缓存绑定
HikariCP 里 getConnection() 返回的 Connection 为什么不能跨线程共享
因为连接池返回的 Connection 实例内部绑定了线程局部状态（比如 Hikari 的 ProxyConnection 持有 ConnectionBag 的引用和借用计数）。跨线程调用 close() 或执行 SQL，会导致连接无法正确归还、泄露，甚至触发 ConcurrentModificationException。
使用场景：异步任务（如 CompletableFuture.supplyAsync()）中直接传入主线程获取的 connection，是最典型的踩坑点。
立即学习“Java免费学习笔记（深入）”；
- 必须在同一线程内完成
getConnection()→ 使用 →close() - 如果需要跨线程传递数据，只传查询结果（如
List<Map<String, Object>>），而不是Connection或ResultSet - HikariCP 的
leakDetectionThreshold配置能帮你捕获这类问题，默认是 0（关闭），建议设为 60000（毫秒）用于测试环境
maxPoolSize 设太高反而让数据库更慢
连接池大小不是越大越好。当 maxPoolSize 超过数据库能高效并发处理的连接数（通常等于 CPU 核心数 × 2～4），多余连接会排队等待锁、争抢 buffer pool、加剧上下文切换，最终拖慢整体吞吐。
性能影响：PostgreSQL 默认 max_connections=100，MySQL 默认 max_connections=151，但真实可用并发远低于此——受磁盘 I/O、索引效率、长事务阻塞等制约。
- 线上推荐起步值：
maxPoolSize = CPU核心数 × (2～4)，再根据 APM 工具（如 SkyWalking）观察连接等待时间（pool.wait）动态调整 - 避免和数据库
max_connections设置相同；至少留 20% 余量给管理员连接、备份脚本等 - HikariCP 的
connectionTimeout默认 30 秒，若频繁超时，优先查数据库负载，而非盲目调大池子
PreparedStatement 缓存失效的三个隐藏条件
连接池本身不缓存 SQL，但底层 Connection 可能启用 PreparedStatement 缓存（如 MySQL Connector/J 的 cachePrepStmts=true）。一旦失效，每次 prepareStatement() 都走服务端解析，性能断崖下跌。
容易被忽略的地方：
- SQL 字符串完全一致才命中缓存（包括空格、换行、大小写），
"SELECT * FROM user"和"select * from user"是两个缓存项 - 使用了非标准参数占位符（如 MyBatis 的
${}拼接），生成的 SQL 每次都不同，缓存形同虚设 - 连接被回收重用后，某些驱动（如 older Oracle JDBC）会清空该连接上的所有预编译缓存，需靠
pool-prepared-statements（Druid）或cachePrepStmts+prepStmtCacheSize（MySQL）显式开启连接级缓存
连接池不是黑盒，它把连接生命周期从“打开-关闭”变成“借-还-清理”。最复杂的点不在配置参数，而在于理解每个 close() 调用背后，是归还、重置，还是真的断开——这取决于你用的是哪个池、连的是哪种数据库、驱动版本是否支持连接状态重用。
