HikariCP与服务线程：单连接池多线程数据库访问疑问

这个场景非常有代表性，我来给你拆解下连接池的运行逻辑，以及你可能会遇到的问题：

连接池的核心运行逻辑 #

• 当第一个线程的数据库任务发起连接请求时，连接池会初始化并分配仅有的1个可用连接，此时连接池的可用连接数变为0
• 剩下9个线程的所有数据库任务再请求连接时，因为固定连接池没有多余连接，这些任务会进入连接池的等待队列（不同连接池实现的等待策略略有差异，比如HikariCP默认会让任务等待直到超时）
• 当持有连接的线程完成数据库操作并释放连接后，连接池会把这个连接按顺序分配给等待队列里的下一个任务（通常是先进先出的FIFO规则）
• 这个“获取-使用-释放-再分配”的过程会持续循环，直到所有线程队列里的数据库任务都执行完毕

可能出现的核心问题 #

• 任务串行化与严重延迟：原本10个线程并行处理的任务，所有数据库操作都被迫串行执行，相当于整个应用的数据库处理能力被限制在单连接的吞吐量上，任务处理延迟会急剧飙升，用户请求响应时间会变得无法接受
• 连接获取超时异常：如果连接池配置了connectionTimeout这类超时参数，等待时间超过阈值的任务会直接抛出连接获取失败的异常，导致请求失败
• 线程池资源浪费：10个线程里，绝大多数时间只有1个线程在真正执行数据库操作，其余线程都处于阻塞等待连接的状态，完全浪费了线程池的资源，10线程池的设计完全没有发挥作用
• 连接长期占用导致服务瘫痪：如果某个持有连接的线程因为业务逻辑卡住（比如死循环、第三方调用超时），这个连接会被一直占用，后续所有任务都无法获取连接，直接导致应用的数据库操作完全瘫痪
• 无界队列引发OOM风险：因为线程池是无界队列，若外部请求持续涌入，队列中的任务会不断累积，最终可能触发内存溢出（OOM），导致整个应用崩溃

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