ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Tomcat的新一代连接池jdbc-pool及实现分析

2021-05-15 15:54:25  阅读:206  来源: 互联网

标签:jdbc Tomcat 队列 connection idle 连接池 连接 pool


前面的文章,我们分析了Tomcat中的dbcp连接池的原理及实现。

数据源连接池的原理及Tomcat中的应用


其实,Tomcat官方还提供了另一种pool的实现,即jdbc-pool。


jdbc-pool的定位,是做为DBCP Pool的替代,或至少是另一个选择

那我们为什么需要一个新的connection pool呢?

Tomcat官方文档是这个介绍的:

  1. DBCP 1.x是单线程的,为了保证线程安全,需要在对象的创建和返回时短时间的锁定整个池。

  2. 随着多线程并发的进行对象的获取和释放,性能反而会下降。在DBCP 2.x解决了这个问题

  3. DBCP 有60多个class, 而tomcat-jdbc-pool核心class只有8个。这样,只需要少量的修改就可以应对后续的需求

  4. Tomcat jdbc pool 的实现支持异步获取Connection, 而不需要增加额外的Thread

  5. 不会产生饥饿死锁。如果一个连接池是空的,并且有线程在等待连接,此时如果有连接返回,连接池会唤醒正确的线程。

此处,还增加了一些超过其它连接池的特性,例如:

  1. 支持高并发和多核心环境

  2. 动态的接口实现

  3. 支持自定义的interceptor,从而支持更多自定义的功能

更多的特性,请参见官方文档。

如何使用

看过我们上一篇文章的朋友,应该都了解DBCP 连接池在Tomcat中如何进行配置。想要从DBCP 切换到jdbc-pool,Tomcat官方也尽可能的提供了方便的方式,所有的属性配置基本都和DBCP一样,意义也一到。 所以,从DBCP到jdbc-pool,只需要配置factory属性,值设置为org.apache.tomcat.jdbc.pool.DataSourceFactory即可。

具体其内在的实现是什么样的呢?我们一起来看一下。

我们的数据仍采用和上一篇文章一样的配置,再增加Resourcefactory属性。

此时,我们会发现,在连接池的初始化时,会有下在的逻辑:

/**     * Initialize the connection pool - called from the constructor     * @param properties PoolProperties - properties used to initialize the pool with     * @throws SQLException if initialization fails     */    protected void init(PoolConfiguration properties) throws SQLException {        poolProperties = properties;         //make sure the pool is properly configured        checkPoolConfiguration(properties);         //make space for 10 extra in case we flow over a bit        busy = new LinkedBlockingQueue<>();        //busy = new FairBlockingQueue<PooledConnection>();        //make space for 10 extra in case we flow over a bit        if (properties.isFairQueue()) {            idle = new FairBlockingQueue<>();            //idle = new MultiLockFairBlockingQueue<PooledConnection>();            //idle = new LinkedTransferQueue<PooledConnection>();            //idle = new ArrayBlockingQueue<PooledConnection>(properties.getMaxActive(),false);        } else {            idle = new LinkedBlockingQueue<>();        }

从代码中我们发现,jdbc-pool使用了两个队列来存储连接,空闲的和忙碌的分别存放于busyidle 这两个LinkedBlockingQueue,当然,空闲队列会根据配置决定是否使用公平队列。

之后,会根据初始设置大小,来初始池中的连接

PooledConnection[] initialPool = new PooledConnection[poolProperties.getInitialSize()];try {    for (int i = 0; i < initialPool.length; i++) {        initialPool[i] = this.borrowConnection(0, null, null); //don't wait, should be no contention    } //for

borrowConnection方法中,对于初始和后续请求连接调用一样,会判断空闲队列的逻辑,以及配置的信息进行连接的创建

PooledConnection con = idle.poll();         while (true) {             if (size.get() < getPoolProperties().getMaxActive()) {                //atomic duplicate check                if (size.addAndGet(1) > getPoolProperties().getMaxActive()) {                    //if we got here, two threads passed through the first if                    size.decrementAndGet();                } else {                    //create a connection, we're below the limit                    return createConnection(now, con, username, password);                }            } //end if

不满足配置的情况下,会从空闲队列获取

           con = idle.poll(timetowait, TimeUnit.MILLISECONDS);

由于空闲队列采用的是公平队列,不会出现饥饿等待的情况。 createConnection,就会在创建连接后直接进入busy队列。在finally块,又通过returnConnection,将连接释放,进入idle队列。

finally {            //return the members as idle to the pool            for (int i = 0; i < initialPool.length; i++) {                if (initialPool[i] != null) {                    try {this.returnConnection(initialPool[i]);}catch(Exception x){/*NOOP*/}                } //end if            } //for

再来看returnConnection方法,核心代码如下:

  protected void returnConnection(PooledConnection con) {    if (busy.remove(con)) { // 重点看这里    if (((idle.size()>=poolProperties.getMaxIdle()) && !poolProperties.isPoolSweeperEnabled())    || (!idle.offer(con))) { //还有这里    }    release(con);  }

以上,是两个池中最核心的方法逻辑,那么,还有一个问题是,在连接的关闭时,池是如何处理来进行连接的复用呢?

通过Connection的close方法调用时,关闭连接时的调用栈如下:

at org.apache.tomcat.dbcp.dbcp2.PoolableConnection.close(PoolableConnection.java:181)  - locked <0xb59> (a org.apache.tomcat.dbcp.dbcp2.PoolableConnection)  at org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:234)  at org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.close(DelegatingConnection.java:217)  at org.apache.tomcat.dbcp.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:228)

前面介绍jdbc-pool时,曾说过,他支持Interceptor。这里对于close方法的拦截,也是通过定义的Interceptor来实现的。

public class ProxyConnection extends JdbcInterceptor {     protected PooledConnection connection = null;     protected ConnectionPool pool = null;

其对应的iinvoke方法是这样的:

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {            if (compare(CLOSE_VAL,method)) { // 重点看这里,判断如果是close方法,则会调用returnConnection方法            if (connection==null) return null; //noop for already closed.            PooledConnection poolc = this.connection;            this.connection = null;            pool.returnConnection(poolc);            return null;        } else if (compare(TOSTRING_VAL,method)) {            return this.toString();        } else if (compare(GETCONNECTION_VAL,method) && connection!=null) {            return connection.getConnection();        }      }

我们注意,此处使用代理模式,会将各个方法的调用进行拦截,之后判断,如果是普通方法会转给对应的method对象执行,而如果待执行方法是close方法,则该方法不会被执行,而是由Interceptor执行pool的方法,将连接重新放回到池中,以备再次使用。

综上,我们看到,在池中,使用了两个队列,busy 和idle,分别代表忙闲两类连接,在释放连接的时候,即close方法执行的时候,会先把连接从busy队列中移除,同时将该连接再加入到idel队列中。从而实现连接的重复使用。


标签:jdbc,Tomcat,队列,connection,idle,连接池,连接,pool
来源: https://blog.51cto.com/u_15127648/2777727

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有