# 1. HikariCP 为什么快，ConcurrentBag 无锁借用、FastList 跳过已检查连接、字节码级优化 A FastList 是 JDK 标准 ArrayList，无特殊优化 B ConcurrentBag 靠全局锁保证线程安全，性能低于传统连接池 C ConcurrentBag 优先从线程本地缓存无锁借用连接，配合 FastList 与 JIT 友好优化，降低连接获取开销 ✓ 正确答案 D HikariCP 连接获取必须经过数据库校验
# 2. HikariCP 的 HouseKeeper 后台线程与连接健康检查（connectionTestQuery/keepaliveTime） A HouseKeeper 只负责创建连接，不处理健康检查 B HouseKeeper 后台线程执行超时回收、maxLifetime 检查与健康校验，connectionTestQuery 指定校验语句，keepaliveTime 控制空闲保活 ✓ 正确答案 C keepaliveTime 与连接健康无关 D connectionTestQuery 一旦设置就禁用连接复用
# 3. 连接池的 registerMbeans 与 JMX 监控指标（active/idle/pending/total）暴露 A active 表示活跃连接、idle 表示空闲、pending 表示等待线程数、total 为总连接数，pending 增长说明连接池可能耗尽 ✓ 正确答案 B JMX 指标只能查看，不能用于告警 C pending 指标表示空闲连接数 D registerMbeans 默认开启，无需配置
# 4. 连接泄漏的检测与定位，leakDetectionThreshold、连接借用追踪与栈信息分析 A leakDetectionThreshold 设置后连接泄漏会自动修复，无需处理 B 连接泄漏不会耗尽连接池 C leakage 检测无法记录借用来源 D leakDetectionThreshold 在连接借用超过阈值未归还时打印告警并记录借用栈，配合栈分析可定位泄漏点 ✓ 正确答案
# 5. Druid 的 RemoveAbandoned 连接泄漏回收与 HikariCP 的 leakDetectionThreshold 机制对比 A RemoveAbandoned 不需要开启配置 B 两者都会主动关闭泄漏连接 C HikariCP 也会主动回收泄漏连接 D Druid RemoveAbandoned 主动回收泄漏连接，HikariCP leakDetectionThreshold 只告警不回收，两者取舍不同 ✓ 正确答案
# 6. Druid 的 WallFilter SQL 防火墙规则配置与批量操作/多语句的放行策略 A WallFilter 默认放行多语句执行 B WallFilter 不影响批量操作 C WallFilter 用于拦截危险 SQL 与注入，多语句默认禁止，需通过 multiStatementAllow 等规则显式放行 ✓ 正确答案 D WallFilter 只能拦截 DDL，不能拦截 DML
# 7. 虚拟线程环境下连接池仍是稀缺资源，Semaphore 或池等待时间实施并发准入的策略 A 虚拟线程会无限增加连接，连接池无需额外处理 B 虚拟线程虽多但连接仍稀缺，需用 Semaphore 或连接池超时做并发准入，避免连接池排队积压 ✓ 正确答案 C 虚拟线程下连接池自动扩容，无需限流 D 连接池容量与数据库 max_connections 无关
# 8. 数据库重启或网络闪断后连接池如何自动恢复，为什么依赖连接校验与 maxLifetime 的协调 A 数据库重启后连接池必须重启应用才能恢复 B 连接池无法检测失效连接 C 连接校验淘汰失效连接、maxLifetime 定期重建、keepaliveTime 主动保活，三者协调使数据库恢复后连接池自动重建 ✓ 正确答案 D 连接校验与 maxLifetime 相互独立，无需协调
# 9. Druid 的监控统计（StatFilter/WallFilter/SpringFilter）与 SQL 防注入的工程价值 A StatFilter 只负责安全防护，不统计 SQL B StatFilter 提供 SQL 监控统计、WallFilter 负责防注入安全、SpringFilter 集成 Spring 链路，分别解决可观测性与安全性 ✓ 正确答案 C WallFilter 用于统计 SQL 执行时间 D SpringFilter 用于拦截 SQL 注入
# 10. HikariCP 的 initializationFailTimeout 与连接池启动失败的快速失败策略 A 设为 0 时一定导致启动失败 B 该参数只影响连接超时，不影响启动 C 设为正数时数据库不可用会导致应用启动失败，实现快速失败 ✓ 正确答案 D 设为负数是唯一推荐配置
# 11. HikariCP 的并发设计，FastList、ConcurrentBag 与无锁获取连接的核心如何？ A ConcurrentBag 优先从线程本地缓存无锁借用、共享队列用 CAS，FastList 优化连接缓存管理，共同降低锁竞争 ✓ 正确答案 B FastList 用于存储数据库连接对象本身 C ConcurrentBag 使用全局锁，性能差 D HikariCP 连接获取必然加锁
# 12. 连接池参数与问题排查，最大连接数、泄漏检测、慢 SQL 与连接被占满如何定位？ A 连接池被占满一定是连接泄漏导致 B 连接被占满需结合监控指标判断，再从连接泄漏、慢 SQL、并发超容三类定位根因 ✓ 正确答案 C 最大连接数越大越好，无需评估 D 慢 SQL 不影响连接池状态
# 13. 读写分离多数据源下连接池隔离与事务绑定（@Transactional 切到写库）的实现 A @Transactional 事务内读操作应走从库，以提升性能 B 开启事务时应强制路由到主库，因为事务内可能有写操作且主从延迟会导致读到旧数据 ✓ 正确答案 C 读写分离无需连接池隔离 D 事务与数据源路由无关
# 14. 连接池核心参数（maximumPoolSize/connectionTimeout/idleTimeout/maxLifetime）与 MySQL wait_timeout 的协调 A maxLifetime 应远大于 wait_timeout，让连接长期复用 B connectionTimeout 与连接获取无关 C idleTimeout 与 maxLifetime 无关 D maxLifetime 应小于 wait_timeout，否则连接被 MySQL 关闭后池中仍持有失效连接 ✓ 正确答案
# 15. 连接池大小如何按 TPS、RT 与数据库 max_connections 推算（公式与压测验证） A 连接数约等于 TPS×平均响应时间，且受数据库 max_connections 约束，需压测验证微调 ✓ 正确答案 B 连接池越大性能一定越好 C 连接池大小可任意设置，无规律 D TPS 与连接池大小无关
# 16. Druid 的监控能力，StatFilter、SQL 防火墙与慢 SQL 日志的工程配置如何？ A StatFilter 只负责防注入，不统计 SQL B WallFilter 用于统计 SQL 执行次数 C StatFilter 开启 SQL 统计与慢 SQL 日志，WallFilter 开启防火墙，配合 StatViewServlet 实现监控与防护 ✓ 正确答案 D 慢 SQL 日志只能由数据库生成，Druid 无法配置
# 17. 连接池耗尽时的快速失败，获取超时、队列与熔断的工程配置如何？ A 熔断器无法在连接耗尽时生效 B 连接池耗尽时应无限等待，直至连接释放 C 连接池耗尽与应用稳定性无关 D 通过 connectionTimeout 超时快速失败、信号量限流防积压、熔断器隔离故障，可避免系统雪崩 ✓ 正确答案
# 18. HikariCP 通过 Micrometer 暴露指标（hikaricp.connections.*）与连接耗尽告警配置 A hikaricp.connections.pending 表示等待线程数，active 接近 max 且 pending>0 时配置告警可预警连接池耗尽 ✓ 正确答案 B HikariCP 指标无法通过 Micrometer 暴露 C 只有 total 指标有意义，其他无用 D 连接池耗尽无法通过指标告警
