连接池的用途实际上有过开发经验的朋友都已经比较清楚了，当资源对象的创建/销毁比较耗时的场景下，可以通过"池化"技术，达到资源的复用，以此来减少系统的开销、增大系统吞吐量，比如数据库连接池、线程池、Redis 连接池等都是使用的该方式，而我们在开发场景中使用较为广泛的 Jedis 就是使用了 GenericObjectPool 作为它底层的连接池实现。
图片
业务模块通过 BorrowObject 方法从空闲连接队列中获取空闲连接，最长会等待 maxWaitMillis 毫秒，如果拿不到则走 Create。
把连接重新放回到 IdleObjects 队列中。
图片
图片
而 RedisConnectionFactory 的其中一个实现就是 JedisConnectionFactory，其中就包含了 Pool。
图片
而 Pool 本身内部就能看到我们真正的主角。
图片
捋一下其中的关系，我们常用的 Spring-Data-Redis 的 Jedis 实现最终是通过以下的层级结构来使用 GenericObjectPool 的。
图片
如上述类结构所示，GenericObjectPool 都是在 GenericObjectPoolConfig 或 BaseObjectPoolConfig 中进行配置相关参数的，其中核心参数以及默认值如下：
图片
上图对这些参数按颜色进行了一个归类：
图片
这里需要注意的是，虽然 GenericObjectPool 支持我们配的参数较多，但是 Spring-Data-Redis 将这部分参数收敛了，具体可供我们修改的只有表格上面的这部分内容，其他参数，有一部分在 JedisPoolConfig 类中，继承了 GenericObjectPoolConfig 进行了修改，比如 Spring-Data-Redis 就修改了以下参数的默认值。
testWhileIdle=true
minEvictableIdleTimeMillis=60000
timeBetweenEvictinotallow=30000
numTestsPerEvictinotallow=-1
本文只会针对方法的一些核心链路进行说明，如想知道更多细节，针对源码解析的可以在网上搜索其他相关文章或是到我的参考链接里进行翻看。
该方法用于从连接池中获取一个空闲对象，它有可能是从空闲池中直接获取的，或是直接创建出来的，如果第一次从空闲对象中没有获取到，会走创建后重新获取，此时如果对象池目前配置的 BlockWhenExhausted=true，那么就会受 maxWaitMillis 参数所配置的超时时间所控制，如果超过了超时时间，都没拿到一个空闲的对象，则会直接抛出异常。
当获取到一个对象后，由于对象池中往往存放的是诸如数据库连接、Redis 连接等创建时较为耗时的资源，但是因为连接本身是复用的，如果 MySQL/Redis Server 端如果因为某些原因断开/释放了该链接，那么此时拿到的对象就是个无效的对象，因此在 borrowObject 阶段会判定，如果：
testOnBorrow=true || (create && testOnCreate=true)就会走到：
factory.validateObject这里如何进行 validateObject 的，是由上层使用对象池的场景所决定的，比如在 Jedis 场景中，会向 Redis Server 发送一个 Ping 命令，如果 Server 返回了 Pong，则认为该连接仍然有效，可以给业务层使用。
但是！！！！！！
线上环境千万不要配置 testOnBorrow=true 或是 testOnCreate=true。
每个对象的获取都需要先校验再拿，会大大增加单次请求的 RT。
ReturnObject
实际上 testOnReturn 的使用场景与上述 borrowObject 时的 testOnBorrow 是类似的，只是testOnReturn就是一个归还对象的操作。同理，线上千万不要配置 testOnReturn=true。
对象池中维护了一个结构为 LinkedBlockingDeque，名为 IdleObjects 的对象用于维护空闲对象队列，且是否归或销毁的判断逻辑如下：
final int maxIdleSave = getMaxIdle();if (isClosed() || maxIdleSave > -1 && maxIdleSave <= idleObjects.size()) { ...销毁对象}else{ ...返还至idleObjects}如果：
或
则对象会被销毁，否则对象会重新回到 IdleObjects 中。
当 timeBetweenEvictionRunsMillis 配置 >0 时，在 GenericObjectPool 所继承的基类中，会启一个周期性执行的线程，它的执行周期就是 timeBetweenEvictionRunsMillis 的值。
当空闲对象过多，对于客户端或服务端的 TCP 连接维护来讲，本身就是一个开销，因此，需要有一个规则，当有一些对象实在太空闲了，就把它们踢掉。
首先会从空闲对象列表中挑选出一部分对象，而这个挑选过程本身也有一个规则，它受 numTestsPerEvictionRun 参数控制。
当 numTestsPerEvictionRun>0，会挑选出 numTestsPerEvictionRun 数量的空闲连接进行检查。
当 numTestsPerEvictionRun<0 时，首先会对 numTestsPerEvictionRun 取绝对值，再然后挑选出空闲数量 /numTestsPerEvictionRun 绝对值的数量进行检查，举个例子，如果 numTestsPerEvictinotallow=-2，就会挑选出一半进行检查。
本身驱逐检查的实现方式是支持自定义的，也就是 evictionPolicy 参数，但是往往只会选择用默认的实现，也就是 DefaultEvictionPolicy，它的驱逐检查策略如下：
if ((config.getIdleSoftEvictTime() < underTest.getIdleTimeMillis() && config.getMinIdle() < idleCount) || config.getIdleEvictTime() < underTest.getIdleTimeMillis()) { return true;}return false;underTest 为被检查对象，当存在以下场景时，满足驱逐检查规则，会触发驱逐。
underTest 的空闲时间 > softMinEvictableIdleTimeMillis 且当前空闲对象数量 > minIdle 或 underTest 的空闲时间 > minEvictableIdleTimeMillis。
Tips：有一些好奇的同学可能会问，对象的空闲时间是怎么算的？
池中的对象本身会维护一个 lastReturnTime 的时间戳，它会随着对象每一次 returnObject 时进行更新，当获取对象空闲时间时，只要它还是在空闲对象中，那么用当前时间戳 -lastReturnTime 就是认为该对象的空闲时间。
由于前面提到过，不能配置 testOnBorrow 和 testOnReturn，那么如果 Server 端的链接直接断开了，怎么能保证池中对象的有效性呢？如果让调用端调用时再触发，会不会太晚了呢？这时候就有个参数 testWhileIdle，当此参数打开时，就代表会在对象空闲时进行对象可用性检查，具体代码如下：
if (evict) { destroy(underTest); destroyedByEvictorCount.incrementAndGet();} else { if (testWhileIdle) { try { factory.activateObject(underTest); } catch (final Exception e) { destroy(underTest); destroyedByEvictorCount.incrementAndGet(); } }}这里隐掉了一些相关的非核心逻辑，这里可以看到 testWhileIdle 的保活机制实际上和 evict 是配套使用的，如果被检查对象需要被驱逐，也就是 evict=true，则会直接 destory 对象，否则它会判定 testWhileIdle 的状态，此时如果 testWhileIdle=true，那么就会激活一下对象，具体激活的方式是由使用对象池的上层工厂所决定的。
testOnBorrow、testOnReturn、testOnCreate。这几个基本看名字就知道是什么意思了，在前面讲 borrowObject 和 returnObject 的时候也有提到，还有一个相对比较特别的是：
testWhileIdle。
该参数目的是为了对象在空闲期间可以进行检查，而它的触发实际上是和 evict(定期驱逐机制)联合起来进行使用的。
本身 GenericObjectPool 默认会把自己的一些参数通过 JMX 的方式进行注册，那么我们可以通过 Jvisualvm 进行查看，或是通过 Arthas，输入如下命令：
mbean org.apache.commons.pool2:type=GenericObjectPool,name=pool-redisConnectionFactory可以获取到对象池当前的一些属性，如下图：
图片
其中对于优化比较有用的就是 CreatedCount（创建对象的数量）、DestoryedCount（对象销毁的对象）、DestoryedByEvictorCount（因为驱逐机制而被销毁的对象数量）。
上述文章以 Jedis 为引，分析了 GenericObjectPool 连接池的底层原理以及 Jedis 是如何使用该连接池的，并且结合了 Arthas 分享了一个简单的排障方式，实际上如果知道了 GenericObjectPool 连接池的原理，其他连接池也是大同小异，本文希望抛砖引玉，带大家对于连接池的底层实现有个基本概念，相信以后遇到此类问题也会有分析的思路，不再迷茫~
本文链接：http://www.28at.com/showinfo-26-54175-0.htmlJedis连接池究竟是何物
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号