想知道小蜜蜂连接池性能为啥这么高吗？
相信很多看过小蜜蜂连接池的性能对比图的网友都会觉得惊讶不已，这比号称史上最快的光连接池还快啊，简直不可思议！想知道它为什么那么强悍吗？今天就为大家解开这个谜团。
- 故事还是要从连接池本身说起，连接池技术是一门古老的IT技术，其本质并不复杂，其工作原理类似图书馆，只不过它借出的是连接对象，一般在连接池类内部至少有两条列表，第一条存放是出借对象（类似书架），第二条是等待队列（或隐藏式), 如果对象都被借光了，那么后来的借用者只加入队伍进行等待（等待队列），等其他借者归还，有的人可能等得不耐烦了，中途就离开队列了，这种离开现象叫等待超时。
- 连接释放后,如何将它快速传递给等待者,是一件很有意思的事情,传递的速度直接影响到连接池的性能,常见的有两种处理策略:A放入某个共享队列,再通知等待者去拉取(Tomcat-Jdbc); B:直接传递给等待者(光连接池与小蜜蜂连接池).队列技术在连接池中使用比较常见, 比如TomcatJDBC使用是是闲/忙两条队列，光连接池采用采用的是同步队列（SynchronousQueue）,利用队列的管道推 拉方式 ，在线程之间进行对象传递，代码方式类似
归还线程A:queue.offer(object);等待线程B:queue.poll(time);
假如当前队列中不存在对象，线程B会加入队列背后的等待链中（SynchronousQueue是比较直白式，自定义了节点链，比如LinkedBlockingQueue背后是通过Lock对象，而Lock对象背后则是AbstractQueuedSynchronizer，它内部就包含一条CAS节点链，看类上的介绍就清楚了，不用太细看代码，一般同学只是使用而已，又不搞JDK代码开发， 没有必要研究太深）
再说回连接池,多个线程并发时刻会抢占连接对象,这里会有一个比较常见的现象,举例说明:
A为归还线程,B为等待者线程,C为刚进入的借用者线程,A在归还的时候,会将连接传递给B,但是C也从队列中发现这个刚归还的连接,结果是: B与 C抢占这个连接.
假如B没有抢占到,此时还未超时(timeout),怎么办? 只能继续Poll(实际是再次进入等待链) , 如此反复有可能造成先进入等待者排列在等待链的末端,实际上应该遵循FIFO原则:我先来,理论上,我应该比后来等待先得到连接才对,反复出入列本身就是损耗.
- 说回小蜜蜂连接池,它之所以性能更强，是因为它有一个更强劲的心脏：创新式队列等待技术: 自加入,自离开队列,除非超时和我拿到有效连接,否则我不离开(不移动位置),该技术为连接池领域一次创新, 该池采用并发队列ConcurrentLinkedQueue进行等待和连接传递,此外还有其他一些亮点
1：并发线程控制
学过计算机的同学都知道，CPU是采用分时执行运行线程的，可以想象一下如果有大量并发的线程运行，那么CPU需要再这些线程之间切换运行，会造成较大的损耗。小蜜蜂连接池使用信号量控制并发借用线程数，避免CPU避免过多切换.
举例说明比如CPU的核心数是4个，而连接池的最大的个数是8个, 那么推荐设置并发线程数为4，那么会形成4个被请求使用，4个正在被使用，CPU每个核覆盖2个线程，减少一些不必要的损耗。
2: 精准控制超时
借用线程进入借用方法时候，预先计算超时时刻点，超时时间默认是8秒，超时未取得连接，自动退出。对于借用者线程，可能存在两次等待，第一次等待信号量的许可，第二次等待其他借用者释放的连接, 超时时间是覆盖这两个时间之和。
3：合理利用队列与缓存
1: 大队列等待，小队列交换: 池采用使用信号量控制并发线程, 其背后隐藏一个许可等待队列;小队列处理Wait/Transfer逻辑
2: 单缓存,信号墙外CAS自撸
4：连接的安全保证
1：JDBC物理队对象通过代理分装，不允许调用者直接获取
2：连接在使用完毕后，重置处理，避免脏连接归还到池中（如果出现，关闭老的，则补充一个新）
3：连接有效性判断检查（存活性，闲置超时，持有不用超时）
4：安全性关闭（如果Close方法被多个并发线程关闭，只能有一个关闭成功）
5：是否关闭的三连级检查（Result检查自己的close,还要检查Statement是否关闭，再上一级Connection是否关闭）确保对象的安全性
5：代码极致优化
1：PSCache缓存优化（包括hashKey的计算）
2：去掉一些get/set方法，直接使用对象的属性值
3：一些CmsUpdator不是放对象内部，减少方法调用次数
总之来说,小蜜蜂连接池是一款优秀的开元作品,希望推荐给更多人使用,同时欢迎各位网友提问,或建议,或质疑.
以上是 想知道小蜜蜂连接池性能为啥这么高吗？ 的全部内容， 来源链接： utcz.com/z/517401.html
