为了提高客户端程序的并发，减少线程等待时间，通常会选择使用连接池：因为建立TCP连接的过程是需要经过多次握手的，这个过程是需要业务线程等待的。采用连接池预先建立几个连接的方式来提高程序并发。
重要的一点：
连接池的设计其实是和应用层协议的设计紧密相关的，目前的应用层协议基本可以分为两种时序类型：
1 请求--接收响应--下一个请求-下一个响应...类型，典型的协议是HTTP1.X、JDBC
2 请求--请求--...接收响应--接收响应...类型，典型的协议有HTTP2、Redis管道、MQ相关协议等
不同的时序类型的协议，连接池的设计有很大的不同。
本篇先讲解上述的类型1类型连接池设计思想。
大概思想如下：
# 一个有大小限制的队列来存储连接
# 设计几个参数：连接池队列大小；最大连接数；最大连接数可以大于连接池队列大小
# 一把读锁，读锁用来保证多个业务线程同时获取连接的时候不会获取到同一个连接对象，即保证一个连接只能被一个线程取走
# 一个条件锁，条件来指示连接池队列中可用的连接个数，当队列中没有可用连接的时候，判断连接数是否超出最大连接数，如果没有超出最大连接数，则创建新的连接，然后直接返回给业务线程使用；如果已经达到了最大连接数，业务线程等待在条件锁的阻塞队列上（可以设置业务线程阻塞时间，实现获取连接超时功能）
# 业务线程获取到连接，按照协议规定的时序，即 “请求--等待响应” 的方式使用连接，这个等待过程可以是同步或者异步等待，但是在响应未到达之前，不允许释放连接到连接池
# 获取到连接的业务线程连接使用完毕，调用释放连接方法，来释放连接到连接池队列，同时通知条件锁来释放等待连接的其他业务线程。需要注意，这里只是释放连接到连接池，不关闭连接，此外这个过程应该也加个写锁，保证连接有序释放
# 开启额外的线程定时监测线程池中的空闲连接，空闲时间过长的连接及时释放掉，防止占用服务端连接资源
再次强调：由于这类协议的设计原因，必须要按“请求-响应-请求-响应”的时序来，所以未完成响应之前业务线程不允许释放连接到连接池，原因：假如一个业务线程发送完数据包就释放连接到连接池，再未处理完第一个响应的时候其他业务线程又得到了这个连接又去发请求，由于服务端的业务处理是并行的，很可能会发生第二个请求的响应在第一个请求的响应之前到达客户端，这样就发生了错误！
(完)
