beecp

https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/JDBCPool2020-11-06.log 来源： oschina 链接： https://my.oschina.net/u/3918073/blog/4706928

测试环境与前相同 jar包位置 ： https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/beecp-3.0.0.jar 日志文件 ： https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/JDBCPool-20201013.log 连接池配置源码： import cn.beecp.test.Link; import cn.beecp.BeeDataSource; import cn.beecp.BeeDataSourceConfig; public class BeeCP_C { public static BeeDataSource createDataSource() throws Exception{ BeeDataSourceConfig config = new BeeDataSourceConfig(); config.setDriverClassName(Link.JDBC_DRIVER); config.setJdbcUrl(Link.JDBC_URL); config.setUsername(Link.JDBC_USER); config.setPassword(Link.JDBC_PASSWORD); config

PC: I5-4210M(2.6Hz) ,12G内存，Win7_64, Java: java8_.0.65, mariadb-10.4.13，驱动：mysql-connector-java-5.1.48.jar Pool: 初始10个，最大10个 执行SQL : select * from BEECP_TEST 测试情况：1000线程 x 1000循环 jar包位置 ： https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/beecp-3.0.0.jar 日志文件 ： https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/JDBCPool-20201013.log 来源： oschina 链接： https://my.oschina.net/u/3918073/blog/4672387

相信很多看过小蜜蜂(BeeCP)连接池的性能对比图的网友都会觉得惊讶不已，这比被号称史上最快的光连接池还快啊，简直不可思议！想知道它性能强悍的原因吗？今天就为大家解开这个谜团。 连接借用 故事还是要从连接池本身说起，连接池技术是一门古老的IT技术，其本质并不复杂，其工作原理类似图书馆，只不过它借出/回收的是连接对象，在连接池类内部一般至少有两条列表，第一条存放连接对象(类似书架),第二条存放等待者线程(或隐式), 如果连接都被借光了，借用者只能排队等待其他借用者归还，等待过程中，某些等待者可能会因为时间达到最大允许时刻点，则会退出等待，这种离开现象叫等待超时。 传递与队列 借用在使用完毕后将被关闭(实际关闭只是代理对象而已),背后自动触发连接池对连接的回收，如果在池中存在等待者，那么连接池将回收过来的连接传递给等待者，这是一件很有意思的事情，各连接池的性能的差异，很大一部分是由传递的速度导致的（谁的传递效率高，谁的性能更强），传递的方式通常是借助于同步队列的管道推拉方式完成的，比如Tomcat-JDBC使用的是闲/忙两条队列，光连接池采用的是同步队列（SynchronousQueue）代码类似: 归还线程A:queue.offer(object); 等待线程B:queue.poll(time); 对于线程 B在有效时间范围内进行等待

JDBC连接池主要是用来管理Connnection, Statement, ResultSet这些对象,只不过用户得到的是它们的代理对象而已(这些对象的管理需要仿真驱动实现),这些代理对象也是要遵循JDBC接口规范, 而这些原生对象是通过JDBC驱动来构建的, 那么我们来看看这些对象在驱动内部是如何被构建的呢? 以MySQL驱动( mysql-connector-java-5.1.48.jar )为例, 第一步: 解压Jar包: 首先用Winrar工具来解压包 第二步: 找到驱动类所在目录 第三步: 找到包下的 Connnection, Statement, ResultSet 实现类 第四步: 使用鼠标将这三个类拖Idea中,将自动被反编译 第五步: 看看Connection是如何创建Statement 和PreparedStatement StatementImpl stmt = new StatementImpl( this .getMultiHostSafeProxy(), this .database); * 驱动本身支持PreparedStatement缓存 再来看看是如何关闭的(Close) 同步方法关闭 连接关闭时,自动关闭被它打开过的 Statement,PreparedStatement,CallableStatement 第六步: 看看Statement

代码类: https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/TestResultSet.java *******************开始测试数据源(BeeCP)******************* BeeCP-通过,<检查由executeQuery执行的结果值必须等于Statement.getResultSet()> BeeCP-通过,<结果集合关闭结果后，statement.getResultSet()不能再获取这个结果集合对象> BeeCP-通过,<unwrap测试ResultSet是否存在暴露问题（原生态对象不允许暴露给使用者)> BeeCP-通过,<unwrap测试Connection是否存在是否存在暴露问题（原生态对象不允许暴露给使用者)> BeeCP-通过,<检查关闭的这个结果集合isClosed()的返回值必须等于True> BeeCP-通过,<检查从一个已经关闭的Statement获取曾经打开过的结果集合要抛出异常> *******************开始测试数据源（HikariCP）******************* HikariCP-失败,<检查由executeQuery执行的结果值必须等于Statement.getResultSet()> HikariCP-通过,

