连接池频繁创建销毁确实很耗资源
很多系统在运行过程中，出现数据库连接慢、响应延迟高，排查到最后发现是连接池被反复创建和销毁。这种情况听起来像是“用完就扔”，图省事，实则代价不小。
连接池本身的设计初衷，就是为了解决频繁建立和断开数据库连接带来的开销。每次新建一个数据库连接，都要走网络握手、身份认证、权限校验等一系列流程，就像每次进小区都得重新办门禁卡一样麻烦。而连接池相当于提前办好一批卡，大家轮流用，用完归还，效率自然高。
频繁重建连接池会发生什么
如果程序里每次用完就把整个连接池关掉，下次再重新初始化，等于把之前那批门禁卡全作废，所有人重新排队办卡。这会直接导致：
- 数据库连接建立的开销成倍增加
- CPU 和内存占用瞬间飙升
- 网络连接数暴涨，可能触发数据库的连接数限制
- 应用响应变慢，甚至出现超时
比如一个电商后台，在促销期间每秒有上千次查询，如果每次查询都经历“创建连接池→获取连接→执行SQL→销毁连接池”的流程，系统早就崩了。
真实场景：定时任务误操作
有个团队写了个定时数据同步脚本，每次跑完任务就把连接池 close 掉，认为这样更“干净”。结果每天凌晨两点，数据库监控都会报警：连接数突增几千，CPU 直接拉满。后来才发现，这个脚本每 5 分钟跑一次，每次都新建一个连接池，旧的还没完全释放，新的又来了，形成堆积。
改成复用同一个连接池后，连接数稳定在几十个，服务器负载下降了七成。
正确做法：复用 + 合理配置
连接池应该在整个应用生命周期内保持存在，通常在应用启动时初始化，关闭时统一释放。常见的连接池如 HikariCP、Druid、C3P0 都支持自动管理空闲连接、心跳检测、超时回收等功能。
以 HikariCP 为例，简单配置就能避免问题：
DataSource dataSource = new HikariDataSource();
((HikariDataSource) dataSource).setJdbcUrl("jdbc:mysql://localhost:3306/test");
((HikariDataSource) dataSource).setUsername("root");
((HikariDataSource) dataSource).setPassword("password");
((HikariDataSource) dataSource).setMaximumPoolSize(20);
((HikariDataSource) dataSource).setIdleTimeout(300000);这样的配置下，连接池会自动维护连接，不需要手动反复创建销毁。
如果你的应用中出现了“每次请求都 new 一个连接池”或者“任务结束就调用 shutdown”这类代码，赶紧改。这不是节省资源，是在烧资源。
连接池不是一次性餐具，别用完就扔。