Down the Rabbit Hole
?? Micro-optimizations 小優(yōu)化
HikariCP包含很多獨立的微小的優(yōu)化绒瘦，這些優(yōu)化幾乎都無法評估測量讲仰，但是所有小優(yōu)化一起形成了一個整體的性能提升楞慈。其中的一些優(yōu)化是以幾毫秒平攤在數以百萬計的調用膊存。
HikariCP contains many micro-optimizations that individually are barely measurable, but together combine as a boost to overall performance. Some of these optimizations are measured in fractions of a millisecond amortized over millions of invocations.
ArrayList
One non-trivial (performance-wise) optimization was eliminating the use of an ArrayList<Statement> instance in the ConnectionProxy used to track open Statement instances. When a Statement is closed, it must be removed from this collection, and when the Connection is closed it must iterate the collection and close any open Statement instances, and finally must clear the collection. The Java ArrayList, wisely for general purpose use, performs a range check upon every get(int index) call. However, because we can provide guarantees about our ranges, this check is merely overhead.
其中一個有意義的優(yōu)化就是消除在ConnectionProxy中用于追蹤活躍的Statement對象的ArrayList<Statement> 赘淮。當Statement關閉了岔帽，它必須從集合中刪除荷荤，并且當整個Connection關閉了退渗，他必須迭代集合然后關閉所有的Statement實例移稳，最終清理整個集合對象。java的ArrayList為了通常的使用会油，在每個get(int index)調用時都做了越界檢查秒裕，但是因為在這里我們可以確保索引范圍，所有這個檢查是多余的支出钞啸。
Additionally, the remove(Object) implementation performs a scan from head to tail, however common patterns in JDBC programming are to close Statements immediately after use, or in reverse order of opening. For these cases, a scan that starts at the tail will perform better. Therefore, ArrayList<Statement> was replaced with a custom class FastList which eliminates range checking and performs removal scans from tail to head.
另外remove(Object) 的實現是從頭到尾掃描數組几蜻，然而通常的JDBC編程模型是在使用了Statements之后立即關閉（跟創(chuàng)建statement順序相反）。因此如果從尾部開始掃描性能會更加好体斩。因此ArrayList<Statement>由我們自己定義的一個類FastList來代替掉了梭稚，它消除了索引越界的檢查以及在刪除時執(zhí)行從尾到頭部的掃描操作。
ConcurrentBag
HikariCP contains a custom lock-free collection called a ConcurrentBag. The idea was borrowed from the C# .NET ConcurrentBag class, but the internal implementation quite different. The ConcurrentBag provides...
A lock-free design 無鎖設計
ThreadLocal caching 本地線程緩存
Queue-stealing 工作竊取隊列
Direct hand-off optimizations
...resulting in a high degree of concurrency, extremely low latency, and minimized occurrences of false-sharing.
Invocation: invokevirtual vs invokestatic
簡而言之：原先的是單例工廠方法絮吵，改成類的靜態(tài)方法弧烤。即原先調用獲取代理連接等等的流程是 getStatic 獲取單例的工廠對象，然后invokeVirtual調用對象的具體方法來返回代理類蹬敲。后面改進之后直接invokeStatic調用類的靜態(tài)方法來返回代理對象暇昂，因此性能得到提升。
In order to generate proxies for Connection, Statement, and ResultSet instances HikariCP was initially using a singleton factory, held in the case of ConnectionProxy in a static field (PROXY_FACTORY).
為了生成Connection, Statement, and ResultSet 的代理對象實例伴嗡，HikariCP最開始使用了單例工廠方法急波，在ConnectionProxy對象的一個靜態(tài)屬性(PROXY_FACTORY)中。
There was a dozen or so methods resembling the following:
項目中有許多如下類似的方法：
public final PreparedStatement prepareStatement(String sql, String[] columnNames) throws SQLException
{
return PROXY_FACTORY.getProxyPreparedStatement(this, delegate.prepareStatement(sql, columnNames));
}
Using the original singleton factory, the generated bytecode looked like this:
public final java.sql.PreparedStatement prepareStatement(java.lang.String, java.lang.String[]) throws java.sql.SQLException;
flags: ACC_PRIVATE, ACC_FINAL
Code:
stack=5, locals=3, args_size=3
0: getstatic #59 // Field PROXY_FACTORY:Lcom/zaxxer/hikari/proxy/ProxyFactory;
3: aload_0
4: aload_0
5: getfield #3 // Field delegate:Ljava/sql/Connection;
8: aload_1
9: aload_2
10: invokeinterface #74, 3 // InterfaceMethod java/sql/Connection.prepareStatement:(Ljava/lang/String;[Ljava/lang/String;)Ljava/sql/PreparedStatement;
15: invokevirtual #69 // Method com/zaxxer/hikari/proxy/ProxyFactory.getProxyPreparedStatement:(Lcom/zaxxer/hikari/proxy/ConnectionProxy;Ljava/sql/PreparedStatement;)Ljava/sql/PreparedStatement;
18: return
You can see that first there is a getstatic call to get the value of the static field PROXY_FACTORY, as well as (lastly) the invokevirtual call to getProxyPreparedStatement() on the ProxyFactory instance.
We eliminated the singleton factory (which was generated by Javassist) and replaced it with a final class having static methods (whose bodies are generated by Javassist). The Java code became:
public final PreparedStatement prepareStatement(String sql, String[] columnNames) throws SQLException
{
return ProxyFactory.getProxyPreparedStatement(this, delegate.prepareStatement(sql, columnNames));
}
Where getProxyPreparedStatement() is a static method defined in the ProxyFactory class. The resulting bytecode is:
private final java.sql.PreparedStatement prepareStatement(java.lang.String, java.lang.String[]) throws java.sql.SQLException;
flags: ACC_PRIVATE, ACC_FINAL
Code:
stack=4, locals=3, args_size=3
0: aload_0
1: aload_0
2: getfield #3 // Field delegate:Ljava/sql/Connection;
5: aload_1
6: aload_2
7: invokeinterface #72, 3 // InterfaceMethod java/sql/Connection.prepareStatement:(Ljava/lang/String;[Ljava/lang/String;)Ljava/sql/PreparedStatement;
12: invokestatic #67 // Method com/zaxxer/hikari/proxy/ProxyFactory.getProxyPreparedStatement:(Lcom/zaxxer/hikari/proxy/ConnectionProxy;Ljava/sql/PreparedStatement;)Ljava/sql/PreparedStatement;
15: areturn
There are three things of note here:
-
The
getstaticcall is gone.get static指令消失了
-
The
invokevirtualcall is replaced with ainvokestaticcall that is more easily optimized by the JVM.invokevirtual被替換成了invokestatic調用瘪校，更加容易被JVM優(yōu)化澄暮。（invokevirtual需要查詢虛方法表來確定方法的直接引用，invokestatic在類加載的解析階段就從符號引用轉成了直接引用 ） -
Lastly, possibly not noticed at first glance is that the stack size is reduced from 5 elements to 4 elements. This is because in the case of
invokevirtualthere is an implicit passing of the instance of ProxyFactory on the stack (i.ethis), and there is an additional (unseen) pop of that value from the stack whengetProxyPreparedStatement()was called.方法stack的深度從5變成了4.這是因為先前的
invokevirtual調用時需要在stack頂部Pop出一個ProxyFactory實例引用
In all, this change removed a static field access, a push and pop from the stack, and made the invocation easier for the JIT to optimize because the callsite is guaranteed not to change.
