Five reasons to analyze Springboot 2.0 Why Choose HIKARICP

Five reasons to analyze Springboot 2.0 Why Choose HIKARICP2018-05-04 Craftsman Piggy Pig accounts for the Little Wolf blog

This article is not original, is the Artisan pig pig's technical world collects some HIKARICP related information to organize to everybody's introduction, mainly explains why SB2 chooses HIKARICP and HIKARICP why so fast.

For more information on HIKARICP, you can search the "technical world of artisan pig pig" public number for attention

Springboot2 default database connection pool selected HIKARICP

The default database connection pool is changed from Tomcat to HIKARICP. If you use Spring.datasource.type to force a Hikari connection pool in a Tomcat application, you can remove this override.

Why Choose HIKARICP

HIKARICP is a database connection pool of a rising star, known as the best performance, can be perfect pk off the other connection pool, is a high-performance JDBC connection pool, based on BONECP do a lot of improvement and optimization. Its author also has another open source work-the high-performance JSON parser Hikarijson.

It, super fast, almost even spring Boot 2 has been announced for support.

The code volume is less pitiful, 130kb.

Https://github.com/brettwooldridge/HikariJSON

Why use HIKARICP? This has to start with BONECP:
What the? Aren't there c3p0/dbcp these mature database connection pools? Always use good, why do you make a BONECP? Because, the legend of BONECP in the fast this feature to achieve the ultimate, the official data is c3p0 and so on about 25 times times. Don't believe it? I don't really believe it either. However, there is a picture of the truth ah (image from BONECP official website: http://jolbox.com/benchmarks.html):

From the above results can be seen HIKARICP performance is much higher than c3p0, Tomcat and other connection pool, so that later BONECP authors have abandoned the maintenance, on the GitHub Project homepage recommend you use HIKARICP. In addition, Spring boot will use HIKARICP as its default JDBC connection pool in version 2.0.

PS: It should be noted that the data in the HIKARICP author calls Datasource.getconnection (), Connection.close (), Connection.preparestatement (), Performance test results for the Statement.execute (), Statement.close () method.

Moreover, online for BONECP is rave, recommended article a lot of search.

