关于mybatis:从零开始手写-mybatis-三jdbc-pool-从零实现数据库连接池

前景回顾

第一节 从零开始手写 mybatis（一）MVP 版本 中咱们实现了一个最根本的能够运行的 mybatis。

第二节 从零开始手写 mybatis（二）mybatis interceptor 插件机制详解

本节咱们一起来看一下如何实现一个数据库连接池。

为什么须要连接池？

数据库连贯的创立是十分耗时的一个操作，在高并发的场景，如果每次对于数据库的拜访都从新创立的话，老本太高。

于是就有了“池化”这种解决方案。

这种计划在咱们日常生活中也是亘古未有，比方资金池，需要池，乃至人力资源池。

思维都是共通的。

咱们本节一起来从零实现一个繁难版本的数据库连接池，不过麻雀虽小，五脏俱全。

将从以下几个方面来开展：

（1）一般的数据库连贯创立

（2）主动适配 jdbc 驱动

（3）指定大小的连接池创立

（4）获取连贯时增加超时检测

（5）增加对于连贯有效性的检测

一般的数据库连贯创立

这种就是最一般的不实用池化的实现。

实现

mybatis 默认其实也是这种实现，不过咱们在这个根底上做了一点优化，那就是能够依据 url 主动适配 driverClass。

public class UnPooledDataSource extends AbstractDataSourceConfig {

    @Override
    public Connection getConnection() throws SQLException {DriverClassUtil.loadDriverClass(super.driverClass, super.jdbcUrl);

        return DriverManager.getConnection(super.getJdbcUrl(),
                super.getUser(), super.getPassword());
    }

}

主动适配

这个个性次要是参考阿里的 druid 连接池实现，在用户没有指定驱动类时，主动适配。

外围代码如下：

/**
 * 加载驱动类信息
 * @param driverClass 驱动类
 * @param url 连贯信息
 * @since 1.2.0
 */
public static void loadDriverClass(String driverClass, final String url) {ArgUtil.notEmpty(url, url);
    if(StringUtil.isEmptyTrim(driverClass)) {driverClass = getDriverClassByUrl(url);
    }
    try {Class.forName(driverClass);
    } catch (ClassNotFoundException e) {throw new JdbcPoolException(e);
    }
}

如何依据 url 获取启动类呢？实际上就是一个 map 映射。

/**
 * 依据 URL 获取对应的驱动类
 *
 * 1. 禁止 url 为空
 * 2. 如果未找到，则间接报错。* @param url url
 * @return 驱动信息
 */
private static String getDriverClassByUrl(final String url) {ArgUtil.notEmpty(url, "url");
    for(Map.Entry<String, String> entry : DRIVER_CLASS_MAP.entrySet()) {String urlPrefix = entry.getKey();
        if(url.startsWith(urlPrefix)) {return entry.getValue();
        }
    }
    throw new JdbcPoolException("Can't auto find match driver class for url: " + url);
}

其中 DRIVER_CLASS_MAP 映射如下：

池化实现

接下来咱们依据指定的大小创立一个初始化的连接池。

定义池化的相干信息

咱们首先定义一个接口：

/**
 * 池化的连接池
 * @since 1.1.0
 */
public interface IPooledConnection extends Connection {


    /**
     * 是否忙碌
     * @since 1.1.0
     * @return 状态
     */
    boolean isBusy();

    /**
     * 设置状态
     * @param busy 状态
     * @since 1.1.0
     */
    void setBusy(boolean busy);

    /**
     * 获取真正的连贯
     * @return 连贯
     * @since 1.1.0
     */
    Connection getConnection();

    /**
     * 设置连贯信息
     * @param connection 连贯信息
     * @since 1.1.0
     */
    void setConnection(Connection connection);

    /**
     * 设置对应的数据源
     * @param dataSource 数据源
     * @since 1.5.0
     */
    void setDataSource(final IPooledDataSourceConfig dataSource);

    /**
     * 获取对应的数据源信息
     * @return 数据源
     * @since 1.5.0
     */
    IPooledDataSourceConfig getDataSource();}

这里咱们间接继承了 Connection 接口，实现时全副对 Connection 做一个代理。

内容较多，然而比较简单，此处不再赘述。

连接池初始化

依据配置初始化大小：

/**
 * 初始化连接池
 * @since 1.1.0
 */
private void initJdbcPool() {
    final int minSize = super.minSize;
    pool = new ArrayList<>(minSize);
    for(int i = 0; i < minSize; i++) {IPooledConnection pooledConnection = createPooledConnection();
        pool.add(pooledConnection);
    }
}

createPooledConnection 内容如下：

/**
 * 创立一个池化的连贯
 * @return 连贯
 * @since 1.1.0
 */
private IPooledConnection createPooledConnection() {Connection connection = createConnection();
    IPooledConnection pooledConnection = new PooledConnection();
    pooledConnection.setBusy(false);
    pooledConnection.setConnection(connection);
    pooledConnection.setDataSource(this);
    return pooledConnection;
}

