2.0 choose Springboot
Five reasons HikariCP is the default database connection pool
Why SB2 chose HikariCP and why HikariCP is so fast.
Springboot2 default database connection pool select HikariCP Reason 1 Code volume reason 2 Word of mouth reason 3 Speed reason 4 Stability Reason 5 Reliability HikariCP why so fast optimize and simplify bytecode better concurrent collection class implementation use FastList instead of A Which is better than rrayListHikariCP or Druid? Springboot2 quick start reference
The default database connection pool is HikariCP. If you use spring. Datasource. Type to force the use of Hikari connection pooling in a Tomcat application, you can remove the override
Why HikariCP
HiKariCP is a new JDBC connection pool with BoneCP enhancements and optimisations. HiKariCP is a new JDBC connection pool with BoneCP enhancements. The author also has another open source work, a high-performance JSON parser called HikariJSON.
It’s fast, fast enough that Spring Boot 2 has announced support for it.
The code size is even smaller, at 130KB.
Github.com/brettwoold….
Why use HiKariCP? It starts with BoneCP: What? Aren’t there mature database connection pools like C3P0/DBCP? It’s been working so well. Why a BoneCP? Because, legend has it that BoneCP is extremely fast, official data is about 25 times faster than C3P0. Don’t believe me? I don’t really believe it either. However, there is a picture of the truth (image from BoneCP website: jolbox.com/benchmarks….
From the above results, it can be seen that the performance of HikariCP is much higher than c3P0, Tomcat and other connection pools, so that the author of BoneCP gave up maintenance and recommended using HikariCP on Github project homepage. In addition, Spring Boot will use HikariCP as its default JDBC connection pool in version 2.0.
PS: It should be pointed out that, The data above is HikariCP author calls to the Connection pool DataSource. The getConnection (), the Connection. The close (), the Connection. PrepareStatement (), the Statement. The execute () , statement.close () performance test results.
What’s more, BoneCP is highly praised on the Internet, with a lot of articles recommended.
However, on the Maven Repository site (mvnrepository.com/artifact/co…). If you look for the latest version, you will find that the latest version is from October 2013. . So, go back to BoneCP’s Githut (github.com/wwadge/bone…) Check to see if any codes have been submitted recently. Instead, BoneCP’s authors seem to have given up on the project and say they are giving in to HikariCP (picture and truth) :
… What? Another CP? … What is Hikari? Hikari comes from Japanese and means “light” (light of sunlight, not bare light). The author presumably used the word to imply that the CP was fast. I do not know whether the author is Japanese, but Japan also has a lot of excellent code farmers, I heard that bitcoin is said to come out of Japan…
The product’s tagline is “Fast, Easy, and Reliable.” Does the actual situation match the slogan? Again, Benchmarks contain it:
This diagram also, indirectly, proves once again that boneCP is much stronger than C3P0, but much weaker than light.
So how does it work? The website details some of the optimizations HikariCP has made, summarized below:
- Bytecode streamlining: Optimizing code until the minimum amount of bytecode is compiled so that the CPU cache can load more program code.
- Optimize proxies and interceptors: Reduce code. For example, HikariCP’s Statement Proxy has only 100 lines of code, one-tenth of BoneCP’s.
- Custom array types (FastStatementList) instead of ArrayList: Avoid range check for every get() call, avoid start-to-end scan for remove();
- Custom collection types (ConcurrentBag: improves concurrent read and write efficiency;
- Other optimizations for BoneCP defects, such as a study of method calls that took more than one CPU slice (but didn’t say how).
A lot of optimized comparisons are for BoneCP… Ha ha. Reference article: github.com/brettwooldr…
Reason one, code volume
Comparison of the amount of code in several connection pools (less code generally means more efficient execution and less possibility of bugs) :
Second, word of mouth
However, the Japanese people also know the saying “huangpo sells melons, and they boast themselves”, so the user’s praise is also a wave of graphs and truth:
Third, speed
There are also third-party tests for speed:
Fourth, stability
You may say, high speed, if unstable is also tough ah. So here’s the graph of stability:
5. Reliability
In addition, the reliability is also supported by experiments and data. In the case of database disconnection, test getConnection(), and the different CP processing is as follows: (all CP are configured with a parameter like connectionTimeout to 5 seconds)
- HikariCP: Wait 5 seconds, if the connection is not restored, throw an SQLExceptions exception; Subsequent getConnection() does the same;
- C3P0: no response at all, no hint, and no notification to the caller if CheckoutTimeout has expired; Then wait 2 minutes and finally wake up, return an error;
- Tomcat: Return a connection and then… If the caller uses this invalid connection to execute an SQL statement… The results can be imagined; It finally wakes up after about 55 seconds, at which point getConnection() finally returns an error, but instead of waiting 5 seconds for the parameter configuration, it returns error immediately;
- BoneCP: same as Tomcat; It takes about 55 seconds to wake up and has a normal response, and finally returns error after 5 seconds.
It can be seen that HikariCP’s treatment is the most reasonable. According to the test results, the scores for each CP processing database interruption are as follows:
Reference article: github.com/brettwooldr…
Why HikariCP so fast
The implementation of JDBC Connection pool is not complicated. It is mainly the encapsulation and dynamic proxy of several core objects in JDBC: Connection, Statement, PreparedStatement, CallableStatement and ResultSet. Here’s a look at why HikariCP is so fast:
Optimize and simplify bytecode
HikariCP utilizes Javassist, a third-party Java bytecode modification class library, to generate delegates to implement dynamic proxies. Dynamic proxy implementation in ProxyFactory class, source code as follows:
I noticed that there was only one line of code for throwing exceptions directly, commented “Body is injected (injected) by JavassistProxyFactory”. The code in the body method is generated by calling JavassistProxyFactory at compile time. The main code is shown below:
Dynamic Proxy generation is done with Javassist because it is faster, produces less bytecode than JDK Proxy, and minimizes unnecessary bytecode.
ConcurrentBag: Better implementation of concurrent collection classes
ConcurrentBag is a lock-less collection designed specifically for connection pooling, and achieves better concurrency performance than LinkedBlockingQueue and LinkedTransferQueue. ConcurrentBag internally uses both ThreadLocal and CopyOnWriteArrayList to store elements, where CopyOnWriteArrayList is shared by threads. ConcurrentBag uses queue-stealing to fetch elements from a ThreadLocal that belong to the current thread to prevent lock contention, or from the shared CopyOnWriteArrayList if no elements are available. In addition, ThreadLocal and CopyOnWriteArrayList are member variables in ConcurrentBag and are not shared between threads, preventing false sharing.
Use FastList instead of ArrayList
FastList is a stripped-down implementation of the List interface that implements only the necessary methods in the interface. The JDK ArrayList does a rangeCheck check every time it calls the get() method to see if the index is out of bounds. The FastList implementation removes this check, and as long as the index is valid, rangeCheck becomes an unnecessary overhead (which is minimal, of course). In addition, HikariCP uses a List to store opened statements. When a Statement or Connection is closed, the corresponding Statement must be removed from the List. When multiple statements are created in the same Connection, the later one is closed first. The remove(Object) method of ArrayList iterates through an array from the beginning, whereas FastList iterates from the end of the array, making it more efficient.
Which is better, HikariCP versus Druid?
Some users gave Druid comments like this:
No comments, one is for performance, one is for monitoring, just look at the previous issue that someone gave HikariCP about comparison analysis with Druid. Druid has been tested by HikariCP and commented on by Druid author Shao Wen. Issue link:
Github.com/brettwoold….
The author’s personal view is that hikariCP can provide monitoring function, such as metrics, you can see the author of this article [Chaser series] hikariCP connection pool monitoring indicator combat. In addition, monitoring, Skywalking, Pinpoint, Mycat and other agents can also do, after the popularization of service mesh can be more monitoring, such as Sharing-JDBC can also do monitoring, Datamesh, Sidecar can also do monitoring.
Springboot2 is quick to get started
So well said, will it be very troublesome to use ah, will there be a lot of parameters to configure to have this effect ah? The answer is: no.
Springboot 2.0’s default connection pool is Hikari, so you don’t need to specify dependencies after referencing parents
Just configure it
- # jdbc_config datasource
- spring.datasource.driver-class-name=com.mysql.jdbc.Driver
- Spring. The datasource. Url = JDBC: mysql: / / 127.0.0.1:3306 / datebook? useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&useSSL=false&zeroDateTimeBehavior=convertToNull
- spring.datasource.username=root
- spring.datasource.password=root# Hikari will use the above plus the following to setup connection pooling
- spring.datasource.type=com.zaxxer.hikari.HikariDataSource
- spring.datasource.hikari.minimum-idle=5
- spring.datasource.hikari.maximum-pool-size=15
- spring.datasource.hikari.auto-commit=true
- spring.datasource.hikari.idle-timeout=30000
- spring.datasource.hikari.pool-name=DatebookHikariCP
- spring.datasource.hikari.max-lifetime=1800000
- spring.datasource.hikari.connection-timeout=30000
- spring.datasource.hikari.connection-test-query=SELECT 1
Direct boot can be shown in the figure
The resources
Blog.csdn.net/clementad/a…
Reprinted from the public account: Craftsman piglet’s Technical World