java中几个主流的数据库连接池

池(Pool)技术在一定程度上可以明显优化服务器应用程序的性能，提高程序执行效率和降低系统资源开销。这里所说的池是一种广义上的池，比如数据库连接池、线程池、内存池、对象池等。其中，对象池可以看成保存对象的容器，在进程初始化时创建一定数量的对象。需要时直接从池中取出一个空闲对象，用完后并不直接释放掉对象，而是再放到对象池中以方便下一次对象请求可以直接复用。其他几种池的设计思想也是如此，池技术的优势是，可以消除对象创建所带来的延迟，从而提高系统的性能。

要了解Java连接池我们先要了解数据库连接池（connection pool）的原理，Java连接池正是数据库连接池在Java上的应用。——我们知道，对于共享资源，有一个很著名的设计模式：资源池（Resource Pool）。

该模式正是为了解决资源的频繁分配﹑释放所造成的问题。为解决上述问题，可以采用数据库连接池技术。数据库连接池的基本思想就是为数据库连接建立一个“缓冲池”。预先在缓冲池中放入一定数量的连接，当需要建立数据库连接时，只需从“缓冲池”中取出一个，使用完毕之后再放回去。我们可以通过设定连接池最大连接数来防止系统无尽的与数据库连接。更为重要的是我们可以通过连接池的管理机制监视数据库的连接的数量﹑使用情况，为系统开发﹑测试及性能调整提供依据。

 

C3P0是一个开放源代码的JDBC连接池，它在lib目录中与Hibernate一起发布,包括了实现jdbc3和jdbc2扩展规范说明的Connection 和Statement 池的DataSources 对象。（主页：http://sourceforge.net/projects/c3p0/）

 

BoneCP 是一个开源的快速的 JDBC 连接池。BoneCP很小，只有四十几K（运行时需要log4j和Google Collections的支持，这二者加起来就不小了），而相比之下 C3P0 要六百多K。另外个人觉得 BoneCP 有个缺点是，JDBC驱动的加载是在连接池之外的，这样在一些应用服务器的配置上就不够灵活。当然，体积小并不是 BoneCP 优秀的原因，BoneCP 到底有什么突出的地方呢，请看看性能测试报告。（主页：http://jolbox.com/）

 

DBCP （Database Connection Pool）是一个依赖Jakarta commons-pool对象池机制的数据库连接池，Tomcat的数据源使用的就是DBCP。目前 DBCP 有两个版本分别是 1.3 和 1.4。1.3 版本对应的是 JDK 1.4-1.5 和 JDBC 3，而1.4 版本对应 JDK 1.6 和 JDBC 4。因此在选择版本的时候要看看你用的是什么 JDK 版本了，功能上倒是没有什么区别。（主页：http://commons.apache.org/dbcp/）

 

Proxool是一个Java SQL Driver驱动程序，提供了对你选择的其它类型的驱动程序的连接池封装。可以非常简单的移植到现存的代码中。完全可配置。快速，成熟，健壮。可以透明地为你现存的JDBC驱动程序增加连接池功能。

 

 

数据库连接是一种关键的有限的昂贵的资源，这一点在多用户的网页应用程序中体现得尤为突出。对数据库连接的管理能显著影响到整个应用程序的伸缩性和健壮性，影响到程序的性能指标。数据库连接池正是针对这个问题提出来的。数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而再不是重新建立一个；释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。

Java中常用的数据库连接池有：DBCP 、C3P0、BoneCP、Proxool、DDConnectionBroker、DBPool、XAPool、Primrose、SmartPool、MiniConnectionPoolManager及Druid等。

Java开源数据连接池: http://www.open-open.com/20.htm

Hibernate常用三种连接池的配置：http://tieba.baidu.com/f?kz=70604644

 

几种常用java连接池:http://hi.baidu.com/tangyudee/blog/item/f8bdb43decca892571cf6ced.html