咱们应用 busy 属性，来标识以后连贯是否可用。

新创建的连贯默认都是可用的。

连贯的获取

整体流程如下：

（1）池中有连贯，间接获取

（2）池中没有连贯，且没达到最大的大小，能够创立一个，而后返回

（3）池中没有连贯，然而曾经达到最大，则进行期待。

@Override
public synchronized Connection getConnection() throws SQLException {
    //1. 获取第一个不是 busy 的连贯
    Optional<IPooledConnection> connectionOptional = getFreeConnectionFromPool();
    if(connectionOptional.isPresent()) {return connectionOptional.get();
    }
    //2. 思考是否能够扩容
    if(pool.size() >= maxSize) {
        //2.1 立即返回
        if(maxWaitMills <= 0) {throw new JdbcPoolException("Can't get connection from pool!");
        }
        //2.2 循环期待
        final long startWaitMills = System.currentTimeMillis();
        final long endWaitMills = startWaitMills + maxWaitMills;
        while (System.currentTimeMillis() < endWaitMills) {Optional<IPooledConnection> optional = getFreeConnectionFromPool();
            if(optional.isPresent()) {return optional.get();
            }
            DateUtil.sleep(1);
            LOG.debug("期待连接池偿还，wait for 1 mills");
        }
        //2.3 期待超时
        throw new JdbcPoolException("Can't get connection from pool, wait time out for mills: " + maxWaitMills);
    }
    //3. 扩容（临时只扩容一个）LOG.debug("开始扩容连接池大小，step: 1");
    IPooledConnection pooledConnection = createPooledConnection();
    pooledConnection.setBusy(true);
    this.pool.add(pooledConnection);
    LOG.debug("从扩容后的连接池中获取连贯");
    return pooledConnection;
}

getFreeConnectionFromPool() 外围代码如下：

间接获取一个不是忙碌状态的连贯即可。

/**
 * 获取闲暇的连贯
 * @return 连贯
 * @since 1.3.0
 */
private Optional<IPooledConnection> getFreeConnectionFromPool() {for(IPooledConnection pc : pool) {if(!pc.isBusy()) {pc.setBusy(true);
            LOG.debug("从连接池中获取连贯");
            return Optional.of(pc);
        }
    }
    // 空
    return Optional.empty();}

连贯的偿还

以前 connection 的偿还是间接将连贯敞开，这里咱们做了一个重载。

只是调整下对应的状态即可。

@Override
public void returnConnection(IPooledConnection pooledConnection) {
    // 验证状态
    if(testOnReturn) {checkValid(pooledConnection);
    }

    // 设置为不忙碌
    pooledConnection.setBusy(false);
    LOG.debug("偿还连贯，状态设置为不忙碌");
}

连贯的有效性

池中的连贯存在有效的可能，所以须要咱们对其进行定期的检测。

配置解说

验证的机会是一门学识，咱们能够在获取时检测，能够在偿还时检测，然而二者都比拟耗费性能。

比拟好的形式是在闲暇的时候进行校验。

配置次要参考 druid 的配置，对应的接口如下：

/**
 * 设置验证查问的语句
 *
 * 如果这个值为空，那么 {@link #setTestOnBorrow(boolean)}
 * {@link #setTestOnIdle(boolean)}}
 * {@link #setTestOnReturn(boolean)}
 * 都将有效
 * @param validQuery 验证查问的语句
 * @since 1.5.0
 */
void setValidQuery(final String validQuery);
/**
 * 验证的超时秒数
 * @param validTimeOutSeconds 验证的超时秒数
 * @since 1.5.0
 */
void setValidTimeOutSeconds(final int validTimeOutSeconds);
/**
 * 获取连贯时进行校验
 *
 * 备注：影响性能
 * @param testOnBorrow 是否
 * @since 1.5.0
 */
void setTestOnBorrow(final boolean testOnBorrow);
/**
 * 偿还连贯时进行校验
 *
 * 备注：影响性能
 * @param testOnReturn 偿还连贯时进行校验
 * @since 1.5.0
 */
void setTestOnReturn(final boolean testOnReturn);
/**
 * 空闲的时候进行校验
 * @param testOnIdle 空闲的时候进行校验
 * @since 1.5.0
 */
void setTestOnIdle(final boolean testOnIdle);
/**
 * 空闲时进行校验的工夫距离
 * @param testOnIdleIntervalSeconds 工夫距离
 * @since 1.5.0
 */
void setTestOnIdleIntervalSeconds(final long testOnIdleIntervalSeconds);

约定优于配置

所有的属性都反对用户自定义，以满足不同的利用场景。

同时也秉承着默认的配置就是最罕用的配置，默认的配置如下：

/**
 * 默认验证查问的语句
 * @since 1.5.0
 */
public static final String DEFAULT_VALID_QUERY = "select 1 from dual";

/**
 * 默认的验证的超时工夫
 * @since 1.5.0
 */
