回应 "SpringBoot中文社区 " 网友的贴

原创
08/16 19:45
阅读数 489

我是在17年无意看到一条关于"光连接池与Druid的"性能PK的新闻,也是那个时候才知道OSChina这个网站(当时还以为它是个小网站),当时用光连接池程序跑了一下,我非常震惊:这世界上还有如此之快的作品? 至此激发个人对连接池的学习兴趣: 我也要练习做一个.

 个人开发小蜜蜂连接池,纯属业余爱好,去年用光连接池的性能基准测试后发现跑分居然比光连接池还高,说实话,我也很质疑之前的跑分结果.由于能力有限,无法找出问题的原因,求助无门(曾在一些光连接池宣传贴下发贴提问, 可惜无人愿意帮忙, 无奈只好说比光更快,本意就是激发网友们质疑它,发现问题.)

我记得曾经在光连接池的论坛上发个帖子请教:小蜜蜂连接池比光连接池更快的原因,好像有个Bill的回了我的帖子,说了应该是Connection在使用之后需要重置,(这个应该是Brett说的不安全的问题吧),在他的建议下,加入了重置逻辑(原本有重置,只是不够全),并制作了一些测试案例, 在打包前是自动执行, 如果TestCase测试失败, 打包过程自然会中止.加入了重置逻辑后再跑,跑分依然高啊.

实事求是的说,我确实阅读过光连接池的代码,但是能力有限,很多地方看不懂,最终放弃,至于他说的小蜜蜂连接池与光连接池在使用方法上存在相似性,Java是面向接口编程,再加上都是数据库连接池,一些方法名,类名相同不足为奇,当然有兴趣的网友可以进一步对比一下两套代码是否相同.连接池上有两个核心关键点:取连接,回收连接,如果真要比较,可以从这两个关键点上进行对比,BeeCP这两段关键逻辑是在个人反复阅读SynchronousQueue获得的灵感,另生成jdbc的代理方式灵感源自阿里的一篇文章(感谢阿里),大约只有有几个小点确实是参考光(比如支持驱动Datasource)思路点, 个人曾在Maven上提交过多个版本,为啥要这么干呢?因为一直在努力尝试各种代码改变带来的性能的提升。如果要Copy的话, 一步到位岂不是更好?


至于他说的Druid,政府等,这个可能他说的玩笑话,Brett比较幽默,很受欢迎
 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部