有一个提高效率的方法，完美解决了当年的数据库连接，长连接和短连接之争。
数据库连接句柄打开开销较大，一般需要30~40ms，如果在功能模块里开，性能降低一半不止。如果常开，在多线程服务器环境不合适。
所以采用了数据库连接池，虽然很多数据库提供了内建的连接池，那与我无关。
连接池在开始时是一个连接也不开。第一个使用者取用时打开一个连接，用完归还时，如果是正常归还，不关闭，就加到空闲队列头。下一次有人用就优先取已经打开的。因数据库致命故障归还的，就关闭，回收资源，放到队尾。
一个定时器线程定时扫描连接池健康度，有超过一定时间（一般是5分钟）不用的连接就关闭之。
  
这是一种极为可靠的连接池健康保障法。
一般的策略是保活，这很难的，你怎么发个信息并得到应答从而确定其活不活？如果那边太忙无暇顾及你，是否会误判？你想检查的连接正在被别人使用怎么办？
  
我的策略是保死，只检查空闲队列，没人用就弄死，不要老占着资源。有的数据库是按连接数付费的，没事别占着茅坑不拉屎，现用现开，最健康。保活的话，检查一次空闲队列需要很长时间，不知道需要多长时间才能得到一个应答，保死的只看时间戳，检查的非常快，锁队列的时间非常短。
实践中这个方法简单而可靠。数据库崩溃，服务器不必restart，等着数据库恢复即可，这叫自愈式连接池。
  
--
FROM 221.221.54.*

不是检查连接有效性，是检查连接的无用性。无用的连接关闭，不要占有资源。
打开的连接长时间不用就没法保证其可用性，夜长梦多，打开的连接，越长的时间不用，损坏的可能性越大。
如何你认为5分钟太长，可以缩短一些。这个时间等同于心跳时间间隔。
可以证明，与心跳周期容错效果相同，开销要小得多。
你可以1秒钟检查一次呀，只不过应用超过1秒间隔就重新开一次数据库呗，多消耗50ms最多了。此法对数据库没有负担。

换句话说吧，越长时间不用，损坏的可能性越大，不要等坏了再处理，关上得了。用的时候再开。

【 在 slowaction 的大作中提到: 】
: 实现空闲连接超时的功能
:
: 这个检查链接有效性没有替代关系
--
修改:ylh1969 FROM 221.221.54.*
FROM 221.221.54.*

用在连接池管理上的不多见，当年也是争议挺大的，直到证明超时间隔与心跳间隔等价，才平息了质疑。
如果连接一直在被使用，根本就不需要心跳。
【 在 slowaction 的大作中提到: 】
: 空闲超时功能是个非常常见的功能
--
修改:ylh1969 FROM 221.221.54.*
FROM 221.221.54.*

业务请求等价于心跳就行了，这样有业务请求包时，不用发专门的心跳包。

我搞长连接就这么干。

【 在 ylh1969 的大作中提到: 】
: 我见过一个项目，100多个客户端，1秒一个心跳，调用存储过程，数据库光为了心跳就开销不小。日志蹭蹭的涨。当需要找故障点时就如大海捞针。
:
--
FROM 123.122.126.*

我一样，就比你多一个空闲连接超时关闭的功能。
像ATM之类的终端几百个，工作时间很少，一天到晚玩心跳，数据库真累。
如果长连接不管，中途数据库关了又起了，连接失效。
【 在 z16166 的大作中提到: 】
: 业务请求等价于心跳就行了，这样有业务请求包时，不用发专门的心跳包。
: 我搞长连接就这么干。
:
--
修改:ylh1969 FROM 221.221.54.*
FROM 221.221.54.*