转自:http://www.totcms.com/html/201602-29/20160229114145.htm
一个网站每天大概有20万的访问量，使用的tomcat自带dbcp连接池，一般网站访问很好，速度也很快，但是过一段时间后，总是报timeout waiting for idle object的异常信息，最后查了apache tomcat的官方文档，终于找到解决方法：
数据库连接池创建和管理池中的数据库连接对象。重建和复用已存在的连接对象要比创建新的连接要频繁的多。
连接池会存在这样一个问题。web应用已经明确关闭ResultSet,Statement,及Connection对象;当关闭出现故障的web应用所使用的资源
时将会导致这个连接资源不能在复用，这就是数据库连接池泄露，最终导致在你的应用程序中没有连接对象可以使用。
这当然是有解决方法的，Apache Commons DBCP可以配置为跟踪和恢复这些被弃的数据库连接对象。不仅恢复还可以跟踪那些连接数据库却没有关闭的代码片段。
要增加连接池中被弃的连接重新可用，打开配置文件，为Resource标签配置以下参数：
removeAbandonedOnBorrow=true
removeAbandonedOnMaintenance=true
removeAbandonedTimeout="60"
logAbandoned="true"
默认情况下removeAbandonedOnBorrow和removeAbandonedOnMaintenance都是为false。
注意：removeAbandonedOnMaintenance只有在timeBetweenEvictionRunsMillis设置为正数的情况下才有效。
removeAbandonedTimeout属性是设置数据库连接被释最多空闲时间多少秒之后设置为空闲。默认移除废弃连接的时间为300秒。
提示：
如果启用removeAbandonedOnMaintenance 或 removeAbandonedOnBorrow，那些被认为废弃的连接对象有可能被池回收。这个机制以下情况下会触发：
当getNumIdle() < 2并且getNumActive() > getMaxTotal() - 3及emoveAbandonedOnBorrow 设置为true时；或 当removeAbandonedOnMaintenance设置为true并且回收完成时。
打个比方说：
如果设置maxTotal=20，当有18个活跃连接、1个空闲连接时会触发removeAbandonedOnBorrow，不过仅是那些使用时间超过removeAbandonedTimeout秒数的活动连接才会被移除（默认是300秒）
，遍历resultset不作为正在使用。创建Statement,PrepareStatement或CallableStatement或使用其中一个执行查询（执行exceute方法）重置父连接的lastUsed属性。
-----------------------------
一、Apache官方DBCP文档给出的配置示例：
可参见：http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html
<Context>
<Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
username="javauser" password="javadude" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/javatest"/>
</Context>
tomcat JDBC连接池配置示例，自动检查连接的可用性，dbcp定时检测连接，dbcp自动重连的配置
-----------------------------
默认配置的DBCP连接池，是不对池中的连接做测试的，有时连接已断开了，但DBCP连接池不知道，还以为连接是好的呢。
应用从池中取出这样的连接访问数据库一定会报错。这也是好多人不喜欢DBCP的原因。
问题例一：
MySQL8小时问题，Mysql服务器默认连接的“wait_timeout”是8小时，也就是说一个connection空闲超过8个小时，Mysql将自动断开该 connection。
但是DBCP连接池并不知道连接已经断开了，如果程序正巧使用到这个已经断开的连接，程序就会报错误。
问题例二：
以前还使用Sybase数据库，由于某种原因，数据库死了后重启、或断网后恢复。
等了约10分钟后，DBCP连接池中的连接还都是不能使用的（断开的），访问数据应用一直报错，最后只能重启Tomcat问题才解决 。
解决方案：
方案1、定时对连接做测试，测试失败就关闭连接。
方案2、控制连接的空闲时间达到N分钟，就关闭连接，（然后可再新建连接）。
以上两个方案使用任意一个就可以解决以述两类问题。如果只使用方案2，建议 N <= 5分钟。连接断开后最多5分钟后可恢复。
也可混合使用两个方案，建议 N = 30分钟。
下面就是DBCP连接池，同时使用了以上两个方案的配置配置
validationQuery = "SELECT 1" 验证连接是否可用，使用的SQL语句
testWhileIdle = "true" 指明连接是否被空闲连接回收器(如果有)进行检验.如果检测失败,则连接将被从池中去除.
testOnBorrow = "false" 借出连接时不要测试，否则很影响性能
timeBetweenEvictionRunsMillis = "30000" 每30秒运行一次空闲连接回收器
minEvictableIdleTimeMillis = "1800000" 池中的连接空闲30分钟后被回收,默认值就是30分钟。
numTestsPerEvictionRun="3" 在每次空闲连接回收器线程(如果有)运行时检查的连接数量，默认值就是3.
解释：
配置timeBetweenEvictionRunsMillis = "30000"后，每30秒运行一次空闲连接回收器（独立线程）。并每次检查3个连接，如果连接空闲时间超过30分钟就销毁。销毁连接后，连接数量就少了，如果小于minIdle数量，就新建连接，维护数量不少于minIdle，过行了新老更替。
testWhileIdle = "true" 表示每30秒，取出3条连接，使用validationQuery = "SELECT 1" 中的SQL进行测试 ，测试不成功就销毁连接。销毁连接后，连接数量就少了，如果小于minIdle数量，就新建连接。
testOnBorrow = "false" 一定要配置，因为它的默认值是true。false表示每次从连接池中取出连接时，不需要执行validationQuery = "SELECT 1" 中的SQL进行测试。若配置为true,对性能有非常大的影响，性能会下降7-10倍。所在一定要配置为false.
每30秒，取出numTestsPerEvictionRun条连接（本例是3，也是默认值），发出"SELECT 1" SQL语句进行测试 ，测试过的连接不算是“被使用”了，还算是空闲的。连接空闲30分钟后会被销毁。
-----------------------------
maxIdle值与maxActive值应配置的接近。
因为，当连接数超过maxIdle值后，刚刚使用完的连接（刚刚空闲下来）会立即被销毁。而不是我想要的空闲M秒后再销毁起一个缓冲作用。这一点DBCP做的可能与你想像的不一样。
若maxIdle与maxActive相差较大，在高负载的系统中会导致频繁的创建、销毁连接，连接数在maxIdle与maxActive间快速频繁波动，这不是我想要的。
高负载系统的maxIdle值可以设置为与maxActive相同或设置为-1(-1表示不限制)，让连接数量在minIdle与maxIdle间缓冲慢速波动。
timeBetweenEvictionRunsMillis建议设置值
initialSize="5"，会在tomcat一启动时，创建5条连接，效果很理想。
但同时我们还配置了minIdle="10"，也就是说，最少要保持10条连接，那现在只有5条连接，哪什么时候再创建少的5条连接呢？
1、等业务压力上来了， DBCP就会创建新的连接。
2、配置timeBetweenEvictionRunsMillis=“时间”,DBCP会启用独立的工作线程定时检查，补上少的5条连接。销毁多余的连接也是同理。
------------------------------
DBCP的连接数会在 0 - minIdle - maxIdle - maxActive 之间变化。变化的逻辑描述如下：
默认未配置initialSize(默认值是0)和timeBetweenEvictionRunsMillis参数时，刚启动tomcat时，连接数是0。当应用有一个并发访问数据库时DBCP创建一个连接。
目前连接数量还未达到minIdle，但DBCP也不自动创建新连接已使数量达到minIdle数量（没有一个独立的工作线程来检查和创建）。
随着应用并发访问数据库的增多，连接数也增多，但都与minIdle值无关，很快minIdle被超越，minIdle值一点用都没有。
直到连接的数量达到maxIdle值，这时的连接都是只增不减的。 再继续发展，连接数再增多并超过maxIdle时，使用完的连接（刚刚空闲下来的）会立即关闭，总体连接的数量稳定在maxIdle但不会超过maxIdle。
但活动连接（在使用中的连接）可能数量上瞬间超过maxIdle，但永远不会超过maxActive。
这时如果应用业务压力小了，访问数据库的并发少了，连接数也不会减少（没有一个独立的线程来检查和销毁），将保持在maxIdle的数量。
默认未配置initialSize(默认值是0)，但配置了timeBetweenEvictionRunsMillis=“30000”（30秒）参数时，刚启动tomcat时，连接数是0。马上应用有一个并发访问数据库时DBCP创建一个连接。
目前连接数量还未达到minIdle，每30秒DBCP的工作线程检查连接数是否少于minIdle数量，若少于就创建新连接直到达到minIdle数量。
随着应用并发访问数据库的增多，连接数也增多，直到达到maxIdle值。这期间每30秒DBCP的工作线程检查连接是否空闲了30分钟，若是就销毁。但此时是业务的高峰期，是不会有长达30分钟的空闲连接的，工作线程查了也是白查，但它在工作。到这里连接数量一直是呈现增长的趋势。
当连接数再增多超过maxIdle时，使用完的连接(刚刚空闲下来)会立即关闭，总体连接的数量稳定在maxIdle。停止了增长的趋势。但活动连接（在使用中的连接）可能数量上瞬间超过maxIdle，但永远不会超过maxActive。
这时如果应用业务压力小了，访问数据库的并发少了，每30秒DBCP的工作线程检查连接(默认每次查3条)是否空闲达到30分钟(这是默认值)，若连接空闲达到30分钟，就销毁连接。这时连接数减少了，呈下降趋势，将从maxIdle走向minIdle。当小于minIdle值时，则DBCP创建新连接已使数量稳定在minIdle，并进行着新老更替。
配置initialSize=“10”时，tomcat一启动就创建10条连接。其它同上。
minIdle要与timeBetweenEvictionRunsMillis配合使用才有用,单独使用minIdle不会起作用。
-----------------------------
Tomcat自带DBCP的包，是$CATALINA_HOME/lib/tomcat-dbcp.jar。
tomcat-dbcp.jar含有commons pool、commons DBCP两个包的内容。但只含有与连接池有关的类。
数据源配置在context.xml文件中， 要在tomcat的lib目录中放jdbc 驱动包
数据源配置在server.xml的host中，不需要在tomcat的lib目录中放jdbc 驱动包，只使用工程中的jdbc驱动包
JNDI配置:更改tomcat的server.xml或context.xml
全局的数据源：
如果需要配置全局的 Resource，则在server.xml的GlobalNamingResources节点里加入Resource，再在Context节点里加入ResourceLink的配置。
全局的resource只是为了重用，方便所有该tomcat下的web工程的数据源管理，但如果你的tomcat不会同时加载多个web工程，也就是说一个tomcat只加载一个web工程时，是没有必要配置全局的resource的。
每个web工程一个数据源：
在$CATALINA_HOME/conf/context.xml的根节点Context里加入Resource配置。这种配置方法，你在context.xml配置了一个数据源，但Tomcat中有同时运行着5个工程，那了就坏事儿了，这个在Tomcat启动时数据源被创建了5份，每个工程1份数据源。连接数会是你配置的参数的5倍。
只有在你的Tomcat只加载一个web工程时,才可以直接以context.xml配置数据源。
<Resource name="jdbc/testDB" //指定的jndi名称，会用于spring数据源bean的配置和ResourceLink的配置
type="javax.sql.DataSource" //数据源类型，使用标准的javax.sql.DataSource
driverClassName="com.mysql.jdbc.Driver" //JDBC驱动器
url="jdbc:mysql://localhost:3306/test" //数据库URL地址
username="test" //数据库用户名
password="test" //数据库密码
maxIdle="40" //最大的空闲连接数
maxWait="4000" //当池的数据库连接已经被占用的时候，最大等待时间
maxActive="40" //连接池当中最大的数据库连接
removeAbandoned="true"
removeAbandonedTimeout="180"
logAbandoned="true" //被丢弃的数据库连接是否做记录，以便跟踪
factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" />
这里的factory指的是该Resource 配置使用的是哪个数据源配置类，这里使用的是tomcat自带的标准数据源Resource配置类，这个类也可以自己写，实现javax.naming.spi.ObjectFactory 接口即可。某些地方使用的commons-dbcp.jar中的org.apache.commons.dbcp.BasicDataSourceFactory，如果使用这个就需把commons-dbcp.jar及其依赖的jar包，都放在tomcat的lib下，光放在工程的WEB-INF/lib下是不够的。
ResourceLink 的配置有多种：
1)tomcat安装目录下的conf/context.xml，把全局的resource直接公开给该tomcat下的所有web工程，在Context节点中加入：
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
不建议在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置数据源，原因上面已说明了。
2)tomcat安装目录下的conf/server.xml，该方法可以指定把哪些source绑定到哪个web工程下。
<!-- 新增，第一行为加载的工程配置，第二行是该工程需要的ResourceLink配置 -->
<context docBase="/web/webapps/phoenix" path="" reloadable="false">
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
</context>
也可在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置数据源。
3)安装目录下的conf/localhost/下建立一个xml文件，文件名是<yourAppName>.xml。比如工程名为test，则该xml名为test.xml。
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
</context>
也可在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置数据源。
4)tomcat安装目录下的\webapps\test\META-INF\context.xml的Context节点中增加:
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
也可在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置数据源。
本文内容都在tomcat6.0上运行测试过，还下载了commons DBCP的源码，加入了跟踪日志，用于验证本文的理论。
| username | 通过JDBC建立一个连接所需的用户名 |
| password | 通过JDBC建立一个连接所需的密码 |
| url | 通过JDBC建立一个连接所需的URL |
| driverClassName | 所使用的JDBC驱动的类全名 |
| connectionProperties | 连接参数是在建立一个新连接时发送给JDBC驱动的 字符串的格式必须是[参数名=参数值;] 提示：用户名和密码属性是需要明确指出的，所以这两个参数不需要包含在这里 |
| defaultAutoCommit | JDBC驱动的缺省值 | 通过这个池创建连接的默认自动提交状态。如果不设置，则setAutoCommit 方法将不被调用。 |
| defaultReadOnly | JDBC驱动的缺省值 | 通过这个池创建连接的默认只读状态。如果不设置，则setReadOnly 方法将不被调用。（部分驱动不支持只读模式，如：Informix） |
| defaultTransactionIsolation | JDBC驱动的缺省值 | 通过这个池创建连接的默认事务策略，设置值为下列中的某一个： (参考 javadoc)
|
| defaultCatalog | 通过这个池创建连接的默认缺省的catalog | |
| cacheState | true | 如果设置为true，池化的连接将在第一次读或写，以及随后的写的时候缓存当前的只读状态和自动提交设置。这样就省去了对getter的任何进一步的调用时对数据库的额外查询。如果直接访问底层连接，只读状态和/或自动提交设置改变缓存值将不会被反映到当前的状态，在这种情况下，应该将该属性设置为false以禁用缓存。 |
| initialSize | 0 | 当这个池被启动时初始化的创建的连接个数，起始生效版本：1.2 |
| maxTotal | 8 | 可以在这个池中同时被分配的有效连接数的最大值，如设置为负数，则不限制 |
| maxIdle | 8 | 可以在池中保持空闲的最大连接数，超出设置值之外的空闲连接将被回收，如设置为负数，则不限制 |
| minIdle | 0 | 可以在池中保持空闲的最小连接数，超出设置值之外的空闲连接将被创建，如设置为0，则不创建 |
| maxWaitMillis | indefinitely | （如果没有可用连接）池在抛出异常前等待的一个连接被归还的最大毫秒数，设置为-1则等待时间不确定 |
提示: 如果在高负载的系统中将maxIdle的值设置的很低，则你可能会发现在一个新的连接刚刚被创建的时候就立即被关闭了。这是活跃的线程及时关闭连接要比那些打开连接的线程要快，导致空闲的连接数大于maxIdle。高负载系统中maxIdle的最合适的配置值是多样的，但是缺省值是一个好的开始点。
| validationQuery | 在连接池返回连接给调用者前用来进行连接校验的查询sql。如果指定，则这个查询必须是一个至少返回一行数据的SQL SELECT语句。如果没有指定，则连接将通过调用isValid() 方法进行校验。 | |
| testOnCreate | false | 指明对象在创建后是否需要被校验，如果对象校验失败，则触发对象创建的租借尝试将失败。 |
| testOnBorrow | true | 指明在从池中租借对象时是否要进行校验，如果对象校验失败，则对象将从池子释放，然后我们将尝试租借另一个 |
| testOnReturn | false | 指明在将对象归还给连接池前是否需要校验。 |
| testWhileIdle | false | 指明对象是否需要通过对象驱逐者进行校验（如果有的话），假如一个对象校验失败，则对象将被从池中释放。 |
| timeBetweenEvictionRunsMillis | -1 | 空闲对象驱逐线程运行时的休眠毫秒数，如果设置为非正数，则不运行空闲对象驱逐线程。 |
| numTestsPerEvictionRun | 3 | 在每个空闲对象驱逐线程运行过程中中进行检查的对象个数。（如果有的话） |
| minEvictableIdleTimeMillis | 1000 * 60 * 30 | 符合对象驱逐对象驱逐条件的对象在池中最小空闲毫秒总数（如果有的话） |
| softMiniEvictableIdleTimeMillis | -1 | 符合对象驱逐对象驱逐条件的对象在池中最小空闲毫秒总数，额外的条件是池中至少保留有minIdle所指定的个数的连接。当miniEvictableIdleTimeMillis 被设置为一个正数，空闲连接驱逐者首先检测miniEvictableIdleTimeMillis，当空闲连接被驱逐者访问时，首先与miniEvictableIdleTimeMillis 所指定的值进行比较（而不考虑当前池中的空闲连接数），然后比较softMinEvictableIdleTimeMillis所指定的连接数，包括minIdle条件。 |
| maxConnLifetimeMillis | -1 | 一个连接的最大存活毫秒数。如果超过这个时间，则连接在下次激活、钝化、校验时都将会失败。如果设置为0或小于0的值，则连接的存活时间是无限的。 |
| connectionInitSqls | null | 在第一次创建时用来初始化物理连接的SQL语句集合。这些语句只在配置的连接工厂创建连接时被执行一次。 |
| lifo | true | 设置为true表明连接池（如果池中有可用的空闲连接时）将返回最后一次使用的租借对象（最后进入）。设置为false则表明池将表现为FIFO队列——将会按照它们被归还的顺序从空闲连接实例池中获取连接 |
| poolPreparedStatements | false | 设置该连接池的预处理语句池是否生效 |
| maxOpenPreparedStatements | unlimited | 可以在语句池中同时分配的最大语句数。设置为负数则不限制。 |
这个设置同时作用于预处理语句池. 当一个可用的语句池被创建给每一个连接时，通过以下方法创建的预处理语句将被池化。
提示 -要确保你的连接会留下一些资源给其他语句。池化预处理语句可能会在数据库中保持他们的游标，可能会引起连接的游标越界，尤其是maxOpenPreparedStatements的值被设置为默认值（无限的），而且一个应用程序可能会为每个连接打开大量不同的预处理语句。为了避免这个问题maxOpenPreparedStatements应该被设置为一个小于连接可以打开的最大游标数的值。
| accessToUnderlyingConnectionAllowed | false | 控制PoolGuard是否可以访问底层连接 |
如果允许访问的话，使用如下代码结构：
Connection conn = ds.getConnection(); Connection dconn =((DelegatingConnection) conn).getInnermostDelegate(); ... conn.close()
默认值为false，这是一个有着潜在风险的操作，使用不当可能会导致非常严重的后果。（在守卫连接已被关闭的情况下，关闭底层连接或者继续使用它），只有在你需要直接访问驱动的特有扩展是可以谨慎使用。
NOTE: 除了最原始那个之外，不要关闭底层连接
| removeAbandoned | false | 标记是否删除超过removeAbandonedTimout所指定时间的被遗弃的连接。 如果设置为true，则一个连接在超过removeAbandonedTimeout所设定的时间未使用即被认为是应该被抛弃并应该被移除的。创建一个语句，预处理语句，可调用语句或使用它们其中的一个执行查询（使用执行方法中的某一个）会重新设置其父连接的lastUsed 属性。 在写操作较少的应用程序中将该参数设置为true可以将数据库连接从连接关闭失败中恢复。 |
| removeAbandonedTimeout | 300 | 一个被抛弃连接可以被移除的超时时间，单位为秒 |
| logAbandoned | false | 标志是否为应用程序中遗弃语句或连接的代码开启日志堆栈追踪。 因为一个堆栈跟踪已被创建，被抛弃的语句和连接相关的日志将被覆盖到打开每个连接或者创建一个Statement时 |
如果你启用了removeAbandoned，则一个连接被池回收再利用是可能的，因为它被认为是已遗弃 在(getNumIdle() < 2) and (getNumActive() > getMaxTotal() - 3)成立时，这个机制将被触发。
例如, maxTotal=20 ，这里有18个活跃连接，一个限制连接，将触发 "removeAbandoned"。但是只有在活动连接超过 "removeAbandonedTimeout" 所指定的秒数内未使用才会被删除（默认为300秒）。遍历一个结果集并不被统计为被使用，创建一个语句，预处理语句，可调用语句或使用它们其中的一个执行查询（使用执行方法中的某一个）会重新设置其父连接的lastUsed 属性
