从BoneCP到HikariCP
&&&&今天笔者本想更新一下项目中使用到的BoneCP版本的。却无意发现jolbox网站打不开了。起初以为是被墙掉了，经过一番查找，居然在BoneCP的Github站看到了如下的一段话：
&&&&BoneCP的作者不知何时修改了简述。（ps：红色框中的部分意思：虽然BoneCP性能优于老旧的C3PO和DBCP连接池，但是现在应该被舍弃了，以迎接HikariCP）
&&&&作者词语之间充满了悲凉之感，好比当年的少年侠客，风流倜傥，如今已是迟暮之年，不得不退出江湖，何其悲凉。
&&&&在笔者胡乱感伤一通过后，那么问题就来了。
HikariCP是虾米？
　　Github主页：
　　HikariCP是一个高效的数据库连接池。
One&Connection Cycle&is defined as single&DataSource.getConnection()/Connection.close().
In&Unconstrained&benchmark, connections & threads.
In&Constrained&benchmark, threads & connections (2:1).
One&Statement Cycle&is defined as single&Connection.prepareStatement(),Statement.execute(),&Statement.close().
1&Versions: HikariCP 2.1.0, BoneCP 0.8.0, Tomcat 8.0.9, Vibur 1.2.0, C3P0 0.9.5-pre8, Java 8u20&2&Java options: -server -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xmx512m
从HikariCP网站给出的对比图来看。其性能相比于BoneCP有了质的变化，革命性的变更。
笔者因为使用了Spring框架。所以更换使用HikariCP相当简单，只要将原本BoneCP的配置信息修改一下就好了。详细见下：
1 &!-- HikariCP 高性能数据库连接池 --&
&bean id="dataSourceHikari" class="com.zaxxer.hikari.HikariDataSource"&
&property name="driverClassName" value="com.mysql.jdbc.Driver"/&
&property name="jdbcUrl" value="jdbc:mysql://localhost:3306/black1?useUnicode=true&characterEncoding=UTF-8"/&
&property name="username" value="root"/&
&property name="password" value=""/&
&!-- Default settings --&
&!-- 控制自动提交行为 default：true --&
&property name="autoCommit" value="true"/&
&!--连接池获取的连接是否只读 default:false--&
&property name="readOnly" value="false"/&
&!--控制连接的事务隔离等级 default:none--&
&property name="transactionIsolation" value="none"/&
&!--设置catalog以便于支持查看catalogs ， 若不指定的话将直接使用 JDBC driver使用的 default:none--&
&property name="catalog" value="none"/&
&!--最大连接超时时间 default：30秒--&
&property name="connectionTimeout" value="30000"/&
&!--最大空闲超时时间 default：10分钟
&property name="idleTimeout" value="600000"/&
&!--连接池中一个连接的最大生命周期 default：30分钟--&
&property name="maxLifetime" value="1800000 "/&
...还有一些其他配置属性 有兴趣可以看看 O(&_&)O哈哈~ --&
　　Ps：笔者也是首次使用HikariCP类库。具体的性能和优越性暂时还不好下定论。但是相信HikariCP开发组能发表这样的对比图，想来未必是空穴来风，暂时使用一下，过段时间再来完善性能是否如图表所示。持续关注中。
　　HikariCP官方网网的一些教程文档：
　　Maven ：&
　　【JDK1.8】
1 &dependency&
&groupId&com.zaxxer&/groupId&
&artifactId&HikariCP&/artifactId&
&version&2.1.0&/version&
&scope&compile&/scope&
6 &/dependency&
　　【JDK1.6和1.7】：
1 &dependency&
&groupId&com.zaxxer&/groupId&
&artifactId&HikariCP-java6&/artifactId&
&version&2.1.0&/version&
&scope&compile&/scope&
6 &/dependency&
作者：TinyZ出处：关于作者：从事于网络游戏服务端开发(JAVA)。喜欢接触和了解新技术。通过不断探索学习，提升自身价值。记录经验分享。本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接如有问题，可以通过&&联系我，非常感谢。笔者网店:&. 欢迎围观
阅读(...) 评论()为什么HikariCP被号称为性能最好的Java数据库连接池，怎么配置使用 - 数据库当前位置:& &&&为什么HikariCP被号称为性能最好的Java数据库连接池为什么HikariCP被号称为性能最好的Java数据库连接池，怎么配置使用&&网友分享于：&&浏览：0次为什么HikariCP被号称为性能最好的Java数据库连接池，如何配置使用HiKariCP是数据库连接池的一个后起之秀，号称性能最好，可以完美地PK掉其他连接池。
原文地址：http://blog.csdn.net/clementad/article/details/
官网：/brettwooldridge/HikariCP
为何要使用HiKariCP？这要先从BoneCP说起：
什么？不是有C3P0/DBCP这些成熟的数据库连接池吗？一直用的好好的，为什么又搞出一个BoneCP来？因为，传说中BoneCP在快速这个特点上做到了极致，官方数据是C3P0等的25倍左右。不相信？其实我也不怎么信。可是，有图有真相啊（图片来自BoneCP官网：/benchmarks.html）：
而且，网上对于BoneCP是好评如潮啊，推荐的文章一搜一大堆。
然而，上Maven Repository网站（/artifact/com.jolbox/bonecp）查找有没有最新版本的时候，你会发现最新的是2013年10月份的（这么久没新版本出来了？）。于是，再去BoneCP的Githut（/wwadge/bonecp）上看看最近有没有提交代码。却发现，BoneCP的作者对于这个项目貌似已经心灰意冷，说是要让步给HikariCP了（有图有真相）：
……什么？又来一个CP？……什么是Hikari？
Hikari来自日文，是“光”（阳光的光，不是光秃秃的光）的意思。作者估计是为了借助这个词来暗示这个CP速度飞快。不知作者是不是日本人，不过日本也有很多优秀的码农，听说比特币据说日本人搞出来的。。。
这个产品的口号是“快速、简单、可靠”。实际情况跟这个口号真的匹配吗？又是有图有真相（Benchmarks又来了）：
这个图，也间接地、再一次地证明了boneCP比c3p0强大很多，当然，跟“光”比起来，又弱了不少啊。
那么，这么好的P是怎么做到的呢？官网详细地说明了HikariCP所做的一些优化，总结如下：
字节码精简：优化代码，直到编译后的字节码最少，这样，CPU缓存可以加载更多的程序代码；优化代理和拦截器：减少代码，例如HikariCP的Statement proxy只有100行代码，只有BoneCP的十分之一；自定义数组类型（FastStatementList）代替ArrayList：避免每次get()调用都要进行range check，避免调用remove()时的从头到尾的扫描；自定义集合类型（ConcurrentBag）：提高并发读写的效率；其他针对BoneCP缺陷的优化，比如对于耗时超过一个CPU时间片的方法调用的研究（但没说具体怎么优化）。
很多优化的对比都是针对BoneCP的……哈哈。
（参考文章：/brettwooldridge/HikariCP/wiki/Down-the-Rabbit-Hole）
几个连接池的代码量对比（代码量越少，一般意味着执行效率越高、发生bug的可能性越低）：
可是，“黄婆卖瓜，自催自擂”这个俗语日本人也是懂得，于是，用户的好评如潮也是有图有真相：
还有第三方关于速度的测试：
也许你会说，速度高，如果不稳定也是硬伤啊。于是，关于稳定性的图也来了：
另外，关于可靠性方面，也是有实验和数据支持的。对于数据库连接中断的情况，通过测试getConnection()，各种CP的不相同处理方法如下：
（所有CP都配置了跟connectionTimeout类似的参数为5秒钟）
HikariCP：等待5秒钟后，如果连接还是没有恢复，则抛出一个SQLExceptions 异常；后续的getConnection()也是一样处理；
C3P0：完全没有反应，没有提示，也不会在“CheckoutTimeout”配置的时长超时后有任何通知给调用者；然后等待2分钟后终于醒来了，返回一个error；
Tomcat：返回一个connection，然后……调用者如果利用这个无效的connection执行SQL语句……结果可想而知；大约55秒之后终于醒来了，这时候的getConnection()终于可以返回一个error，但没有等待参数配置的5秒钟，而是立即返回error；
BoneCP：跟Tomcat的处理方法一样；也是大约55秒之后才醒来，有了正常的反应，并且终于会等待5秒钟之后返回error了；
可见，HikariCP的处理方式是最合理的。根据这个测试结果，对于各个CP处理数据库中断的情况，评分如下：
参考文章：/brettwooldridge/HikariCP/wiki/Bad-Behavior:-Handling-Database-Down
说得这么好，用起来会不会很麻烦啊，会不会有很多参数要配置才能有这样的效果啊？答案是：不会。
如果之前用的是BoneCP配置的数据源，那么，就简单了，只需要把dataSource换一下，稍微调整一下参数就行了：
BoneCP的数据源配置：
&!-- BoneCp Datasource --&
&bean id=&dataSourceBoneCp& class=&com.jolbox.bonecp.BoneCPDataSource& destroy-method=&close&&
&property name=&driverClass& value=&${db.driverClass}& /&
&property name=&jdbcUrl& value=&${db.url}& /&
&property name=&username& value=&${db.username}& /&
&property name=&password& value=&${db.password}& /&
&property name=&idleConnectionTestPeriodInMinutes& value=&2& /&
&property name=&idleMaxAgeInMinutes& value=&2& /&
&property name=&maxConnectionsPerPartition& value=&2& /&
&property name=&minConnectionsPerPartition& value=&0& /&
&property name=&partitionCount& value=&2& /&
&property name=&acquireIncrement& value=&1& /&
&property name=&statementsCacheSize& value=&100& /&
&property name=&lazyInit& value=&true&/&
&property name=&maxConnectionAgeInSeconds& value=&20&/&
&property name=&defaultReadOnly& value=&true&/&
HiKariCP的数据源配置：
&!-- Hikari Datasource --&
&bean id=&dataSourceHikari& class=&com.zaxxer.hikari.HikariDataSource&
destroy-method=&shutdown&&
&!-- &property name=&driverClassName& value=&${db.driverClass}& /& --& &!-- 无需指定，除非系统无法自动识别 --&
&property name=&jdbcUrl& value=&jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8& /&
&property name=&username& value=&${db.username}& /&
&property name=&password& value=&${db.password}& /&
&!-- 连接只读数据库时配置为true， 保证安全 --&
&property name=&readOnly& value=&false& /&
&!-- 等待连接池分配连接的最大时长（毫秒），超过这个时长还没可用的连接则发生SQLException， 缺省:30秒 --&
&property name=&connectionTimeout& value=&30000& /&
&!-- 一个连接idle状态的最大时长（毫秒），超时则被释放（retired），缺省:10分钟 --&
&property name=&idleTimeout& value=&600000& /&
&!-- 一个连接的生命时长（毫秒），超时而且没被使用则被释放（retired），缺省:30分钟，建议设置比数据库超时时长少30秒，参考MySQL wait_timeout参数（show variables like '%timeout%';） --&
&property name=&maxLifetime& value=&1800000& /&
&!-- 连接池中允许的最大连接数。缺省值：10；推荐的公式：((core_count * 2) + effective_spindle_count) --&
&property name=&maximumPoolSize& value=&15& /&
其中，很多配置都使用缺省值就行了，除了maxLifetime和maximumPoolSize要注意自己计算一下。
其他的配置（sqlSessionFactory、MyBatis MapperScannerConfigurer、transactionManager等）统统不用变。
其他关于Datasource配置参数的建议：
Configure your HikariCP&idleTimeout&and&maxLifeTime&settings
to be one minute less than the&wait_timeout&of MySQL.
对于有Java连接池的系统，建议MySQL的wait_timeout使用缺省的8小时（/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server）。
另外：对于web项目，记得要配置：destroy-method=&shutdown&
（原创文章，转载请注明转自Clement-Xu的csdn博客。）
版权声明：本文为原创文章，转载请注明转自Clement-Xu的csdn博客。
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 1234567891011 Copyright & &&版权所有&&国之画&&&& &&
版权所有 京ICP备号-2
迷上了代码！修改Tomcat的Access Log存放路径和文件名
修改Tomcat的Access Log存放路径和文件名
Tomcat中的Access Log，缺省存放在logs目录下。这个目录会越来越大，如果访问量大的话，很快就会把硬盘挤满。
解决的方法有两种：
不要记录Access Log：注释掉server.xml中的&Valve&配置项把Access log存放到其他地方，然后定期压缩归档：修改server.xml中&Valve&配置项中的“directory”参数，改为另外一个在大硬盘中的路径
如果是在运行中的系统，需要多做几步，先停止Tomcat、把Tomcat/logs中已经存在的Access Log文件移走、修改配置文件、然后重启Tomcat。一个具体的修改例子如下：
假设新存放路径是/opt/logs/access_logs，文件名前缀修改为xjj_access_log以免跟其他Tomcat的log混淆：
cd /opt/logs
mkdir access_logs
vim /opt/app/tomcat-xjj/conf/server.xml
修改：directory=&/opt/logs/access_logs&修改：prefix=&xjj_access_log&
停止tomcat：/opt/app/tomcat-xjj/bin/shutdown.sh 无法停止？杀死：kill -9 &pid&
cd /opt/app/tomcat-xjj/logs
rename localhost_access_log xjj_access_log *.txt （用后缀.txt过滤出所有的access
log文件，并批量重命名）
mv *.txt /opt/logs/access_logs/
重启tomcat：/opt/app/tomcat-xjj/bin/startup.sh&
然后，如果有需要，再另外写脚本定期压缩归档/opt/logs/access_logs中的文件（步骤略）。
更多关于Tomcat Access Log的配置参考：
我的热门文章
即使是一小步也想与你分享