使用JAVA中的动态代理实现数据库连接池

               

数据库连接池在编写应用服务是经常需要用到的模块，太过频繁的连接数据库对服务性能来讲是一个瓶颈，使用缓冲池技术可以来消除这个瓶颈。我们可以在互联网上找到很多关于数据库连接池的源程序，但是都发现这样一个共同的问题：这些连接池的实现方法都不同程度地增加了与使用者之间的耦合度。很多的连接池都要求用户通过其规定的方法获取数据库的连接，这一点我们可以理解，毕竟目前所有的应用服务器取数据库连接的方式都是这种方式实现的。但是另外一个共同的问题是，它们同时不允许使用者显式的调用Connection.close()方法，而需要用其规定的一个方法来关闭连接。这种做法有两个缺点：

第一：改变了用户使用习惯，增加了用户的使用难度。

首先我们来看看一个正常的数据库操作过程：

使用者在用完数据库连接后通常是直接调用连接的方法close来释放数据库资源，如果用我们前面提到的连接池的实现方法，那语句conn.close()将被某些特定的语句所替代。

第二：使连接池无法对之中的所有连接进行独占控制。由于连接池不允许用户直接调用连接的close方法，一旦使用者在使用的过程中由于习惯问题直接关闭了数据库连接，那么连接池将无法正常维护所有连接的状态，考虑连接池和应用由不同开发人员实现时这种问题更容易出现。

综合上面提到的两个问题，我们来讨论一下如何解决这两个要命的问题。

首先我们先设身处地的考虑一下用户是想怎么样来使用这个数据库连接池的。用户可以通过特定的方法来获取数据库的连接，同时这个连接的类型应该是标准的java.sql.Connection。用户在获取到这个数据库连接后可以对这个连接进行任意的操作，包括关闭连接等。

通过对用户使用的描述，怎样可以接管Connection.close方法就成了我们这篇文章的主题。

为了接管数据库连接的close方法，我们应该有一种类似于钩子的机制。例如在Windows编程中我们可以利用Hook API来实现对某个Windows API的接管。在JAVA中同样也有这样一个机制。JAVA提供了一个Proxy类和一个InvocationHandler，这两个类都在java.lang.reflect包中。我们先来看看SUN公司提供的文档是怎么描述这两个类的。

SUN的API文档中关于Proxy的描述很多，这里就不罗列出来。通过文档对接口InvocationHandler的描述我们可以看到当调用一个Proxy实例的方法时会触发Invocationhanlder的invoke方法。从JAVA的文档中我们也同时了解到这种动态代理机制只能接管接口的方法，而对一般的类无效，考虑到java.sql.Connection本身也是一个接口由此就找到了解决如何接管close方法的出路。

首先，我们先定义一个数据库连接池参数的类，定义了数据库的JDBC驱动程序类名，连接的URL以及用户名口令等等一些信息，该类是用于初始化连接池的参数，具体定义如下：

其次是连接池的工厂类ConnectionFactory，通过该类来将一个连接池对象与一个名称对应起来，使用者通过该名称就可以获取指定的连接池对象，具体代码如下：

ConnectionFactory主要提供了用户将将连接池绑定到一个具体的名称上以及取消绑定的操作。使用者只需要关心这两个类即可使用数据库连接池的功能。下面我们给出一段如何使用连接池的代码：

从使用者的示例代码就可以看出，我们已经解决了常规连接池产生的两个问题。但是我们最最关心的是如何解决接管close方法的办法。接管工作主要在ConnectionFactory中的两句代码：

DataSourceImpl是一个实现了接口javax.sql.DataSource的类，该类维护着一个连接池的对象。由于该类是一个受保护的类，因此它暴露给使用者的方法只有接口DataSource中定义的方法，其他的所有方法对使用者来说都是不可视的。我们先来关心用户可访问的一个方法getConnection

DataSourceImpl类中实现getConnection方法的跟正常的数据库连接池的逻辑是一致的，首先判断是否有空闲的连接，如果没有的话判断连接数是否已经超过最大连接数等等的一些逻辑。但是有一点不同的是通过DriverManager得到的数据库连接并不是及时返回的，而是通过一个叫_Connection的类中介一下，然后调用_Connection.getConnection返回的。如果我们没有通过一个中介也就是JAVA中的Proxy来接管要返回的接口对象，那么我们就没有办法截住Connection.close方法。

终于到了核心所在，我们先来看看_Connection是如何实现的，然后再介绍是客户端调用Connection.close方法时走的是怎样一个流程，为什么并没有真正的关闭连接。

一旦使用者调用所得到连接的close方法，由于用户的连接对象是经过接管后的对象，因此JAVA虚拟机会首先调用_Connection.invoke方法，在该方法中首先判断是否为close方法，如果不是则将代码转给真正的没有被接管的连接对象conn。否则的话只是简单的将该连接的状态设置为可用。到此您可能就明白了整个接管的过程，但是同时也有一个疑问：这样的话是不是这些已建立的连接就始终没有办法真正关闭？答案是可以的。我们来看看ConnectionFactory.unbind方法，该方法首先找到名字对应的连接池对象，然后关闭该连接池中的所有连接并删除掉连接池。在DataSourceImpl类中定义了一个close方法用来关闭所有的连接，详细代码如下：

该方法一一调用连接池中每个对象的close方法，这个close方法对应的是_Connection中对close的实现，在_Connection定义中关闭数据库连接的时候是直接调用没有经过接管的对象的关闭方法，因此该close方法真正的释放了数据库资源。

以上文字只是描述了接口方法的接管，具体一个实用的连接池模块还需要对空闲连接的监控并及时释放连接，详细的代码请参照相关资料。

           

再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow