HikariCP为什么这么快

HikariCP是一个高性能的JDBC连接池，基于BoneCP做了不少的改进和优化。作者是个日本人，他还有另外一个开源作品——高性能的JSON解析器HikariJSON。

关于HikariCP的性能有多高，看图说话：

从上述结果可以看出HikariCP的性能远高于c3p0、tomcat等连接池，以致后来BoneCP作者都放弃了维护，在Github项目主页推荐大家使用HikariCP。另外，Spring Boot将在2.0版本中把HikariCP作为其默认的JDBC连接池。

需要指出的是，上图中的数据是HikariCP作者对各个连接池调用DataSource.getConnection()、Connection.close()、Connection.prepareStatement()、Statement.execute()、Statement.close()方法的性能测试结果。

JDBC连接池的实现并不复杂，主要是对JDBC中几个核心对象Connection、Statement、PreparedStatement、CallableStatement以及ResultSet的封装与动态代理。接下来从几个方面来看看HikariCP为什么这么快：

1、优化并精简字节码

HikariCP利用了一个第三方的Java字节码修改类库Javassist来生成委托实现动态代理。动态代理的实现在ProxyFactory类，源码如下：

发现这些代理方法中只有一行直接抛异常的代码，注释写着“Body is replaced (injected) by JavassistProxyFactory”，其实方法body中的代码是在编译时调用JavassistProxyFactory才生成的，主要代码见下图：

之所以使用Javassist生成动态代理，是因为其速度更快，相比于JDK Proxy生成的字节码更少，精简了很多不必要的字节码。

2、ConcurrentBag：更好的并发集合类实现

ConcurrentBag的实现借鉴于C#中的同名类，是一个专门为连接池设计的lock-less集合，实现了比LinkedBlockingQueue、LinkedTransferQueue更好的并发性能。ConcurrentBag内部同时使用了ThreadLocal和CopyOnWriteArrayList来存储元素，其中CopyOnWriteArrayList是线程共享的。ConcurrentBag采用了queue-stealing的机制获取元素：首先尝试从ThreadLocal中获取属于当前线程的元素来避免锁竞争，如果没有可用元素则再次从共享的CopyOnWriteArrayList中获取，进而减少伪共享(false sharing)的发生。

3、使用FastList替代ArrayList

FastList是一个List接口的精简实现，只实现了接口中必要的几个方法。JDK ArrayList每次调用get()方法时都会进行rangeCheck检查索引是否越界，FastList的实现中去除了这一检查，只要保证索引合法那么rangeCheck就成为了不必要的计算开销(当然开销极小)。

此外，HikariCP使用List来保存打开的Statement，当Statement关闭或Connection关闭时需要将对应的Statement从List中移除。通常情况下，同一个Connection创建了多个Statement时，后打开的Statement会先关闭。ArrayList的remove(Object)方法是从头开始遍历数组，而FastList是从数组的尾部开始遍历，因此更为高效。

关于HikariCP与Druid相比哪个更好？

不评论，一个追求性能，一个偏向监控，直接看之前有人给HikariCP提的关于跟Druid对比分析的issue吧。HikariCP作者对Druid做了测试并给出了测试结果数据，Druid作者温少也对此作了评论。Issue链接：https://github.com/brettwooldridge/HikariCP/issues/232

【参考】

https://github.com/brettwooldridge/HikariCP/wiki/Down-the-Rabbit-Hole

http://javatar.iteye.com/blog/814426