连接池中DB连接开闭开销及使用最佳实践咨询

1. 开启和关闭DB连接的性能开销具体有多大？ #

物理数据库连接的创建和销毁开销远高于多数开发者的直觉，开销主要来自三类环节：

• 网络层面：TCP三次握手建连、四次挥手断连，跨网络场景下这部分延迟本身就不低，如果开启SSL加密还会额外增加TLS握手的加解密、证书校验开销
• 数据库侧：连接创建时需要完成账号鉴权、权限校验、分配会话专属内存、初始化会话上下文（字符集、事务隔离级别、会话变量等），连接销毁时需要回收会话资源、清理关联的内存和执行状态
• 高并发次生开销：如果大量请求同时频繁建连关连，数据库会把大量CPU、内存资源消耗在连接管理上，甚至触发连接数上限报错，直接影响正常业务请求的处理能力，这部分影响远大于单次建连的耗时。
  拿生产环境常见数据参考：同机房内网部署的MySQL实例，单条物理连接的创建+销毁耗时通常在5ms~30ms区间，如果是跨可用区、跨公网、开启强鉴权的场景，耗时会涨到上百毫秒甚至秒级。而从连接池获取已经初始化好的空闲连接，耗时通常在几微秒到几十微秒，和新建物理连接差了3个数量级以上。

2. 每次执行DB操作时频繁开启、操作完成后关闭DB连接，是否属于推荐的良好开发实践？ #

这个问题的核心是要分清楚操作的是物理连接还是连接池代理的逻辑连接：

• 如果不使用连接池，每次操作都手动新建物理连接、执行完就销毁物理连接，这是典型的反模式。除了前面提到的性能问题，高并发下会直接把数据库连接数打满，拖垮整个数据库服务，生产环境绝对不能这么写。
• 如果是正确使用连接池的场景，代码里调用的getConnection()是从池里取空闲连接，调用connection.close()根本不是销毁物理连接，而是把连接归还给连接池复用。这种“按需取连接、用完立刻释放”的写法反而是行业通用的最佳实践，一定要把连接释放的逻辑写在try-with-resources或者finally块里，避免业务异常导致连接泄漏。
  很多新手会误以为用了连接池就要尽量少调用close()，实际上长时间持有连接不归还，反而会导致连接池被占满，其他请求拿不到连接，是更常见的生产故障诱因。

3. 是否可以在不同业务方法间传递复用同一个DB连接来完成数据库操作？ #

要不要跨方法复用连接，完全取决于业务场景，没有绝对的能或者不能：

• 必须复用的场景：同一个本地事务范围内的多个数据库操作，必须复用同一个连接。数据库的事务是绑定在单条连接（会话）上的，如果同一个事务里的扣库存、创订单、记流水几个操作分别用不同的连接，每个连接的事务是独立的，根本没法实现统一提交、异常回滚。实际开发中不需要手动把连接当参数传来传去，Spring这类框架的事务管理器会通过ThreadLocal把连接绑定到当前事务线程上，同事务范围内的方法自动拿到同一个连接，避免了手动传参的麻烦。
• 绝对不能乱复用的场景：没有事务绑定关系的操作、跨线程的操作、生命周期很长的业务流程，绝对不要长期持有同一个连接到处传。首先JDBC连接本身不是线程安全的，多线程并发操作同一个连接会出现SQL串写、事务状态错乱的问题；其次连接有空闲超时时间，长期持有不归还，数据库端可能已经主动断开了连接，再用就会抛出连接失效的错误；最严重的是长期持有连接不归还，会导致连接池的连接被耗尽，整个服务的数据库请求全部阻塞。
  非必要不要手动跨方法传递连接，把连接生命周期的管理交给连接池和事务框架就好，手动传参非常容易遗漏释放逻辑，引发连接泄漏故障。

内容的提问来源于stack exchange，提问作者Avyaan