However, on the MAVEN Repository website (HTTP://MVNREPOSITORY.COM/ARTIFACT/COM.JOLBOX/BONECP) to find out if there is no latest version of the time, You will find that the latest is October 2013 (so long has no new version come out?) ）。 So, go to BONECP's Githut (HTTPS://GITHUB.COM/WWADGE/BONECP) to see if there is a recent code submission. But found that the author of Bonecp for the project seems to have been discouraged, said to give up to HIKARICP (there is a picture of the truth):

...... What the? Another CP? ...... What is Hikari?
Hikari comes from Japanese, which means "light" (The Light of the sun, not the bare light). The author estimates that this word is used to imply that the CP is fast. I do not know whether the author is Japanese, but Japan also has a lot of good yards farmers, heard that the Japanese made out of bitcoin ...

The slogan of this product is "fast, simple, reliable". Does the fact match the slogan? There is a picture of the truth (benchmarks again):

This figure, also indirectly, once again proves that the BONECP is much stronger than c3p0, of course, compared with the "light", and weak a lot of AH.

So, how does it work so well? The official website explains in detail some of the optimizations made by HIKARICP, which are summarized as follows:

• bytecode Simplification : Optimize the code until the least compiled bytecode, so that the CPU cache can load more program code;

• optimize proxies and interceptors : reduce code, such as HIKARICP statement proxy only 100 lines of code, only the BONECP one-tenth;

• Custom Array type (faststatementlist) instead of ArrayList: avoid a range check for each get () call, avoiding a sweep from the beginning to the end of the call to remove ();

• Custom collection type (concurrentbag: Increase the efficiency of concurrent read and write;

• other optimizations for BONECP defects , such as the study of method invocations that take more than one CPU time slice (but not exactly how to optimize them).

Many of the optimization comparisons are aimed at BONECP ... Ha ha.
(Reference article: Https://github.com/brettwooldridge/HikariCP/wiki/Down-the-Rabbit-Hole)

Reason one, the amount of code

A comparison of the code volume of several connection pools (the less code, generally means that the more efficient the execution, the less likely the bug is):

Reason two, reputation

However, "Guangzhoa sell melon, self-urge self-tracing" This proverb Japanese also understand, so, the user's praise like Tide also has figure has the truth:

Reason three, speed

There are also third-party tests on speed:

Reason four, stability

Perhaps you will say, high speed, if instability is also flawed ah. Thus, a diagram of stability is also coming:

Reason Five, reliability

In addition, there are experiments and data support on reliability. For the case of database connection interruption, by testing the getconnection (), the different methods of CP processing are as follows:
(all CP are configured with a parameter similar to ConnectionTimeout for 5 seconds)

• HIKARICP: After waiting for 5 seconds, if the connection is still not restored, a SQLExceptions exception is thrown, and the subsequent getconnection () is treated as the same;

• c3p0: No response at all, no prompt, no notification to the caller after the time-out of the "checkouttimeout" configuration, and then wait 2 minutes to finally wake up and return an error;

• Tomcat: Return a connection, then ... If the caller uses this invalid connection to execute the SQL statement ... The results can be imagined; After about 55 seconds finally woke up, this time the getconnection () finally return an error, but did not wait for the parameter configuration of 5 seconds, but immediately return error;

• BONECP: As with Tomcat, it is about 55 seconds before waking up with a normal response, and will finally wait 5 seconds to return the error;

Visible, HIKARICP is the most reasonable way to deal with. Based on this test result, the scores for each CP processing database outage are as follows:

Reference article: Https://github.com/brettwooldridge/HikariCP/wiki/Bad-Behavior:-Handling-Database-Down

Why is HIKARICP so fast?

The implementation of the JDBC connection pool is not complex, primarily for encapsulation and dynamic proxies for several core objects in JDBC, connection, Statement, PreparedStatement, CallableStatement, and resultset. Let's take a look at how HIKARICP is so fast in several ways:

Optimize and streamline bytecode

HIKARICP uses a third-party Java bytecode to modify the class library javassist to generate delegates to implement dynamic proxies. Dynamic agent implementation in the Proxyfactory class, the source code is as follows:

It is found that only one line of these proxy methods throws the exception code, and the comment reads "Body is replaced (injected) by Javassistproxyfactory", In fact, the code in the body is generated at compile-time call Javassistproxyfactory, the main code see:

The reason for using javassist to generate dynamic proxies is that they are faster, with fewer bytecode generated than JDK proxies, and a lot of unnecessary bytecode is reduced.

Concurrentbag: Better implementation of concurrent collection classes

Concurrentbag's implementation draws on the same name class in C #, a Lock-less collection designed specifically for connection pooling, which achieves better concurrency than Linkedblockingqueue and linkedtransferqueue. Concurrentbag internally uses both Threadlocal and copyonwritearraylist to store elements, where copyonwritearraylist are thread-shared. Concurrentbag uses the queue-stealing mechanism to get the elements: first try to get the elements belonging to the current thread from threadlocal to avoid lock contention, If no elements are available, they are obtained again from the shared copyonwritearraylist. In addition, threadlocal and Copyonwritearraylist are member variables in Concurrentbag, and are not shared among threads, avoiding the occurrence of pseudo-sharing (false sharing).

replacing ArrayList with Fastlist

Fastlist is a compact implementation of the list interface, which implements only the necessary methods in the interface. JDK ArrayList every time the Get () method is called Rangecheck check whether the index is out of bounds, fastlist the implementation of this check, as long as the index is guaranteed to be legitimate so rangecheck to unnecessary computational overhead (of course, very small). In addition, HIKARICP uses list to save the open statement, which is required to remove the corresponding statement from the list when the statement is closed or connection closed. Typically, when multiple statement are created for the same connection, the statement that is opened will be closed first. The Remove (Object) method of ArrayList is to iterate through the array from the beginning, and fastlist is more efficient by iterating from the end of the array.

Which is better than HIKARICP and druid?

Some users have given comments such as Druid:

Do not comment, a pursuit of performance, a biased monitoring, directly see before someone gave HIKARICP about with Druid comparative analysis of issue bar. HIKARICP the author of the Druid did a test and gave the test results data, Druid The author also commented on the temperature. Issue Links:

https://github.com/brettwooldridge/HikariCP/issues/232

The author's personal view is that HIKARICP can provide monitoring functions, such as metrics, you can see the author of this article "Ray Chaser series" HIKARICP Connection pool monitoring indicators combat.
In addition, monitoring aspects, skywalking, pinpoint, mycat these agents can also be done, after service mesh popularization more can be monitored, such as sharding-jdbc can also do monitoring, Datamesh, Sidecar can also be monitored.

Springboot2 get started quickly

Say so good, use up will be very troublesome Ah, will have a lot of parameters to configure to have such effect ah? The answer is: No.

Springboot 2.0 The default connection pool is Hikari, so you don't have to rely on the reference parents

Just a little bit of configuration.

# Jdbc_config DataSource
Spring.datasource.driver-class-name=com.mysql.jdbc.driver
spring.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'll 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 start

Five reasons to analyze Springboot 2.0 Why Choose HIKARICP