我注意到，即使数据库已关闭，因此池中实际上没有可用的连接，Hikari CP仍会等待连接超时，然后再向客户端发送异常。
我同意在数据库可用时这样做是合乎需要的，但就我而言，我希望在连接不可用时不要让池在发送异常之前等待。
原因是数据库本身的响应时间少于2ms，因此我每秒可以处理数千个事务，但是当没有可用连接时，池将等待更长的时间（建议的最小可接受超时为250 ms）因此我无法处理吞吐量。另一方面，我的逻辑可以在没有数据库的情况下工作一段时间。
我应该如何处理？
编辑：
This link几乎是我想要实现的，减去了我希望HikariCP自动执行此操作的事实，我不应该激活挂起状态。
答案 0 :(得分：0)
也许您应该在应用程序代码中的某个地方引入一个计数器，如果并发请求数超过该值，则不要使用数据库。不知道自己在处理什么，很难说。读取还是写入。
根据brettwooldridge comment regarding connectionTimeout property，由于线程调度，即使有可用的连接，较低的超时也不可靠：
我们当然可以考虑使用较低的楼层，但是绝对最小值为125毫秒。
Windows和Linux的默认调度程序时间间隔均为20ms。如果在4核CPU上运行16个线程，则仅允许一个线程运行最多80ms。如果池由于（例如）在maxLifetime退出连接而导致空闲，那么这将留下宝贵的时间来建立连接以填充插槽，而不会给客户端造成虚假的故障。
如果未认真考虑以确保CPU和调度程序不会超饱和（以125ms的超时运行），则即使池具有可用的连接，也会使您的应用程序层出现虚假故障的风险。例如，在4核CPU上运行32个线程可能导致负载不足的线程饥饿长达120毫秒-非常接近边缘。