感觉在介绍之前有必要阐述一下连接池的几个概念，有助于后边一些文字的理解。
最原始的数据库使用就是打开一个连接并进行使用，使用过后一定要关闭连接释放资源。由于频繁的打开和关闭连接对jvm包括数据库
都有一定的资源负荷，尤其应用压力较大时资源占用比较多容易产生性能问题。由此使用连接池的作用就显现出来，他的原理其实不复杂：
先打开一定数量的数据库连接，当使用的时候分配给调用者，调用完毕后返回给连接池，注意返回给连接池后这些连接并不会关闭，而是
准备给下一个调用者进行分配。由此可以看出连接池节省了大量的数据库连接打开和关闭的动作，对系统性能提升的益处不言而喻。
几个概念：
最小连接--应用启动后随即打开的连接数以及后续最小维持的连接数。
最大连接数--应用能够使用的最多的连接数
连接增长数--应用每次新打开的连接个数
举个例子说明连接池的运作：
假设设置了最小和最大的连接为10，20，那么应用一旦启动则首先打开10个数据库连接，但注意此时数据库连接池的正在使用数字为0--因为你并没有使用这些连接，而空闲的数量则是10。然后你开始登录，假设登录代码使用了一个连接进行查询，那么此时数据库连接池的正在使用数字为1、空闲数为9，这并不需要从数据库打开连接--因为连接池已经准备好了10个给你留着呢。登录结束了，当前连接池的连接数量是多少？当然是0，因为那个连接随着事务的结束已经返还给连接池了。然后同时有11个人在同一秒进行登录，会发生什么：连接池从数据库新申请（打开）了一个连接，连同另外的10个一并送出，这个瞬间连接池的使用数是11个，不过没关系正常情况下过一会儿又会变成0。如果同时有21个人登录呢？那第21个人就只能等前面的某个人登录完毕后释放连接给他。这时连接池开启了20个数据库连接--虽然很可能正在使用数量的已经降为0，那么20个连接会一直保持吗？当然不，连接池会在一定时间内关闭一定量的连接还给数据库，在这个例子里数字是20-10=10，因为只需要保持最小连接数就好了，而这个时间周期也是连接池里配置的。

好了，基本概念说完了，言归正传进行比较了。
首先说明的一点，为了应用便于移植以及可配置的角度，建议还是使用jndi统一进行连接池的配置。怎么配置其实网上都有很多例子，
这里简单举个例子（使用spring框架）：
首先在应用的上下文定义中配置jndi名称，如一个resource.xml文件，里边的写法
   
        jdbc/myapp
   
注意dataSource这个bean在dao层(hibernate或jdbc)的配置文件里需要作为dataSource名称的属性配置到所有bean中
其中“jdbc/myds”这个就是jndi名称了，下一步就是在应用服务器连接池里进行数据库连接以及对应的jndi配置了

一 开源数据连接池
1 dbcp
dbcp可能是使用最多的开源连接池，原因大概是因为配置方便，而且很多开源和tomcat应用例子都是使用的这个连接池吧。
这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。这个连接池的配置参见附件压缩包中的:dbcp.xml
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性还是可以，不过速度稍慢，在大并发量的压力下稳定性
有所下降，此外不提供连接池监控

2 c3p0
c3p0是另外一个开源的连接池，在业界也是比较有名的，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的:c3p0.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性相当不错，在大并发量的压力下稳定性也有一定保证，
          此外不提供连接池监控。
         
3 proxool
proxool这个连接池可能用到的人比较少，但也有一定知名度，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的：proxool.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性有一定问题，有一个需要长时间跑批的任务场景任务，同样的代码
在另外2个开源连接池中成功结束，但在proxool中出现异常退出。
但是proxool有一个优势--连接池监控，这是个很诱人的东西，大概的配置方式就是在web.xml中添加如下定义：
   
        admin
        org.logicalcobwebs.proxool.admin.servlet.AdminServlet     
  
  
      admin
      /admin
     
并在应用启动后访问：http://localhost:8080/myapp/admin这个url即可监控
不过proxool本身的包在监测使用中会有编码问题，附件中有一个
解决此问题的包，参见附件压缩包中的：proxool-0.9.0RC3.jar。另外需要jdk1.5以上的环境。

总结时刻：
综上所述，这几种开源连接池各有优劣，推荐使用c3p0，经检验这种连接池性能稳定，承压能力强。而proxool尽管有明显的性能问题，
但由于它具备监控功能，因此建议在开发测试时使用，有助于确定是否有连接没有被关掉，可以排除一些代码的性能问题。

