一，概述

本人认为在开发过程中，需要挑战更高的阶段和更优的代码，虽然在真正开发工作中，代码质量和按时交付项目功能相比总是无足轻重。但是个人认为开发是一条任重而道远的路。现在本人在网上找到一个自定义连接池的代码，分享给大家。无论是线程池还是db连接池，他们都有一个共同的特征：资源复用，在普通的场景中，我们使用一个连接，它的生命周期可能是这样的：

一个连接，从创建完毕到销毁，期间只被使用一次，当周期结束之后，另外的调用者仍然需要这个连接去做事，就要重复去经历这种生命周期。因为创建和销毁都是需要对应服务消耗时间以及系统资源去处理的，这样不仅浪费了大量的系统资源，而且导致业务响应过程中都要花费部分时间去重复的创建和销毁，得不偿失，而连接池便被赋予了解决这种问题的使命！

二，连接池简要需求

和原始周期相比，连接池多了一下特性：

1，创建并不是真的创建，而是从池子中选出空闲连接。

2，销毁并不是真的销毁，而是将使用中的连接放回池中。

3，真正的创建和销毁由线程池的特性机制来决定。

’

4，保存连接的容器是必不可少的，另外，该容器也要支持连接的添加和移除功能，并保证线程安全。

5，我们需要因为要对连接的销毁做逻辑调整，我们需要重写它的close以及isClosed方法。

6，我们需要有个入口对连接池做管理，例如回收空闲连接，连接池不仅仅只是对Connection生命周期的控制，还应该加入一些特色，例如初始连接数，最大连接数，最小连接数、最大空闲时长以及获取连接的等待时长，这些我们也简单支持一下。

容器连接池的选型：

1，要保证线程安全，我们可以将目标瞄准在JUC包下的神通们，设我们想要的容器为X，那么X不仅需要满足基本的增删改查功能，而且也要提供获取超时功能，这是为了保证当池内长时间没有空闲连接时不会导致业务阻塞，即刻熔断。另外，x需要满足双向操作，这是为了连接池可以识别出饱和的空闲连接，方便回收操作。

综上所述，LinkedBlockingDeque是最合适的选择，它使用InterruptibleReentrantLock来保证线程安全，使用Condition来做获取元素的阻塞，另外支持双向操作。

另外，我们可以将连接池分为3个类型：

工作池：存在正在被使用的连接。

空闲池：存在空闲连接。

回收池：已经被回收（物理关闭）的连接。

其中，工作池和回收池大可不必用双向队列，或许用单向队列或者set都可以代替之：

private LinkedBlockingQueue<HoneycombConnection> workQueue;
private LinkedBlockingQueue<HoneycombConnection> idleQueue;
private LinkedBlockingQueue<HoneycombConnection> freezeQueue;

Connection 的装饰

连接池的输出是Connection，它代表着一个db连接，上游服务使用它做完操作后，会直接调用它的close方法来释放连接，而我们必须做的是在调用者无感知的情况下改变它的关闭逻辑，当调用close的方法时，我们将它放回空闲队列中，保证其的可复用性！

因此，我们需要对原来的Connection做装饰，其做法很简单，但是很累，这里新建一个类来实现Connection接口，通过重写所有的方法来实现一个“可编辑”的Connection，我们称之为Connection的装饰者：

public class HoneycombConnectionDecorator implements Connection{

    protected Connection connection;

    protected HoneycombConnectionDecorator(Connection connection) {
        this.connection = connection;
    }

    此处省略对方法实现的三百行代码...
}

之后，我们需要新建一个自己的Connection来继承这个装饰者，并重写相应的方法：

public class HoneycombConnection extends HoneycombConnectionDecorator implements HoneycombConnectionSwitcher{
    @Override
    public void close() { do some things }

    @Override
    public boolean isClosed() throws SQLException { do some things }    

    省略...
}

DataSource的重写

DataSource是JDK为了更好的统合和管理数据源而定义出的一个规范，获取连接的入口，方便我们在这一层更好的扩展数据源（例如增加特殊属性），使我们的连接池的功能更加丰富，我们需要实现一个自己的DataSource：

public class HoneycombWrapperDatasource implements DataSource{
    protected HoneycombDatasourceConfig config;
    省略其它方法的实现...
    @Override
    public Connection getConnection() throws SQLException {
        return DriverManager.getConnection(config.getUrl(), config.getUser(), config.getPassword());
    }

    @Override
    public Connection getConnection(String username, String password) throws SQLException {
        return DriverManager.getConnection(config.getUrl(), username, password);
    }
    省略其它方法的实现...
}

我们完成了对数据源的实现，但是这里获取连接的方式是物理创建，我们需要满足池化的目的，需要重写HoneycombWrapperDatasource中的连接获取逻辑，做法是创建一个新的类对父类方法重写：

public class HoneycombDataSource extends HoneycombWrapperDatasource{
    private HoneycombConnectionPool pool;
    @Override
    public Connection getConnection() throws SQLException {
        这里实现从pool中取出连接的逻辑
    }
    省略...
}

特性扩展

在当前结构体系下，我们的连接池逐渐浮现出了雏形，但远远不够的是，我们需要在此结构下可以做自由的扩展，使连接池对连接的控制更加灵活，因此我们可以引入特性这个概念，它允许我们在其内部访问连接池，并对连接池做一系列的扩展操作：

public abstract class AbstractFeature{
    public abstract void doing(HoneycombConnectionPool pool);
}

AbstractFeature抽象父类需要实现doing方法，我们可以在方法内部实现对连接池的控制，其中一个典型的例子就是对池中空闲连接左回收：

public class CleanerFeature extends AbstractFeature{
    @Override
    public void doing(HoneycombConnectionPool pool) {
        这里做空闲连接的回收
    }
}

三，落实计划

原文地址：https://www.cnblogs.com/boanxin/p/10962053.html