tomcat-jdbc-pool 实现简单分析

什么是连接池?

池,不由自主的会想到水池。

小时候,我们都要去远处的水井挑水,倒进家中的水池里面。这样,每次要用水时,直接从水池中「取」就行了。不用大老远跑去水井打水。

数据库连接池就如此,我们预先准备好一些连接,放到池中。当需要时,就直接获取。而不要每次跟数据库建立一个新的连接。特别对数据库连接这类耗时,耗资源的操作。当连接用完后,再放回池中,供后续使用。

连接池的作用?

避免多次去创建资源。
例如,创建新的数据库连接,500ms轻轻松松就消耗了。建立TCP连接,数据库账号验证等等。这性能消耗起来,可是非常大的。

在稍大的系统内,连接池是必备的。同时,对技术人员要求,对连接池的掌握也是必须的。

tomcat-jdbc-pool的特色

基于jdk1.5后的并发实现。代码简洁,精练。核心的类就2,3个。
对池的控制就在 org.apache.tomcat.jdbc.pool.ConnectionPool 中搞定。

先前有简单看过 dbcp1.x, c3p0等等,代码量真不少,逻辑复杂。
想熟悉池的设计,可以仔细读读tomcat-jdbc-pool,非常快速的入手。在dbcp2的实现时,跟tomcat-jdbc-pool思路一致(完全copy的版本)

对于连接池来说,最基本的特点就是:

  • 有一定的容量,及已经创建好的对象
  • 有「借」有「还」操作的接口

池中「借出」连接是怎么个过程?

jdbc-pool设计有2队列,分别为busyidle,存储「正在使用」和「空闲」的连接。都采用ArrayBlockingQueue以保证线程安全。

当有请求「借」的动作过来时,从idlepoll一个连接,然后将该连接再offerbusy队列中。这是最基本最纯净的思路。

idle连接不够时,内部会再去创建新的连接返回给客户端。

但是,做为「池」必须的职责之一是控制总量,不会任你去增长。

那么,有意思来了,他是怎么控制总量的咧?

我们可以通俗点称『占坑法』(tomcat中也有不少场景采用这方式)。

首先池中有维护连接数总量「计数器」(采用AtomicInteger保证线程安全,每次新增或销毁都会变更)。

『占坑法』就在每次要新创建连接池,先总量计数器+1(占位),再比较是否达到配置的池的最大连接数。如果没有达到,则创建新的;如果已达到了,则等待现有连接释放,再取走。

有点类似,大学时先用本书去抢位置占着。

大致实现代码如下:

public class ConnectionPool {

    //连接数的总量
    private AtomicInteger size = new AtomicInteger(0);
    
    //所有正在使用中的连接
    private BlockingQueue<PooledConnection> busy;

    //所有空闲的连接
    private BlockingQueue<PooledConnection> idle;

    private PooledConnection borrowConnection(int wait, String username, String password) throws SQLException {
        PooledConnection con = idle.poll();
        while (true) {
            if (con != null) {
                 try {
                     busy.offer(con);//我这简化了,在源码中这儿会对连接进行校验、检查或进行连接。
                 } catch(Exception e) {
                 }
                 return con;
            }
    
            if (size.get() < getPoolProperties().getMaxActive()) {
                
                //占坑神技
                if (size.addAndGet(1) > getPoolProperties().getMaxActive()) {
                    //既然没了,那数量也减回去
                    //再去等待其他连接归还回来
                    size.decrementAndGet();
                } else {
                    return createConnection(now, con, username, password);
                }
            }

            try {
                //检查并等待新的空闲连接
                con = idle.poll(timetowait, TimeUnit.MILLISECONDS);
            } catch (InterruptedException ex) {
                //....
            } 
        }
    }
    
}

用完后「归还」连接是怎么个过程?

大致思路跟「借」操作相反落。当然是无视那些「善后」的工作,只关注资源的管理。

但是,做为连接池必须的职责之一,并不真实的断开与数据库的连接。而只是放至idle队列中,供客户端下次再使用。如果有需要或必要肯定会释放,技巧所在。

大致代码如下:

