如何实现一个Java链接池？

什么是链接池？

结构

链接池对外提供接口：

• 得到链接
• 归还链接

并暴露客户端可配置的参数：

• 最小空闲链接数
• 最大链接数

在内部则实现功能：

• 链接创建

• 链接心跳保持

• 链接管理

• 空闲链接回收

• 链接可用性检测

• 链接池结构示意图

业务中常常也会用到各类链接池：

• 数据库链接池
• Redis链接池
• HTTP链接池

客户端SDK是否基于链接池

在使用三方客户端进行网络通讯时，首要肯定客户端SDK是不是基于链接池技术实现的。

若客户端SDK没有使用链接池，而直接是TCP链接，就须要考虑每次创建TCP链接的开销，由于TCP基于字节流，若在多线程下对同一链接操做，就有线程安全隐患。

TCP链接的客户端SDK，对外提供API的方式

链接池和链接分离的API

有一个XXXPool类负责链接池实现：

• 先从其得到链接XXXConnection
• 再用所获链接请求服务端
• 完成后归还链接

XXXPool必须是线程安全的，可并发获取和归还链接，而XXXConnection是非线程安全的。 对应到链接池结构示意图，XXXPool就是右边链接池那个框，左边客户端是咱们本身的代码。

内部带有链接池的API

对外提供一个XXXClient类，经过该类可直接请求服务端。该类内部维护了链接池，SDK使用者无需考虑链接的获取和归还问题。 XXXClient是线程安全的。对应到链接池结构示意图中，整个API就是蓝框。

非链接池的API

通常命名为XXXConnection，以区分其是基于链接池or单链接，而不建议命名为XXXClient。直接链接方式的API基于单一链接，每次使用都须要建立和断开链接，性能通常，且一般不是线程安全的。对应到链接池的结构示意图中，这种形式至关于没有右边链接池那个框，客户端直接链接服务端建立链接。

不排除有一些客户端特立独行，所以在使用三方SDK时，必定要

• 查看官方文档了解其最佳实践
• Stackoverflow搜索XXX threadsafe/singleton
• 看源码，直到定位到原始Socket来判断Socket和客户端API的对应关系

使用SDK的最佳实践

分离方式

链接池自己通常是线程安全的，可复用。每次使用须要从链接池获取链接，使用后归还，归还的工做由使用者负责。

内置链接池

大多数中间件、数据库的客户端SDK都会支持链接池，SDK负责链接的获取和归还，使用的时候直接复用客户端。

SDK没有实现链接池

那一般不是线程安全的，并且短链接的方式性能不会很高，使用的时候须要考虑是否本身封装一个链接池。

下面看Jedis类到底属于哪一种类型的API，直接在多线程环境下复用一个链接会产生什么问题，以及如何用最佳实践来修复这个问题。

首先，向Redis初始化2组数据，Key=a、Value=1，Key=b、Value=2：

@PostConstruct
public void init() {
    try (Jedis jedis = new Jedis("127.0.0.1", 6379)) {
        Assert.isTrue("OK".equals(jedis.set("a", "1")), "set a = 1 return OK");
        Assert.isTrue("OK".equals(jedis.set("b", "2")), "set b = 2 return OK");
    }
}
复制代码

而后，启动两个线程，共享操做同一个Jedis实例，每个线程循环1000次，分别读取Key为a和b的Value，判断是否分别为1和2：

Jedis jedis = new Jedis("127.0.0.1", 6379);
new Thread(() -> {
    for (int i = 0; i < 1000; i++) {
        String result = jedis.get("a");
        if (!result.equals("1")) {
            log.warn("Expect a to be 1 but found {}", result);
            return;
        }
    }
}).start();
new Thread(() -> {
    for (int i = 0; i < 1000; i++) {
        String result = jedis.get("b");
        if (!result.equals("2")) {
            log.warn("Expect b to be 2 but found {}", result);
            return;
        }
    }
}).start();
TimeUnit.SECONDS.sleep(5);
复制代码

执行程序屡次，能够看到日志中出现了各类奇怪的异常信息，有的是读取Key为b的Value读取到了1，有的是流非正常结束，还有的是链接关闭异常：

//错误1
[14:56:19.069] [Thread-28] [WARN ] [.t.c.c.redis.JedisMisreuseController:45  ] - Expect b to be 2 but found 1
//错误2
redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream.
	at redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
	at redis.clients.jedis.util.RedisInputStream.readLine(RedisInputStream.java:50)
	at redis.clients.jedis.Protocol.processError(Protocol.java:114)
	at redis.clients.jedis.Protocol.process(Protocol.java:166)
	at redis.clients.jedis.Protocol.read(Protocol.java:220)
	at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:318)
	at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:255)
	at redis.clients.jedis.Connection.getBulkReply(Connection.java:245)
	at redis.clients.jedis.Jedis.get(Jedis.java:181)
	at org.geekbang.time.commonmistakes.connectionpool.redis.JedisMisreuseController.lambda$wrong$1(JedisMisreuseController.java:43)
	at java.lang.Thread.run(Thread.java:748)
//错误3
java.io.IOException: Socket Closed
	at java.net.AbstractPlainSocketImpl.getOutputStream(AbstractPlainSocketImpl.java:440)
	at java.net.Socket$3.run(Socket.java:954)
	at java.net.Socket$3.run(Socket.java:952)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.Socket.getOutputStream(Socket.java:951)
	at redis.clients.jedis.Connection.connect(Connection.java:200)
	... 7 more
复制代码

让咱们分析一下Jedis类的源码，搞清楚其中原因吧。

BinaryClient封装了各类Redis命令 都是调用其父类Connection方法，使用Protocol类发送命令 Protocol类的sendCommand方法 发送命令时是直接操做RedisOutputStream写字节。

在多线程环境下复用Jedis对象，其实就是在复用RedisOutputStream。若是多个线程在执行操做，那么既没法确保整条命令以一个原子操做写入Socket，也没法确保写入后、读取前没有其余数据写到远端。 这就能解释了为什么多线程下使用Jedis对象操做Redis会出现各类问题：

• 写操做互相干扰，多条命令交织，必然是非法的Redis命令，则Redis会关闭客户端链接，致使链接断开
• 线程1和2前后写入get a和get b请求，Redis也返回了值1和2，可是线程2先读取了数据1就会出现数据错乱的问题。

那么如何修复呢？ 使用Jedis提供的线程安全的类JedisPool来得到Jedis的实例。JedisPool做为链接池，能够声明为static 被多线程共享。注意使用try-with-resources模式。 这样使用后代码再也不有线程安全问题。最好再经过shutdownhook，在程序退出以前关闭JedisPool：

@PostConstruct
public void init() {
    Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        jedisPool.close();
    }));
}
复制代码

Jedis#close

若Jedis是从链接池获取的话，则close方法会调用链接池的return方法归还链接：

若是不是，则直接关闭链接，其最终调用Connection类的disconnect方法来关闭TCP链接： 可见Jedis可独立使用，也可配合链接池（JedisPool）

JedisPool

• JedisPool继承JedisPoolAbstract又继承抽象类Pool，Pool内部持有Apache Common的GenericObjectPool。

因此JedisPool的链接池其实就是直接复用的GenericObjectPool，并无本身实现一套池子。

综上，Jedis API属于链接池和链接分离的API，JedisPool是线程安全的链接池，Jedis是非线程安全的单一链接。