㈠ 开源的数据库连接池和普通的数据库连接池有什么区别
在项目中尝试使用了几种开源的数据库连接池实现。一种是dbcp，一种是c3p0，还有一种是proxool，这几种数据库连接池都可以很容易的在Spring配置起来。性能总体上上感觉dbcp为最优，因为稳定性和并发性都是我的项目需要的。
项目中经过反复测试，如果web server和数据库server不是同一个机器的话，在断网时间比较短的时间内三种数据库连接池都能较好的重连，但是在断网时间超过8个钟头 proxool就不能恢复工作了。但是dbcp却能很快的重新连接。实际生产环境中稳定性和总体性能是最重要的，都需要做相应的测试才能放心的让系统上生产线。
这里给出项目中数据库连接池配置：
dbcp的jndi：13 4 java:comp/env/jdbc/mysql5 6 proxool(proxool-0.9.0RC1)的配置： com.mysql.jdbc.Driver jdbc:mysql://ip:3306/dbname?useUnicode=true&characterEncoding=utf8&autoReconnect=true user password 500 15000 select CURRENT_DATE true mysqlProxoolDataSource 1000 false 建议使用DBCP，配置在tomcat中，然后在spring中使用jndi的形式获取。 c3p0(c3p0-0.9.0)： 1 3 4 com.mysql.jdbc.Driver 5 6 7 jdbc:mysql://192.168.0.225:3306/sendinmdb?useUnicode=true&characterEncoding=utf8&autoReconnect=true 8 9 10 ********11 12 13 ********14 15 16 10017 18 19 5020 21 22 10023 24 25 100026 27 28 3029 30 直接 & paste到spring配置文件里就可以使用了。 配置一些额外的tomcat 的DBCP连接池参数，也可以更好的使用到类似proxool提供的功能，只是dbcp更加稳定而已。tomcat/conf/context.xml中插入一个Resource元素： 解释一下以下这些参数的含义：
validationQuery = "select current_date()"
testOnBorrow = "true"
testOnReturn = "false"
testWhileIdle = "true"
当 从池中获取一个Connection后使用 select current_date() 来测试该数据库连接的可用性，如果SQL语句返回结果则认为是一个有效的连接，否则将继续测试知道可以拿到有效的连接。当返回Connection给池的时候不进行验证，但是Connection空闲的时候就要进行认证。
timeBetweenEvictionRunsMillis = "15000"
DBCP 清空线程睡眠的间隙，如值为负数则不运行该线程
numTestsPerEvictionRun = "10"
清空线程每次验证的连接对象个数
minEvictableIdleTimeMillis = "600000" Connection对象可以在池中空闲的最小时间，单位为毫秒详细配置请访问
㈡ java的3种数据库连接池用哪个好
1 dbcp
dbcp可能是使用最多的开源连接池，原因大概是因为配置方便，而且很多开源和tomcat应用例子都是使用的这个连接池吧。
这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。这个连接池的配置参见附件压缩包中的:dbcp.xml
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性还是可以，不过速度稍慢，在大并发量的压力下稳定性有所下降，此外不提供连接池监控
2 c3p0
c3p0是另外一个开源的连接池，在业界也是比较有名的，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的:c3p0.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性相当不错，在大并发量的压力下稳定性也有一定保证，此外不提供连接池监控。
3 proxool
proxool这个连接池可能用到的人比较少，但也有一定知名度，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的：proxool.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性有一定问题
㈢ java的3种数据库连接池用哪个好
1
dbcp
dbcp可能是使用最多的开源连接池，原因大概是因为配置方便，而且很多开源和tomcat应用例子都是使用的这个连接池吧。
这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。这个连接池的配置参见附件压缩包中的:dbcp.xml
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性还是可以，不过速度稍慢，在大并发量的压力下稳定性
有所下降，此外不提供连接池监控
2
c3p0
c3p0是另外一个开源的连接池，在业界也是比较有名的，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的:c3p0.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性相当不错，在大并发量的压力下稳定性也有一定保证，
此外不提供连接池监控。
3
proxool
proxool这个连接池可能用到的人比较少，但也有一定知名度，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的：proxool.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性有一定问题，有一个需要长时间跑批的任务场景任务，同样的代码
㈣ 什么是数据库连接池，有什么作用
数据库连接是一种有限的昂贵的资源，
数据库连接影响到程序的性能指标。
数据库连接池正是针对这个问题提出来的。数据库连接池负责分配、
管理和释放数据库连接，
它允许应用程序重复使用一个现有的数据库连接，
而再不是重新建立一个；
释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数
据库连接而引起的数据库连接遗漏。
这项技术能明显提高对数据库操作的性能。
㈤ 数据库连接池druid和bonep有什么区别
现在常用的开源数据库连接池主要有c3p0、dbcp、proxool三种，其中：
Spring 推荐使用dbcp；
Hibernate 推荐使用c3p0和proxool；
1、 DBCP：apache
DBCP(DataBase connection pool)数据库连接池。是apache上的一个 java连接池项目，也是 tomcat使用的连接池组件。单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar由于建立数据库连接是一个非常耗时耗资源的行为，所以通过连接池预先同数据库建立一些连接，放在内存中，应用程序需要建立数据库连接时直接到连接池中申请一个就行，用完后再放回去。dbcp没有自动的去回收空闲连接的功能。
2、 C3P0：
C3P0是一个开源的jdbc连接池，它实现了数据源和jndi绑定，支持jdbc3规范和jdbc2的标准扩展。c3p0是异步操作的，缓慢的jdbc操作通过帮助进程完成。扩展这些操作可以有效的提升性能。目前使用它的开源项目有Hibernate，Spring等。c3p0有自动回收空闲连接功能。
3、 Proxool：Sourceforge
Proxool是一种Java数据库连接池技术。是sourceforge下的一个开源项目,这个项目提供一个健壮、易用的连接池，最为关键的是这个连接池提供监控的功能，方便易用，便于发现连接泄漏的情况。
对比：
1> 相同时间内同等量的线程数和循环次数下:通过对三个连接池的三个标志性性能测试参数（Average,median,90%Line）进行比较发现：性能dbcp<=c3p0<proxool；
2> 不同情况下的同一数据库连接池测试：通过观察 Average,median,90%Line三个参数发
现三个连接池的稳定性（三种连接池的三个测试参数的变化情况）依次：稳定性dbcp>=c3p0>proxool。
结论：
通过对三种数据库连接池的性能测试发现，proxool和 c3p0能够更好的支持高并发，但是在稳定性方面略逊于 dpcp；
㈥ websphere 数据库连接池比其他连接池好么
websphere的连接池
还是先来段题外话：记得有人说过，websphere只有版本6以后才算是websphere，个人很赞同。websphere 5以及以前的版本。。。还是忘了吧。
其实websphere的连接池秉承ibm一贯的风格：功能强大，使用复杂：
进入控制台使用“JDBC提供程序”功能菜单进行连接池的基本配置，一路下来，不同的数据库配置方式不尽相同，最奇怪的是还要单独手工加上user和password参数，如果没有
资料指导的话还真是摸不着头脑。这些基本设置还是网上找吧很多的。连接池设置完还需要设置数据源，jndi名字一样与之前的对应：jdbc/myapp
高级设置包括初始化连接数，最大连接，连接有效性检查，不使用超时。
连接池监控：使用运行监控菜单，里边会有一个监控项目选择，选jdbc监控即可，可恶的是一开始弹出什么服务器操作系统需要安装什么图形化控件，选择是那么就得去找到控件在操作系统（linux）下安装，然后很多的依赖组件都没有。。。搞了半天才发现选择否，监控数据以及图形一样能出来嘛，真是要怒了。
虽然经过一番波折但是监控的内容还是很强大的，就连接池来说一样包括当前连接数、曾经达到的峰值、可以使用的连接数、从数据库打开的连接数、曾经关闭的连接数。。。其中前3项是我最关注的，比较奇怪的现象是应用刚启动的时候已开启的连接数量竟然没有达到初始定义的连接数量，不清楚websphere是怎么个计算机制。
另外在压力大的时候可使用的连接数会是负数，当时很奇怪，想想也了然了，那个负数肯定是排队等待的数量了
使用评价：在具体项目应用中，此连接池的持续运行的稳定性相当强，在大并发量的压力下性能也足够优秀，另外在一些异常情况下连接池里的连接能够及时释放，连接池监控配置有些复杂，但是配置好后各项指标一目了然并且有图形显示 。
总结：
这种商业级别的连接池功能强大，使用稳定，性能优秀，监控到位。
下面这个话题可能和比较本身没有直接关系，但个人认为应该是更有价值的一些经验分享吧，那就是---这么多指标配置，那些最大和最小连接数以及其他一些必要的配置指标，在一个正式的生产项目中到底应该配置什么值呢？
其实这个值首先还是要根据具体的项目情况、数据规模以及并发数来制定的(尽管像是套话，但是我们研发人员严谨的作风还是必要的:)。具体而言在中型偏小型的项目--给个数值把，用户数300到3000，数据量100万到1亿---中,建议websphere最小200最大300，前提是设置的最小内存要在1G以上，当然如果条件允许内存越大越好，不过32位机内存1.5G的限制是一定的（64位嘛我愿意设个4G内存过来，速度提升的感觉很爽啊）。这个数字出来以后相信会有不少问题要抛过来，
1 为什么是200或300而不是更高？
回答： 再分配多了效果也不大了，一个是应用服务器维持这个连接数需要内存支持，刚才说了32位的机器只能支持到1.5G，并且维护大量的连接进行分配使用对cpu也是一个不小的负荷，因此不宜太大。
2 为什么不小一点？
回答： 如果太小，那么在上述规模项目的并发量以及数据量上来以后会造成排队现象，系统会变慢，数据库连接会经常打开和关闭，性能上有压力，用户体验也不好。
3 为什么websphere最小最大不一样
回答： 其实和分配内存的最小最大值的情况一样，一般都推荐2个值应该一致，都放在内存里就好了嘛。但是ibm官方推荐2个值要有区别---官方说法还是要听的
4 其他开源连接池的分配方案还没说呢？
回答： 开源的个人认为到100就可以了，再高他也不会太稳定，当然1G的最小内存是一定要给tomcat分的
㈦ 数据库连接池与JDBC的区别
数据库连接池与JDBC的区别如下：
1、理念方面的区别：
数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而不是再重新建立一个；释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。
JDBC（Java DataBase Connectivity,java数据库连接）是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。JDBC提供了一种基准，据此可以构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序，同时，JDBC也是个商标名。
2、原理不同：
与数据库建立连接的标准方法是调用DriverManager.getConnection方法。该方法接受含有某个URL的字符串。DriverManager类（即所谓的JDBC管理层）将尝试找到可与那个URL所代表的数据库进行连接的驱动程序。DriverManager类存有已注册的Driver类的清单。当调用方法getConnection时，它将检查清单中的每个驱动程序，直到找到可与URL中指定的数据库进行连接的驱动程序为止。Driver的方法connect使用这个URL来建立实际的连接。
连接池基本的思想是在系统初始化的时候，将数据库连接作为对象存储在内存中，当用户需要访问数据库时，并非建立一个新的连接，而是从连接池中取出一个已建立的空闲连接对象。使用完毕后，用户也并非将连接关闭，而是将连接放回连接池中，以供下一个请求访问使用。而连接的建立、断开都由连接池自身来管理。同时，还可以通过设置连接池的参数来控制连接池中的初始连接数、连接的上下限数以及每个连接的最大使用次数、最大空闲时间等等。也可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。
㈧ 使用连接池技术与使用传统jdbc访问数据库相比，哪个速度上会更快一些
肯定是连接池更快啊，连接池存放一定数量的连接池，用户需要连接数据库时，直接从连接池取一条连接，不需要重新重建一条连接，这个道理很简单了，取和创建比，取明显效率要更高
㈨ 为什么HikariCP被号称为性能最好的Java数据库连接池，如何配置使用
HiKariCP是数据库连接池的一个后起之秀，号称性能最好，可以完美地PK掉其他连接池。
为何要使用HiKariCP？这要先从BoneCP说起：
什么？不是有C3P0/DBCP这些成熟的数据库连接池吗？一直用的好好的，为什么又搞出一个BoneCP来？因为，传说中BoneCP在快速这个特点上做到了极致，官方数据是C3P0等的25倍左右。不相信？其实我也不怎么信。可是，有图有真相啊（图片来自BoneCP官网：）：
而且，网上对于BoneCP是好评如潮啊，推荐的文章一搜一大堆。
然而，上Maven Repository网站（）查找有没有最新版本的时候，你会发现最新的是2013年10月份的（这么久没新版本出来了？）。于是，再去BoneCP的Githut（）上看看最近有没有提交代码。却发现，BoneCP的作者对于这个项目貌似已经心灰意冷，说是要让步给HikariCP了（有图有真相）：
……什么？又来一个CP？……什么是Hikari？
Hikari来自日文，是“光”（阳光的光，不是光秃秃的光）的意思。作者估计是为了借助这个词来暗示这个CP速度飞快。不知作者是不是日本人，不过日本也有很多优秀的码农，听说比特币据说日本人搞出来的。。。
这个产品的口号是“快速、简单、可靠”。实际情况跟这个口号真的匹配吗？又是有图有真相（Benchmarks又来了）：
这个图，也间接地、再一次地证明了boneCP比c3p0强大很多，当然，跟“光”比起来，又弱了不少啊。
那么，这么好的P是怎么做到的呢？官网详细地说明了HikariCP所做的一些优化，总结如下：
字节码精简：优化代码，直到编译后的字节码最少，这样，CPU缓存可以加载更多的程序代码；
优化代理和拦截器：减少代码，例如HikariCP的Statement proxy只有100行代码，只有BoneCP的十分之一；
自定义数组类型（FastStatementList）代替ArrayList：避免每次get()调用都要进行range check，避免调用remove()时的从头到尾的扫描；
自定义集合类型（ConcurrentBag）：提高并发读写的效率；
其他针对BoneCP缺陷的优化，比如对于耗时超过一个CPU时间片的方法调用的研究（但没说具体怎么优化）。
很多优化的对比都是针对BoneCP的……哈哈。
（参考文章：）
几个连接池的代码量对比（代码量越少，一般意味着执行效率越高、发生bug的可能性越低）：
可是，“黄婆卖瓜，自催自擂”这个俗语日本人也是懂得，于是，用户的好评如潮也是有图有真相：
还有第三方关于速度的测试：
也许你会说，速度高，如果不稳定也是硬伤啊。于是，关于稳定性的图也来了：
另外，关于可靠性方面，也是有实验和数据支持的。对于数据库连接中断的情况，通过测试getConnection()，各种CP的不相同处理方法如下：
（所有CP都配置了跟connectionTimeout类似的参数为5秒钟）
HikariCP：等待5秒钟后，如果连接还是没有恢复，则抛出一个SQLExceptions 异常；后续的getConnection()也是一样处理；
C3P0：完全没有反应，没有提示，也不会在“CheckoutTimeout”配置的时长超时后有任何通知给调用者；然后等待2分钟后终于醒来了，返回一个error；
Tomcat：返回一个connection，然后……调用者如果利用这个无效的connection执行SQL语句……结果可想而知；大约55秒之后终于醒来了，这时候的getConnection()终于可以返回一个error，但没有等待参数配置的5秒钟，而是立即返回error；
BoneCP：跟Tomcat的处理方法一样；也是大约55秒之后才醒来，有了正常的反应，并且终于会等待5秒钟之后返回error了；
可见，HikariCP的处理方式是最合理的。根据这个测试结果，对于各个CP处理数据库中断的情况，评分如下：
参考文章：
说得这么好，用起来会不会很麻烦啊，会不会有很多参数要配置才能有这样的效果啊？答案是：不会。
如果之前用的是BoneCP配置的数据源，那么，就简单了，只需要把dataSource换一下，稍微调整一下参数就行了：
BoneCP的数据源配置：
<!--BoneCpDatasource-->
<beanid="dataSourceBoneCp"class="com.jolbox.bonecp.BoneCPDataSource"destroy-method="close">
<propertyname="driverClass"value="${db.driverClass}"/>
<propertyname="jdbcUrl"value="${db.url}"/>
<propertyname="username"value="${db.username}"/>
<propertyname="password"value="${db.password}"/>
<propertyname=""value="2"/>
<propertyname="idleMaxAgeInMinutes"value="2"/>
<propertyname="maxConnectionsPerPartition"value="2"/>
<propertyname="minConnectionsPerPartition"value="0"/>
<propertyname="partitionCount"value="2"/>
<propertyname="acquireIncrement"value="1"/>
<propertyname="statementsCacheSize"value="100"/>
<propertyname="lazyInit"value="true"/>
<propertyname="maxConnectionAgeInSeconds"value="20"/>
<propertyname="defaultReadOnly"value="true"/>
</bean>
HiKariCP的数据源配置：
<!--HikariDatasource-->
<beanid="dataSourceHikari"class="com.zaxxer.hikari.HikariDataSource"destroy-method="shutdown">
<!--<propertyname="driverClassName"value="${db.driverClass}"/>--><!--无需指定，除非系统无法自动识别-->
<propertyname="jdbcUrl"value="jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8"/>
<propertyname="username"value="${db.username}"/>
<propertyname="password"value="${db.password}"/>
<!--连接只读数据库时配置为true，保证安全-->
<propertyname="readOnly"value="false"/>
<!--等待连接池分配连接的最大时长（毫秒），超过这个时长还没可用的连接则发生SQLException，缺省:30秒-->
<propertyname="connectionTimeout"value="30000"/>
<!--一个连接idle状态的最大时长（毫秒），超时则被释放（retired），缺省:10分钟-->
<propertyname="idleTimeout"value="600000"/>
<!--一个连接的生命时长（毫秒），超时而且没被使用则被释放（retired），缺省:30分钟，建议设置比数据库超时时长少30秒，参考MySQLwait_timeout参数（showvariableslike'%timeout%';）-->
<propertyname="maxLifetime"value="1800000"/>
<!--连接池中允许的最大连接数。缺省值：10；推荐的公式：((core_count*2)+effective_spindle_count)-->
<propertyname="maximumPoolSize"value="15"/>
</bean>
其中，很多配置都使用缺省值就行了，除了maxLifetime和maximumPoolSize要注意自己计算一下。
其他的配置（sqlSessionFactory、MyBatis MapperScannerConfigurer、transactionManager等）统统不用变。
其他关于Datasource配置参数的建议：
Configure your to be one minute less than thewait_timeoutof MySQL.