应用服务器的连接池、自己写的连接池或第三方的连接池哪个好

Question

自己写？编写一个产品级别的连接需要非常高的水平，在国内这样的人也是屈指可数的。像 c3p0 这样已经相当完善的连接池实现，现在还是处于 0.9.x 的版本。在应用服务器上的话，那毋庸置疑就是用应用服务器上的数据源，其本身就是个连接池，从 JNDI 上获得。
如果不是应用服务器，那就使用开源的连接池实现。

Answer 1

下面这些是原来在一个帖子中回复的关于连接池中的技术要点，以及困难的部分，要想自己实现连接池的话可以参考一下：如果需要自己实现一个连接池的话，最起码得对这些技术灵活运用：  * JDBC（java.sql.*, javax.sql.*）
  * 线程处理、定时任务
  * 动态代理（java.lang.reflect.Proxy, java.lang.reflect.InvocationHandler）
  * 集合（java collection framework）用到的 Java 技术基本上就是这些了。我草拟了一些连接池实现中主要的技术难点（个人观点仅供参考）：1：Connection#close 问题。使用者使用连接池与不使用连接池，除了从哪获得 Connection 对象不一样之外，其他 JDBC 的代码是完全相同的，并不能因为使用连接池而改变既有的 JDBC 代码。如果不能改变 JDBC 代码，就带来了一个 Connection close 的问题，大家都知道这个调用是关闭数据库连接，如果在连接池中这么做的话就会关闭连接，使用连接得不到重用。解决方案：
1. 动态代理重写 close 方法，将其改为把连接还回到池中去；
2. 使用装饰器模式重写 close 方法，其他方法进行委托调用。2：连接被动关闭问题。为了保证连接的复用性，将连接一直保存在池中。有些数据库服务器会将已经连接很久的客户端连接主动踢掉，如果碰到这种情况，在池中的这个连接池就会变为不可用状态，如果被客户端使用的话将会抛出连接被关闭的 SQLException。解决方案：
使用一个守护线程定时地检查池中连接的健康状态，如果是不健康的连接就将其抛弃，重新生成一个放回池中以便补充。3：连接回收问题。假如我们的连接池最大设为 50 个，在某一并发很高的时段达到了 50 个，但是过后并发率就降下去了，对于连接池来说池中还是 50 个连接，实际上后面根本不需要那么多连接。这时连接池白白地浪费了几十个数据库宝贵的连接（数据库对于客户端的连接数是有限制的），如果连接池占用了很多的连接，那么可能会导致其他应用程序因为数据库客户端的连接数到了限制而无法再获得连接。我们应该及时地将不需要使用的连接关闭还给数据库服务器，保留一些基本连接数。解决方案：
配置连接池最大和最小的连接数，以及最大的空闲时间。使用一个守护线程定时查询池中哪些连接空闲的时间已经超过了配置的空闲时间时，就将其取出关闭还给数据库，这时如果池中连接数小于配置最小的连接数时，由这个守护线程打开几个连接填充到池中去。4：网络中断重连问题。连接池中的连接在网络中断时，池中连接会全部断开，数据库服务端也会回收断开的连接。但是网络中断后，过了一些时间又连上了，这时池中的连接依然是断开的，如果取出来用的话，不用说就会抛出异常的。一个优秀的连接池，必须实现自动重连功能，否则就没有可用的价值。解决方案：
与问题 1 的解决方案类似，但是这个线程应在网络中断时尝试关闭连接，并扔掉池中连接，启动网络连接监测直到网络通信恢复为止，当一监测到恢复时，立即从数据库中获得连接填充连接池。--------------------------------------------------------------------
总之，要自己实现一个可用、高效的连接池，难度非常大。就算是著名的 Apache Commons DBCP 连接池实际在某些地方也是不尽如人意的。

Answer 2

ProXool
proxool和tomcat DBCP都是很成熟的连接池，在访问量稳定之后两者性能不相上下。
而突发的大访问量也是可以通过调整参数来很好的处理的。但考虑到proxool有即时监控连接池状态的功能，而且代码更方便写，还是推荐使用proxool。