二 商业中间件连接池
上面列举了几种开源的连接池，其实可以肯定的说，如果条件允许使用weblogic和websphere等中间件，那么不要犹豫，一定要
使用这些商业级别的中间件所自带的数据库连接池，他们的性能以及调配和开源的不在一个量级，举个例子，曾经有一个项目，数据量比较大，同样的代码应用，在3种开源的连接池里都多少出现过系统异常，而weblogic和websphere的连接池则正常运行，当然后来发现代码有一定瑕疵，但也侧面说明了商业连接池的强大。

1 weblogic的连接池
weblogic 8 是一个让人使用起来很轻松方便的应用服务器软件，但是到了9简直就是折磨，不知道是bea是怎么想的，oracle收购了bea以后出了10，比9强不少，但是最喜欢的还是8。。。
题外话不说了，就以8.1版本介绍一下他的数据库连接池（其实10的配置也差不多）
首先是连接池的基本设置，这个不讲了，网上有很多教程。然后进入Data Sources菜单配置数据源里边的JNDI Name，要和之前在应用配置中的一致：jdbc/myapp。
然后是连接池一些具体项目的配置，包括设置最小（Initial Capacity），最大（ Maximum Capacity）连接，以及
每次连接增加时需要一次性增加多少连接（Capacity Increment）。Allow Shrinking（是否把不用的连接退还数据库以保持最小连接数--这个就可以参见之前的连接池阐述的例子进行理解了）。
另外还有几个有意思的选项Test Reserved Connections：对取得的连接进行测试，Test Released Connections：对释放的连接进行测试。有人会问了，这个有什么用啊？
不知道大家在项目中有没有遇到java报连接失效的异常，反正我碰到过，只有在系统压力大的时候才出现。而有了这个选项就不用担心这个问题了--因为连接池已经帮你测试了，一旦检查到连接是无效的他会废弃掉还给数据库，只给你有效的。不过这个连接失效的异常其实多半是应用的不严谨造成的，我们更因该关心应代码的问题--但起码weblogic想到帮你弥补一下，是不是很贴心：）
另外一个重要功能当然是连接池监控：monitor选项卡里可以看到使用情况，有人又要问了，没有什么指标啊，别忘了custom view这个功能链接哦：）
有以下指标：当前连接数、曾经达到的峰值、可以使用的连接数、等待的连接数、从数据库打开的连接数、曾经关闭的连接数。。。其中前3项是我最关注的

使用评价：在具体项目应用中，此连接池的持续运行的稳定性很强，在大并发量的压力下性能也相当优秀，另外在一些异常情况下连接池里的连接也能够及时释放。
          连接池监控一目了然，及时到位。        

2 websphere的连接池
还是先来段题外话：记得有人说过，websphere只有版本6以后才算是websphere，个人很赞同。websphere 5以及以前的版本。。。还是忘了吧。
其实websphere的连接池秉承ibm一贯的风格：功能强大，使用复杂：）
进入控制台使用“JDBC提供程序”功能菜单进行连接池的基本配置，一路下来，不同的数据库配置方式不尽相同，最奇怪的是还要单独手工加上user和password参数，如果没有
资料指导的话还真是摸不着头脑。这些基本设置还是网上找吧很多的。连接池设置完还需要设置数据源，jndi名字一样与之前的对应：jdbc/myapp
高级设置包括初始化连接数，最大连接，连接有效性检查，不使用超时。。其实这些都和weblogic中的连接池配置大致一样。
连接池监控：使用运行监控菜单，里边会有一个监控项目选择，选jdbc监控即可，可恶的是一开始弹出什么服务器操作系统需要安装什么图形化控件，选择是那么就得去找到控件在操作系统（linux）下安装，然后很多的依赖组件都没有。。。搞了半天才发现选择否，监控数据以及图形一样能出来嘛，真是要怒了。
虽然经过一番波折但是监控的内容还是很强大的，就连接池来说一样包括当前连接数、曾经达到的峰值、可以使用的连接数、从数据库打开的连接数、曾经关闭的连接数。。。其中前3项是我最关注的，比较奇怪的现象是应用刚启动的时候已开启的连接数量竟然没有达到初始定义的连接数量，不清楚websphere是怎么个计算机制。
另外在压力大的时候可使用的连接数会是负数，当时很奇怪，想想也了然了，那个负数肯定是排队等待的数量了

使用评价：在具体项目应用中，此连接池的持续运行的稳定性相当强，在大并发量的压力下性能也足够优秀，另外在一些异常情况下连接池里的连接能够及时释放，
          连接池监控配置有些复杂，但是配置好后各项指标一目了然并且有图形显示 

 

