JDBC连接池的并发设计

Apache Tomcat 7系列的版本中使用了JDBC Connection Pool替代传统的commons-dbcp作为新的数据库连接池。其中很重要的一个原因是,commons-dbcp是单线程的,为了保证线程安全它必须将整个线程池上锁,并且它在对高并发的支持方面表现很差。JDBC Connection Pool一个很重要的新特性就是它对高并发环境和多核/多处理器系统的支持。下面将通过对JDBC Connection Pool的源码分析,深入理解其连接池设计的思想以及对高并发的解决方法。

连接池的存储设计

连接池使用两个阻塞队列BlockingQueue分别存储已分配的active和空闲的idle连接对象。如果BlockingQueue是空的,从BlockingQueue中取元素会被阻断进入等待状态,直到BlockingQueue进入元素后才被唤醒;同样,如果BlockingQueue是满的,任何试图往队列里存元素也会被阻断进入等待状态,直到BlockingQueue中有空间时才会被唤醒继续操作。
Tomcat 7 JDBC Connection Pool中的FairBlockingQueue实现了BlockingQueue接口。FairBlockingQueue采用先进先出(FIFO)原理,从而保证最先进入idle队列的连接最先被分配。FairBlockingQueue的offer和poll操作时均使用ReentrantLock锁定该连接,操作成功后解锁。ReentrantLock锁是一个可重入的互斥锁,它由最近成功获得锁定,并且还没有释放该锁的线程拥有。所以FairBlockingQueue在offer和poll一个连接对象时,能够确保该连接不会被其它并发的请求干扰,导致死锁。(后面小节中提到的锁均是指ReentrantLock)。

并发请求与连接对象的映射

当同时有多个用户请求连接对象时,若有足够的连接对象,则每个用户根据请求的时间依次从idle队列中获取一个连接对象。若idle队列中没有足够的队列,则需要按请求时间依次将这些用户请求添加到一个先进先出FIFO的受阻塞的请求队列,每次添加都是在队列尾部插入,从而保证一旦有空闲连接产生时,先来的请求最先获得连接。一旦请求获得连接对象后,它将从受阻塞的请求队列中移除。在向受阻塞的请求队列中添加和移除请求时,都需要对队列上锁,防止同时有多个请求被添加、或同时有多个请求被移除、或同时既有请求被添加又有请求被移除等情况发生,导致请求队列的乱序,直到操作完成后解锁。
连接池为每一个没有分配到连接的请求设置一个同步倒数计数器CountDownLatch,每个计数器传入的初始值分别为请求到来的顺序。例如,最早来到的且未被分配连接的请求的同步计数器初值设为1,后面来到的请求初值依次加1。计数器大于0,该线程就会被阻塞,直到计数器为0,该线程才能继续执行。每次当有空闲连接产生,并且成功分配给受阻塞的请求队列最前面的请求后,所有被阻塞的请求的计数器减1,因此刚获取连接对象的请求线程的计数器值变为0,从而可以继续执行,其它请求线程则继续处于阻塞状态。
在Tomcat 7 JDBC Connection Pool中,自定义了ExchangeCountDownLatch类,该类继承CountDownLatch,并且添加了一个成员变量,表示该请求线程最终被分配到的连接对象。
下面通过一个例子说明以上过程:如下图1中Time=1时,受阻塞请求队列中有n个请求线程受阻塞,各自的同步计数器值分别从1到n,此时空闲连接队列为空,工作连接队列中队尾的连接为Cm;假设Time=1结束后,工作连接队列中的C1被释放,则在Time=2时,受阻塞请求队列的队首R1(count=1)线程获得刚被释放的C1连接,因此它被移除受阻塞请求队列,队首请求变为R2,并且所有的受阻塞的请求线程计数器都减1,此时R1的count=0可以继续执行,R2的count=1,继续被阻塞。C1连接因为被R1所占用,因此又被添加到工作队列的队尾。

获取连接对象的流程

当用户请求连接对象时,若连接池中有空闲连接则立即返回该连接,若没有空闲连接但是连接总数没有达到设定的最大值,则创建一个新的连接对象并返回。否则循环等待并检查是否有空闲连接,若有空闲连接产生则返回该连接,若超过等待时间仍无空闲连接产生,则抛出异常。下图2详细说明了请求连接对象的流程。

在检查到idle队列中存在空闲连接后还需要对连接作有效性的检查,以确定该连接对象与数据库是处于连接状态,若连接断开需重新连接,以保证该连接对象的有效性。为了确保多个请求线程不会竞争同一个连接对象,首先获得该连接的线程需要对该连接上锁,直到检查完毕确保该连接有效并被添加到active队列后才为其解锁。

 

你可能感兴趣的:(数据库连接池)