我是在17年无意看到一条关于"光连接池与Druid的"性能PK的新闻,也是那个时候才知道OSChina这个网站(当时还以为它是个小网站),当时用光连接池程序跑了一下,我当时非常震惊:这世界上还有如此之快的作品? 至此激发个人对连接池的学习兴趣: 我也要练习做一个. 个人做开发小蜜蜂连接池,纯属业余爱好,去年用光连接池的性能基准测试后发现跑分居然比光连接池还高,说实话,我也很质疑之前的跑分结果.由于能力有限,无法找出问题的原因,求助无门(曾在一些光连接池宣传贴下发贴提问, 可惜无人愿意帮忙, 无奈只好说比光更快了, 本意就是激发大家质疑它,发现问题.) 我记得曾经在光连接池的论坛上发个帖子请教:为什么小蜜蜂连接池比光连接池更快的原因,好像有个Bill的回了我的帖子,说了应该是Connection在使用之后需要重置,(这个应该是Brett说的不安全的问题吧),在他的建议下,加入了重置逻辑,并制作了一些测试案例, 在打包前是自动执行, 如果TestCase测试失败的打包过程自然会中止.加入了重置逻辑后再跑,跑分依然高啊. 实事求是的说,我确实阅读过光连接池的代码,但是能力有限,很多地方看不懂,最终放弃,至于他说的小蜜蜂连接池与光连接池在使用方法上存在相似性,Java是面向接口变成,再加上都是数据库连接池,一些方法名,类名相同不足为奇,当然有兴趣的网友可以进一步对比一下两套代码是否相同

测试机器 CPU: I3-7100 内存: 8G 操作系统:Win7_64 测试结果图 源码地址 https://github.com/Chris2018998/BeeCP/blob/master/doc/other/HikariCP-benchmark_SafeClose.zip Tag:BeeCP 来源： oschina 链接： https://my.oschina.net/u/3918073/blog/4365521

Tag:BeeCP-2.5.2 来源： oschina 链接： https://my.oschina.net/u/3918073/blog/4486061

上一节博客中提到了：连接池在回收连接时，需要对连接进行安全关闭, 并提到了主流连接池可能存在这个问题，似乎一些网友表示怀疑, 这怎么可能呢? 主流连接可都是大牌啊( 大牌也是人开发的,是人做的,就有出错的可能性 ), 好吧,今天就做一个测试用例来论证一下 测试说明 : 利用1000个并发线程去关闭同一个连接 期待结果 : 只能有一个成功,其他999个必须失败(999个异常). 测试结果,如图下 源码包地址: https://github.com/Chris2018998/BeeCP/blob/master/doc/other/ConnectionSafeClose.zip 光连接池结果出现两面性：有时候通过，有时不通过，因此把它的异常信息打印出来 如果增加安全关闭控制，估计几个主流连接池性能都会下降（ 光连接池的那个性能柱状图就得重测了)。有兴趣的网友帮忙看看，是不是真有问题。 Tag:BeeCP 来源： oschina 链接： https://my.oschina.net/u/3918073/blog/4355637