• Druid 连接池简介

Druid首先是一个数据库连接池。Druid是目前最好的数据库连接池，在功能、性能、扩展性方面，都超过其他数据库连接池，包括DBCP、C3P0、BoneCP、Proxool、JBoss DataSource。Druid已经在阿里巴巴部署了超过600个应用，经过一年多生产环境大规模部署的严苛考验。

同时Druid不仅仅是一个数据库连接池，它包括四个部分：

    Druid是一个JDBC组件，它包括三个部分：

    基于Filter－Chain模式的插件体系。

    DruidDataSource 高效可管理的数据库连接池。

    SQLParser

Druid的功能

1、替换DBCP和C3P0。Druid提供了一个高效、功能强大、可扩展性好的数据库连接池。

2、可以监控数据库访问性能，Druid内置提供了一个功能强大的StatFilter插件，能够详细统计SQL的执行性能，这对于线上分析数据库访问性能有帮助。

3、数据库密码加密。直接把数据库密码写在配置文件中，这是不好的行为，容易导致安全问题。DruidDruiver和DruidDataSource都支持PasswordCallback。

4、SQL执行日志，Druid提供了不同的LogFilter，能够支持Common-Logging、Log4j和JdkLog，你可以按需要选择相应的LogFilter，监控你应用的数据库访问情况。

5、扩展JDBC，如果你要对JDBC层有编程的需求，可以通过Druid提供的Filter机制，很方便编写JDBC层的扩展插件。

• 使用原因

             原先项目使用的是C3P0连接池，在项目发布使用一段时间后发现c3p0 连接池访问数据库的时候创建连接会在oralce的lisenter.log 日志文件记录。 

经过一段时间观察发现oralce每6秒会在lisenter.log日志记录一次，我们设置的最小连接是20，所以oracle每次会在日志记录20条。随着时间越长日志文件越来越大，当日志文件达到4个G的时候会导致oracle死掉。 经过不断调整参数配置还是无法得到解决方案，最后选择使用阿里Druid连接池试试，Druid默认最小连接2个，配置好后发布观察日志发现只在创建的时候在日志里面记录了2条记录。没有像C3P0那样每6秒记录一次导致日志文件越来越大。 

lisenter.log 日志截图

 

• Druid使用

       1. Druid.jar包

                       druid-1.1.4.jar   1.1.4

       2.Druid连接池配置

                     

           这里没有配置最小连接数 ，默认为2个。

        3.Druid属性配置图

配置	缺省值	说明
name		配置这个属性的意义在于，如果存在多个数据源，监控的时候  可以通过名字来区分开来。如果没有配置，将会生成一个名字，  格式是："DataSource-" + System.identityHashCode(this)
jdbcUrl		连接数据库的url，不同数据库不一样。例如：  mysql : jdbc:mysql://10.20.153.104:3306/druid2   oracle : jdbc:oracle:thin:@10.20.149.85:1521:ocnauto
username		连接数据库的用户名
password		连接数据库的密码。如果你不希望密码直接写在配置文件中，  可以使用ConfigFilter。详细看这里：  https://github.com/alibaba/druid/wiki/%E4%BD%BF%E7%94%A8ConfigFilter
driverClassName	根据url自动识别	这一项可配可不配，如果不配置druid会根据url自动识别dbType，然后选择相应的driverClassName
initialSize	0	初始化时建立物理连接的个数。初始化发生在显示调用init方法，或者第一次getConnection时
maxActive	8	最大连接池数量
maxIdle	8	已经不再使用，配置了也没效果
minIdle		最小连接池数量
maxWait		获取连接时最大等待时间，单位毫秒。配置了maxWait之后，缺省启用公平锁，并发效率会有所下降，如果需要可以通过配置useUnfairLock属性为true使用非公平锁。
poolPreparedStatements	false	是否缓存preparedStatement，也就是PSCache。  PSCache对支持游标的数据库性能提升巨大，比如说oracle。  在mysql5.5以下的版本中没有PSCache功能，建议关闭掉。 作者在5.5版本中使用PSCache，通过监控界面发现PSCache有缓存命中率记录，  该应该是支持PSCache。
maxOpenPreparedStatements	-1	要启用PSCache，必须配置大于0，当大于0时，  poolPreparedStatements自动触发修改为true。  在Druid中，不会存在Oracle下PSCache占用内存过多的问题，  可以把这个数值配置大一些，比如说100
validationQuery		用来检测连接是否有效的sql，要求是一个查询语句。  如果validationQuery为null，testOnBorrow、testOnReturn、  testWhileIdle都不会其作用。
testOnBorrow	true	申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
testOnReturn	false	归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能
testWhileIdle	false	建议配置为true，不影响性能，并且保证安全性。  申请连接的时候检测，如果空闲时间大于  timeBetweenEvictionRunsMillis，  执行validationQuery检测连接是否有效。
timeBetweenEvictionRunsMillis		有两个含义：  1) Destroy线程会检测连接的间隔时间  2) testWhileIdle的判断依据，详细看testWhileIdle属性的说明
numTestsPerEvictionRun		不再使用，一个DruidDataSource只支持一个EvictionRun
minEvictableIdleTimeMillis
connectionInitSqls		物理连接初始化的时候执行的sql
exceptionSorter	根据dbType自动识别	当数据库抛出一些不可恢复的异常时，抛弃连接
filters		属性类型是字符串，通过别名的方式配置扩展插件，  常用的插件有：  监控统计用的filter:stat   日志用的filter:log4j  防御sql注入的filter:wall
proxyFilters		类型是List，  如果同时配置了filters和proxyFilters，  是组合关系，并非替换关系

　　　

