java中几种数据库链接池的比较

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

好了，基本概念说完了，言归正传进行比较了。 首先说明的一点，为了应用便于移植以及可配置的角度，建议仍是使用jndi统一进行链接池的配置。怎么配置其实网上都有不少例子， 这里简单举个例子（使用spring框架）： 首先在应用的上下文定义中配置jndi名称，如一个resource.xml文件，里边的写法 <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"><value>jdbc/myapp</value></property> </bean> 注意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中添加以下定义： <servlet> <servlet-name>admin</servlet-name> <servlet-class>org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>admin</servlet-name> <url-pattern>/admin</url-pattern> </servlet-mapping> 并在应用启动后访问：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是怎么个计算机制。 另外在压力大的时候可以使用的链接数会是负数，当时很奇怪，想一想也了然了，那个负数确定是排队等待的数量了

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

总结时刻： 这两种商业级别的链接池都给我留下深入印象，功能强大，使用稳定，性能优秀，监控到位。能够说难分伯仲，相对而言weblogic的链接池使用配置和监控配置更简单明了，而websphere的更复杂但选项功能也更多一些。

比较了多种链接池的优劣，下面这个话题可能和比较自己没有直接关系，但我的认为应该是更有价值的一些经验分享吧，那就是---这么多指标配置，那些最大和最小链接数以及其余一些必要的配置指标，在一个正式的生产项目中到底应该配置什么值呢？ 其实这个值首先仍是要根据具体的项目状况、数据规模以及并发数来制定的(尽管像是套话，可是咱们研发人员严谨的做风仍是必要的:)。具体而言在中型偏小型的项目--给个数值把，用户数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分的 5 还有其余的指标吗？ 回答： 固然还有一些，但我的认为剩下的具体状况具体分析了不在这里一一列举了，你们有兴趣能够和我讨论分享一下。

林林总总说了很多但愿对你们有帮助，这些比较分析和数据都具有实际应用支撑。