我是在17年无意看到一条关于"光连接池与Druid的"性能PK的新闻,也是那个时候才知道OSChina这个网站(当时还以为它是个小网站),当时用光连接池程序跑了一下,我当时非常震惊:这世界上还有如此之快的作品? 至此激发个人对连接池的学习兴趣: 我也要练习做一个.
个人做开发小蜜蜂连接池,纯属业余爱好,去年用光连接池的性能基准测试后发现跑分居然比光连接池还高,说实话,我也很质疑之前的跑分结果.由于能力有限,无法找出问题的原因,求助无门(曾在一些光连接池宣传贴下发贴提问, 可惜无人愿意帮忙, 无奈只好说比光更快了, 本意就是激发大家质疑它,发现问题.)
我记得曾经在光连接池的论坛上发个帖子请教:为什么小蜜蜂连接池比光连接池更快的原因,好像有个Bill的回了我的帖子,说了应该是Connection在使用之后需要重置,(这个应该是Brett说的不安全的问题吧),在他的建议下,加入了重置逻辑,并制作了一些测试案例, 在打包前是自动执行, 如果TestCase测试失败的打包过程自然会中止.加入了重置逻辑后再跑,跑分依然高啊.
实事求是的说,我确实阅读过光连接池的代码,但是能力有限,很多地方看不懂,最终放弃,至于他说的小蜜蜂连接池与光连接池在使用方法上存在相似性,Java是面向接口变成,再加上都是数据库连接池,一些方法名,类名相同不足为奇,当然有兴趣的网友可以进一步对比一下两套代码是否相同.连接池上有两个核心关键点:取连接,回收连接,如果真要比较,可以从这两个关键点上进行对比,BeeCP这两段关键逻辑是在个人反复阅读SynchronousQueue获得的灵感,另生成jdbc的代理方式灵感源自阿里的一篇文章(感谢阿里),大约只有有几个小点确实是参考光(比如支持驱动Datasource)思路点, 个人曾在Maven上提交过多个版本，为啥要这么干呢？因为一直在努力尝试各种代码改变带来的性能的提升。如果要Copy的话, 一步到位岂不是更好？如果抄袭的话,我一定大大方方承认,真的就是真的,假的也真不了.
至于他说的Druid,政府等,这个可能他说的玩笑话,Brett比较幽默,很受欢迎
来源：oschina
链接：https://my.oschina.net/u/3918073/blog/4497931