　　　　4.数据源监控配置

　　　　　　　　　　在项目的web.xml加上以下代码

                              

 1 
 2         DruidWebStatFilter
 3         com.alibaba.druid.support.http.WebStatFilter
 4         
 5             exclusions
 6             *.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/*
 7         
 8     
 9     
10         DruidWebStatFilter
11         /*
12     
13     
14     
15         DruidStatView
16         com.alibaba.druid.support.http.StatViewServlet
17     
18     
19         DruidStatView
20         /druid/*
21     

         
总结时刻：
这两种商业级别的连接池都给我留下深刻印象，功能强大，使用稳定，性能优秀，监控到位。可以说难分伯仲，相对而言weblogic的连接池使用配置和监控配置更简单明了，而websphere的更复杂但选项功能也更多一些。其实这正是对两种应用服务器的使用印象的直接反映，当然总体比较2种应用服务器应该又是另一个话题了，也许在下一期的内容里。。。

比较了多种连接池的优劣，下面这个话题可能和比较本身没有直接关系，但个人认为应该是更有价值的一些经验分享吧，那就是---这么多指标配置，那些最大和最小连接数以及其他一些必要的配置指标，在一个正式的生产项目中到底应该配置什么值呢？
其实这个值首先还是要根据具体的项目情况、数据规模以及并发数来制定的(尽管像是套话，但是我们研发人员严谨的作风还是必要的:)。具体而言在中型偏小型的项目--给个数值把，用户数300到3000，数据量100万到1亿---中,建议weblogic设置为最大和最小都是200，websphere最小200最大300，前提是2者设置的最小内存要在1G以上，当然如果条件允许内存越大越好，不过32位机内存1.5G的限制是一定的（64位嘛我愿意设个4G内存过来，速度提升的感觉很爽啊）。这个数字出来以后相信会有不少问题要抛过来，我一一谈一下自己的体验和想法吧
1 为什么是200或300而不是更高？
回答：  再分配多了效果也不大了，一个是应用服务器维持这个连接数需要内存支持，刚才说了32位的机器只能支持到1.5G，并且维护大量的连接进行分配使用对cpu也是一个不小的负荷，因此不宜太大。
2 为什么不小一点？
回答：   如果太小，那么在上述规模项目的并发量以及数据量上来以后会造成排队现象，系统会变慢，数据库连接会经常打开和关闭，性能上有压力，用户体验也不好。
3 为什么weblogic最小最大都一样，而websphere不一样
回答：   其实和分配内存的最小最大值的情况一样，一般都推荐2个值应该一致，都放在内存里就好了嘛。但是ibm官方推荐2个值要有区别---官方说法还是要听的
4 其他开源连接池的分配方案还没说呢？
回答： 开源的个人认为到100就可以了，再高他也不会太稳定，当然1G的最小内存是一定要给tomcat分的