16
回答
为什么 BoneCP 连接池的性能这么高呢?
科大讯飞通用文字识别100000次/天免费使用。立即申请   

看了 BoneCP 这个连接池的介绍,其性能远在 C3P0DBCP 之上。

为什么呢?

Java连接池发展了这么久,基本上已经都很稳定了,你看 C3P0 和 DBCP 都不再发布新版本了。而 BoneCP出彩的地方就是跟进了技术的最新进展。

研究它的源码,发现有两个主要原因:

1. BoneCP 不用 synchronized 关键字来处理多线程对资源的争用,而是使用 java.util.concurrent 包中的锁机制,这个包是在 JDK 1.5 才开始有的;

2. 分区机制,尽管使用了锁,但还是存在着资源争用的问题,因此 BoneCP 可配置多个连接池分区,每个分区独立管理,互不影响。

尽管连接池的性能并不会是一个系统中的瓶颈,但是我们单纯从连接池这个角度来看 BoneCP ,也是值得我们去学习的。

附:昨晚,本站刚刚将原来的 C3P0 换成 BoneCP ,到目前为止,稳定性是没什么问题。

 

举报
红薯
发帖于8年前 16回/7K+阅
共有16个评论 最后回答: 6年前

1 synchronized 这个很讨厌,现在只是用于一些特定语法;

2 减少竞争永远是提高性能的法宝;

3 一个web系统应该尽可能的减少读数据库的次数;

我测试过,如果是单线程synchronized  比concurrent的锁,是要快的,但他的测试单线程都比c3p0要快

这就真其怪了,也可能是分区机制,ConcurrentHashMap之后以比hashmap快,他的思想就是用N把锁来锁数据

这样冲突就减到最低了

其实用synchronized使用降低效率的根本原因是synchronized 的使用不当,concurrent的引入杜绝了这个问题,但是concurrent本身效率并不高,如果追求高效代码,还是要自己来实现同步代码,我测过concurrent中的ThreadPool,比起实现相同功能的我自己写的代码效率就明显要低,但是胜在安全和通用不是,所以最后我还是采用了concurrent,反正这些效率的降低不会死人,出了问题才会死人不是

引用来自“木才”的帖子

其实用synchronized使用降低效率的根本原因是synchronized 的使用不当,concurrent的引入杜绝了这个问题,但是concurrent本身效率并不高,如果追求高效代码,还是要自己来实现同步代码,我测过concurrent中的ThreadPool,比起实现相同功能的我自己写的代码效率就明显要低,但是胜在安全和通用不是,所以最后我还是采用了concurrent,反正这些效率的降低不会死人,出了问题才会死人不是

 自己来实现同步代码????怎样实现??用synchronized么

顶部