public static final int DEFAULT_VALID_TIME_OUT_SECONDS = 5;

/**
 * 获取连贯时，默认不校验
 * @since 1.5.0
 */
public static final boolean DEFAULT_TEST_ON_BORROW = false;

/**
 * 偿还连贯时，默认不校验
 * @since 1.5.0
 */
public static final boolean DEFAULT_TEST_ON_RETURN = false;

/**
 * 默认空闲的时候，进行校验
 *
 * @since 1.5.0
 */
public static final boolean DEFAULT_TEST_ON_IDLE = true;

/**
 * 1min 主动校验一次
 *
 * @since 1.5.0
 */
public static final long DEFAULT_TEST_ON_IDLE_INTERVAL_SECONDS = 60;

检测的实现

这里我参考了一篇 statckOverflow 的文章，其实还是应用 Connection#isValid 验证比较简单。

/**
 * https://stackoverflow.com/questions/3668506/efficient-sql-test-query-or-validation-query-that-will-work-across-all-or-most
 *
 * 真正反对规范的，间接应用 {@link Connection#isValid(int)} 验证比拟适合
 * @param pooledConnection 连接池信息
 * @since 1.5.0
 */
private void checkValid(final IPooledConnection pooledConnection) {if(StringUtil.isNotEmpty(super.validQuery)) {Connection connection = pooledConnection.getConnection();
        try {
            // 如果连贯有效，从新申请一个新的代替
            if(!connection.isValid(super.validTimeOutSeconds)) {LOG.debug("Old connection is inValid, start create one for it.");
                Connection newConnection = createConnection();
                pooledConnection.setConnection(newConnection);
                LOG.debug("Old connection is inValid, finish create one for it.");
            }
        } catch (SQLException throwables) {throw new JdbcPoolException(throwables);
        }
    } else {LOG.debug("valid query is empty, ignore valid.");
    }
}

空闲时的线程解决

咱们为了不影响性能，独自为空闲的连贯检测开一个线程。

在初始化的创立：

/**
 * 初始化闲暇时测验
 * @since 1.5.0
 */
private void initTestOnIdle() {if(StringUtil.isNotEmpty(validQuery)) {ScheduledExecutorService idleExecutor = Executors.newSingleThreadScheduledExecutor();
        idleExecutor.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {testOnIdleCheck();
            }
        }, super.testOnIdleIntervalSeconds, testOnIdleIntervalSeconds, TimeUnit.SECONDS);
        LOG.debug("Test on idle config with interval seonds:" + testOnIdleIntervalSeconds);
    }
}

testOnIdleCheck 实现如下：

/**
 * 验证所有的闲暇连贯是否无效
 * @since 1.5.0
 */
private void testOnIdleCheck() {LOG.debug("start check test on idle");
    for(IPooledConnection pc : this.pool) {if(!pc.isBusy()) {checkValid(pc);
        }
    }
    LOG.debug("finish check test on idle");
}

开源地址

所有源码均已开源：

jdbc-pool

应用形式和常见的连接池一样。

maven 引入

<dependency>
    <groupId>com.github.houbb</groupId>
    <artifactId>jdbc-pool</artifactId>
    <version>1.5.0</version>
</dependency>

测试代码

PooledDataSource source = new PooledDataSource();
source.setDriverClass("com.mysql.jdbc.Driver");
source.setJdbcUrl("jdbc:mysql://127.0.0.1:3306/test?useUnicode=true&characterEncoding=utf-8");
source.setUser("root");
source.setPassword("123456");
source.setMinSize(1);

// 初始化
source.init();

Connection connection = source.getConnection();
System.out.println(connection.getCatalog());

Connection connection2 = source.getConnection();
System.out.println(connection2.getCatalog());

日志

[DEBUG] [2020-07-18 10:50:54.536] [main] [c.g.h.t.p.d.PooledDataSource.getFreeConnection] - 从连接池中获取连贯
test
[DEBUG] [2020-07-18 10:50:54.537] [main] [c.g.h.t.p.d.PooledDataSource.getConnection] - 开始扩容连接池大小，step: 1
[DEBUG] [2020-07-18 10:50:54.548] [main] [c.g.h.t.p.d.PooledDataSource.getConnection] - 从扩容后的连接池中获取连贯
test

小结

到这里，一个简略版本的连接池就曾经实现了。

常见的连接池，比方 dbcp/c3p0/druid/jboss-pool/tomcat-pool 其实都是相似的。

万变不离其宗，实现只是一种思维的差异化示意而已。

然而有哪些有余呢？

性能方面，咱们为了简略，都是间接应用 synchronized 保障并发平安，这样性能会绝对于乐观锁，或者是无锁差一些。

自定义方面，比方 druid 能够反对用户自定义拦截器，增加注入避免 sql 注入，耗时统计等等。

页面治理，druid 比拟优异的一点就是自带页面治理，这一点对于日常保护也比拟敌对。