c3p0,oscache,jedis的bug

jdk版本
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
BEA JRockit(R) (build R27.5.0-110_o-99226-1.6.0_03-20080528-1505-linux-x86_64, compiled mode)

c3p0版本0.9.1，0.9.1.2在高并发时，测试2000并发出现线程阻塞，resin服务挂起，dump线程出现

 "com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0" id=85 BLOCKED
	waiting on com.mchange.v2.resourcepool.BasicResourcePool@33479e3
      at com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask.run (BasicResourcePool.java:1229)
      at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run (ThreadPoolAsynchronousRunner.java:547)
 
 "com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1" id=86 BLOCKED
	waiting on com.mysql.jdbc.JDBC4ResultSet@eaa775
	owned by "com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2"
      at com.mysql.jdbc.ResultSetImpl.realClose (ResultSetImpl.java:7478)                                      

c3p0作者也说了
https://github.com/swaldman/c3p0/issues/10

this looks very similar to a deadlock reported on SourceForge here. It's fixed already in the latest snapshot release of c3p0-0.9.5-pre3. give that a shot if you can (and let me know how it goes!). if not, c3p0-0.9.5-pre3 (non-SNAPSHOT) will be published very shortly. i may backport this fix to the stable 0.9.2 series, but not until people have kicked around 0.9.5-pre3 for a while.

as an aside, it looks like you have not set a preferredTestQuery or automaticTestTable, and so are using the default DatabaseMetaData.getTables(...) Connection test. That's slow; I strongly suggest defining a preferredTestQuery.

good luck!

换用dbcp 1.4版本没出现问题，配置如下

		<property name="driverClassName" value="${jdbc.driver}" />
		<property name="url" value="${jdbc.url}" />
		<property name="username" value="${jdbc.username}" />
		<property name="password" value="${jdbc.password}" />
		<property name="testOnBorrow" value="false" />
		<property name="testWhileIdle" value="true" />
		<!--#给出一条简单的sql语句进行验证 -->
		<!--#在取出连接时进行有效验证 -->
		<property name="validationQuery" value="select 1 from dual" />

		<property name="removeAbandonedTimeout" value="120" />
		<property name="removeAbandoned" value="true" />
		<!-- #运行判断连接超时任务的时间间隔，单位为毫秒，默认为-1，即不执行任务。 -->
		<property name="timeBetweenEvictionRunsMillis" value="3600000" />
		<!-- #连接的超时时间，默认为半小时。 -->
		<property name="minEvictableIdleTimeMillis" value="3600000" />
		<!-- 连接池启动时的初始值 -->
		<property name="initialSize" value="100" />
		<!-- 连接池的最大值 -->
		<property name="maxActive" value="2000" />
		<!-- 最大空闲值.当经过一个高峰时间后，连接池可以慢慢将已经用不到的连接慢慢释放一部分，一直减少到maxIdle为止 -->
		<property name="maxIdle" value="300" />
		<!-- 最小空闲值.当空闲的连接数少于阀值时，连接池就会预申请去一些连接，以免洪峰来时来不及申请 -->
		<property name="minIdle" value="200" />
		<!-- 最大等待时间:当没有可用连接时,连接池等待连接被归还的最大时间(以毫秒计数),超过时间则抛出异常-->
		<property name="maxWait" value="6000" />

oscache2.4.1在高并发时也会出现线程阻塞，resin服务挂起

    -- Waiting for notification on: com/opensymphony/oscache/base/EntryUpdateState@0x48702240[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at java/lang/Object.wait(J)V(Native Method)
    at java/lang/Object.wait(Object.java:485)
    at com/opensymphony/oscache/base/Cache.getFromCache(Cache.java:278)
    ^-- Lock released while waiting: com/opensymphony/oscache/base/EntryUpdateState@0x48702240[fat lock]
    at com/opensymphony/oscache/base/Cache.getFromCache(Cache.java:199)
    at com/opensymphony/oscache/general/GeneralCacheAdministrator.getFromCache(GeneralCacheAdministrator.java:132)

jedis2.1.0在高并发时偶尔会出现线程短暂的阻塞，resin服务没有挂起，还能正常访问