什么是连接池？
结构
连接池对外提供接口：
- 获得连接
- 归还连接
并暴露客户端可配置的参数：
- 最小空闲连接数
- 最大连接数
在内部则实现功能：
- 连接建立
- 连接心跳保持
- 连接管理
- 空闲连接回收
- 连接可用性检测
- 连接池结构示意图
业务中经常也会用到各种连接池：
- 数据库连接池
- 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方法
