通过设置 BasicDataSource 属性 testOnBorrow=false 来提高 web app/rest-api 的性能，有风险吗？答案

【问题标题】：Improve web app/rest-api performance by setting BasicDataSource property testOnBorrow=false , is it risky?通过设置 BasicDataSource 属性 testOnBorrow=false 来提高 web app/rest-api 的性能，有风险吗？
【发布时间】：2015-09-28 12:08:42
【问题描述】：

似乎我们可以通过在 org.apache.commons.dbcp2.BasicDataSource 上设置 testOnBorrow=false 来提高性能。但有什么风险？

default setting 是真的。

因此，在默认情况下，每次从连接池中检索连接时，都会对数据库执行验证查询以测试它是否有效。虽然该查询可能会快速运行（通常“选择 1”是查询）。它仍然涉及将数据发送到数据库（通常在另一台服务器上）并读回结果。这需要时间，也许只有 50 毫秒，但如果没有必要，为什么还要这样做呢？

为了提高性能，我正在考虑设置testOnBorrow=false, testOnReturn=true, testOnCreate =true, testWhileIdle=true。而不是默认值。

因此，使用此设置的风险似乎是连接可能“变坏”并且您的数据库查询失败。但为什么会这样呢？尤其是使用 testOnReturn 和 testWhileIdle 时，风险似乎很小。什么可能导致此设置中的连接出现问题？

【问题讨论】：

任何东西。从功能的角度来看，您必须随时准备好在没有明显原因的情况下关闭连接。这也意味着在借用连接时检查连接在功能意义上是无用的。但是从性能的角度来看，您要问的是：在最后一个空闲测试和第一个查询之间连接断开的可能性有多大？这将取决于很多事情。此外，与每次借用一次相比，持续空闲测试会导致多少开销。

标签： java spring performance jdbc apache-commons-dbcp

【解决方案1】：

请注意，正确性和性能都是需要的属性。在实践中，过时的连接是真正的问题，我们经常不得不聘请 DBA/系统管理员寻求帮助。正如您所暗示的那样，连接损坏不应该发生，而是由于网络状况而发生。

使用验证查询有助于快速识别损坏的连接并将其从池中丢弃。这最终将允许将新的连接对象添加到池中。这种自动恢复过程非常适合 IMO。

【讨论】：