数据库连接池 - HikariCP 和 Druid 如何选择
在当今的 Java 分布式生态（尤其是 Spring Boot 3.x / 微服务架构）下，如果只能给出一个绝对纯粹、不做任何骑墙妥协的结论，90% 的主流场景下都更加推荐 HikariCP。但这并不是说 Druid 不行，而是两者的技术演进方向和底层哲学发生了根本性的分化：HikariCP 追求的是将 “极致的并发性能” 做到物理极限；而 Druid 追求的是把 “企业级监控与防御” 做成全能型武器。
为什么 HikariCP 成了不可动摇的默认王者？
Spring Boot 官方团队在 2.x 和 3.x 中，毅然决然地废弃了传统的 Tomcat-JDBC，将 HikariCP 作为唯一雷打不动的内置数据源。它能在性能上秒杀群雄，靠的是底层对 Java 字节码和硬件 CPU 缓存的极限压榨：
- FastList 替代 ArrayList：普通的连接池拿到或归还连接时，会使用 JDK 的 ArrayList。它每次执行 remove 都会从头到尾人肉扫描一遍，且有边界检查。HikariCP 源码里自己手写了一个 FastList，去除了边界检查，逆向从尾部开始扫描，让连接的借还速度变成了闪电般的 O(1) 复杂度。
- 消除无谓的动态代理：像 Druid 等老牌连接池，为了追踪连接状态，会频繁使用 Proxy.newProxyInstance 产生动态代理对象。HikariCP 的作者认为这在极高并发下会产生严重的 JVM 内存碎片并增加 CPU 轮转。他直接通过 Javassist 在编译期人肉篡改生成了硬编码的字节码，完全消除了动态代理的损耗。
- 利用 CPU 缓存行对齐（Padding）：HikariCP 的源码中大量使用了诸如 LongAdder 的伪共享消除技术，确保核心多线程计数器不会在多核 CPU 的高并发争抢中引发 L1/L2 缓存行失效。
如果你的项目追求的是极致的低延迟、吞吐量以及微秒级的响应，HikariCP 是毫无争议的唯一选择。
为什么某些特定业务依然疯狂死守 Druid？
Druid被称为 “为监控而生的数据库连接池”。它在纯性能压测上虽然略逊于 HikariCP，但它自带了一套极其强悍的企业级 “特务监控网”：
- 无可替代的内置 Web 监控面板（StatFilter）：Druid 不需要借助任何外接组件，只要引入依赖并开启配置，就能在浏览器里直接访问一个内置的 druid/index.html 监控后台。在这个后台里，线上跑的哪行 SQL 最慢、哪个接口执行了多少次、哪里发生了全表扫描、甚至当前池子里有几个死连接，全部肉眼可见。
- 极其强大的 SQL 防火墙（WallFilter）：这是网络安全攻防的利器。Druid 内部人肉集成了一个真正的 SQL 解析器。它可以配置线上规则，一旦发现你的代码或外部输入中包含了非法的 SQL 拼接（比如带有恶意 OR 1=1 的 SQL 注入攻击，或者试图跨库执行 DROP TABLE），Druid 会在连接池内部直接将该 SQL 爆破拦截并报警，根本不会让它递交到 MySQL 物理执行！
- 强大的连接泄露诊断（LogFilter）：遇到团队里的新手开发写代码忘了关数据库连接导致连接池被打满时，Druid 能精准打印出是哪一行代码申请了连接却没有还，直接抓到“真凶”。
实际生产场景该怎么选？
在实际的选型上，我们应该遵循 性能归底层，监控归基础设施 的云原生架构理念：
- 在微服务/云原生架构下，我们更推荐使用 HikariCP。因为在高并发分布式场景下，数据库连接池应当专注于极致的吞吐量与极低的资源损耗。至于 Druid 擅长的 SQL 耗时统计、慢 SQL 监控，在现代大厂架构中，我们完全可以通过 SkyWalking、Prometheus、Canal 或者是云厂商自带的慢 SQL 审计日志（如阿里云 RDS DAS）等外围基础设施无感解决，没有必要为了监控而在核心微服务的本地数据源层引入复杂的 Druid 过滤器链，造成多余的性能妥协。
- 但在两类特殊场景下，我们会重回 Druid 的怀抱：一是那些完全没有搭建链路追踪、缺乏系统级监控的中小型单体政企项目，Druid 自带的监控面板能让运维低成本排查慢 SQL；二是对网络安全和防 SQL 注入有着极其严苛审计要求的金融/政务项目，我们会强制利用 Druid 的 SQL 防火墙（WallFilter）进行硬件级的代码合规御敌。