protected void returnConnection(PooledConnection con) {
    if (con != null) {
        try {
            con.lock();
    
            if (busy.remove(con)) {
                //跟允许的最大空闲数比较
                if(idle.size() < poolProperties.getMaxIdle()) {
                    idle.offer(con);
                    //源码中调用release
                    //会根据配置项执行一些校验,例如:testOnReturn为true,则在回收时检查连接是否正常
                    //release(con); 
                }
        } catch(Exception e) {
           //.... 
        } finally {
            con.unlock();
        }
    } //end if
}

当长时间运行后,怎么回收无效的连接?

这是连接池必备的功能之一,类似检查死链或者释放自身过多的资源。比如,在高并发过后,对资源消耗量少时,就释放些不再使用的数据库连接(真实断开),维护合理的空格数量。

看到这应用场景就自然想到,通过后台线程定时扫描。

「对的,就是这样子。」

同样在ConnectionPool这个类文件中的PoolCleaner类。写在同个类文件中,便于用this进行传递数据。不用再去构造个复杂的ConnectionPool对象。

直接上代码,「好代码」就是最好的描述。

public class ConnectionPool {

    /**
     * Initialize the connection pool - called from the constructor
     */
    protected void init(PoolConfiguration properties) throws SQLException {
        initializePoolCleaner(properties);
    }

    public void initializePoolCleaner(PoolConfiguration properties) {        
        if (properties.isPoolSweeperEnabled()) {
            poolCleaner = new PoolCleaner(this, properties.getTimeBetweenEvictionRunsMillis());
            poolCleaner.start(); //只注册一个清理器,并未启动线程。
        } //end if
    }

    /**
    * 检查所有的空闲连接
    */
    public void checkIdle(boolean ignoreMinSize) {

        try {
            if (idle.size()==0) return;
            
            Iterator<PooledConnection> unlocked = idle.iterator();
            while (unlocked.hasNext()) {
                PooledConnection con = unlocked.next();
                try {
                    con.lock();
                    //如果这时已到busy中,则不检查了
                    if (busy.contains(con)) {
                        continue;
                    }

                    release(con);
                    idle.remove(con);

                } finally {
                    con.unlock();
                }
            } //while
        } catch (Exception e) {
            //....
        }

    }

    private static volatile Timer poolCleanTimer = null;
    private static HashSet<PoolCleaner> cleaners = new HashSet<>();

    //注册一个清理器
    private static synchronized void registerCleaner(PoolCleaner cleaner) {
        unregisterCleaner(cleaner);
        cleaners.add(cleaner);
        
        //一堆构造方式。。。
        if (poolCleanTimer == null) {
            ClassLoader loader = Thread.currentThread().getContextClassLoader();
            try {
                Thread.currentThread().setContextClassLoader(ConnectionPool.class.getClassLoader());
                poolCleanTimer = new Timer("PoolCleaner["+ System.identityHashCode(ConnectionPool.class.getClassLoader()) + ":"+
                                           System.currentTimeMillis() + "]", true);
            }finally {
                Thread.currentThread().setContextClassLoader(loader);
            }
        }
        //构造定时扫描器
        //java有内库非常强大,想用啥有啥呀
        poolCleanTimer.scheduleAtFixedRate(cleaner, cleaner.sleepTime,cleaner.sleepTime);
    }

    //真实的处理线程在这儿。。。
    protected static class PoolCleaner extends TimerTask {
        protected WeakReference<ConnectionPool> pool;

        PoolCleaner(ConnectionPool pool, long sleepTime) {
            //弱引用,不了解的可以google下
            this.pool = new WeakReference<>(pool);
        }

        @Override
        public void run() {
            ConnectionPool pool = this.pool.get();
            if (pool == null) {
                stopRunning();
            } else if (!pool.isClosed()) {                
      
                if (pool.getPoolProperties().getMinIdle() < pool.idle.size()) {
                    pool.checkIdle(); //check. check now.
                }
            }
        }

        public void start() {
            registerCleaner(this); //并未启动线程,只是注册一个清理器
        }

        public void stopRunning() {
            unregisterCleaner(this);
        }
    }
}
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,539评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,911评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,337评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,723评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,795评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,762评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,742评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,508评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,954评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,247评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,404评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,104评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,736评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,352评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,557评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,371评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,292评论 2 352

推荐阅读更多精彩内容

  • JDBC概述 在Java中,数据库存取技术可分为如下几类:JDBC直接访问数据库、JDO技术、第三方O/R工具,如...
    usopp阅读 3,534评论 3 75
  • application的配置属性。 这些属性是否生效取决于对应的组件是否声明为Spring应用程序上下文里的Bea...
    新签名阅读 5,364评论 1 27
  • 本文包括传统JDBC的缺点连接池原理自定义连接池开源数据库连接池DBCP连接池C3P0连接池Tomcat内置连接池...
    廖少少阅读 16,738评论 0 37
  • 这些属性是否生效取决于对应的组件是否声明为 Spring 应用程序上下文里的 Bean(基本是自动配置的),为一个...
    发光的鱼阅读 1,423评论 0 14
  • Spring Boot 参考指南 介绍 转载自:https://www.gitbook.com/book/qbgb...
    毛宇鹏阅读 46,801评论 6 342