轉載自：https://www.jianshu.com/p/b9b98ac3e010
一、主流數據庫連接池
C3p0: 實現數據源和JNDI綁定，支持JDBC3規範和JDBC2的標準擴展。Hibernate、Spring使用。單線程，性能較差，適用於小型系統，代碼600KB左右。
DBCP (Database Connection Pool):Apache的， commons-pool對象池機制，Tomcat使用。單獨使用dbcp需要3個包：common-dbcp.jar,common-pool.jar,common-collections.jar，預先將數據庫連接放內存中，建立數據庫連接時，直接到連接池中申請，用完放回。單線程，併發量低，性能不好，適用於小型系統。
Tomcat Jdbc Pool：Tomcat在7.0以前都是使用，單線程，保證線程安全會鎖整個連接池，性能差，超過60個類複雜。Tomcat從7.0開始叫做Tomcat jdbc pool，基於Tomcat JULI，使用Tomcat日誌框架，完全兼容dbcp，異步方式獲取連接，支持高併發應用環境，核心文件8個，支持JMX，支持XA Connection。
BoneCP：高效、免費。設計提高性能，速度最快，高度可擴展：集成Hibernate和DataNucleus中。連接狀態切換的回調機制；允許直接訪問連接；自動化重置能力；JMX支持；懶加載能力；支持XML和屬性文件配置方式；較好的Java代碼組織，100%單元測試分支代碼覆蓋率；代碼40KB左右。
Druid：Java中最好，強大監控和擴展，可用於大數據實時查詢和分析的高容錯、高性能分佈式系統，尤其是當發生代碼部署、機器故障以及其他產品系統遇到宕機等情況時，100%正常運行。主要特色：分析監控；交互式查詢快；高可用；可擴展；
主流連接池各項功能對比如下：
有HikariCP的
二、HikariCP性能分析：
HikariCP通過優化**(concurrentBag，fastStatementList** )集合來提高併發的讀寫效率。
使用threadlocal緩存連接及大量使用CAS的機制，最大限度的避免lock。可能帶來cpu使用率的上升。
字節碼的維度優化代碼。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes ）讓方法儘量在35個字節碼一下，提升jvm的處理效率。HikariCP做的優化補充如下：
mysql connecter 源碼裏用的就是ping命令
比HikariCP更快的數據庫連接池：https://github.com/mauricio/postgresql-async
scala生態圈的。用netty實現mysql協議，沒用mysql官方connector，純異步，連接池寫的隨便，性能依然很好。
三、前瞻，未來到底是HikariCP還是Druid的天下？
容器調度加編排的雲操作系統取而代單機的操作系統。裸機或者虛擬機的運行時也將會被容器取代。通信方面將會使用Service Mesh。
中間件趨勢是弱化到無感知。maven依賴問題，把二方庫寫在pom裏，監控等代碼的硬編碼進應用裏都將逐漸弱化到不復存在，取而代之的那些java agent（如pinpoint、skywalking之類），或是service mesh這種side car模式都是可以做中間件（包括連接池）的監控的。
有贊用HikariCP替換durid後，RT出現斷崖式下滑（1.5ms ～ 1.2ms） 並且持續穩定毛刺少。性能測試與壓測之後，比druid性能提高一倍。
未來的中間件，一定是和spring生態圈、servich mesh一樣，大道至簡，越來越薄，升級中間件不再是需要用戶強行升級maven依賴解決依賴衝突，而是通過mesh的方式極致到升級讓業務方無感知。熱部署、潘多拉boot、容器隔離等解決依賴衝突的妥協方式也將可能大概率被置換掉。
四、從Sharding-jdbc架構演進看未來
Database Mesh（搭乘 Service Mesh 新詞）：用齧合層將數據庫（散落系統各個角落）統一治理。
首要目標：齧合應用與數據庫間的交互（這樣的交互網絡像蜘蛛網一樣複雜而有序），不是齧合db中的數據，將分佈式數據訪問應用與數據庫有機串聯。Sharding-JDBC 以 JDBC 層分片架構圖如下：
Sharding-JDBC 分別實現 Driver、Server 、Sidecar 三個不同版本，組成 Sharding-JDBC 的生態圈，爲不同的需求與環境提供差異化服務。
Sharding-JDBC-Server 使原來 DBA 通過 Sharding-JDBC-Driver無法對數據進行操作的缺憾得到了補償。由於 Sharding-JDBC-Driver 無需通過代理層進行二次轉發，因此線上性能更佳，可通過以下的混合部署方案使用 Sharding-JDBC:
Sharding-JDBC-Driver：
線上應用使用，直連數據庫以獲取最優性能；
用 MySQL 命令行或 UI 客戶端，連接 Sharding-JDBC-Server 方便的查詢數據和執行各種 DDL 語句。
同一註冊中心集羣，通過管理端配置註冊中心中的數據，註冊中心自動將配置變更推送至 Driver 和 Server 應用。若數據庫拆分的過多而導致連接數會暴漲，則可以考慮直接在線上使用 Sharding-JDBC-Server，以達到有效控制連接數的目的。
Sharding-JDBC-Sidecar 將問世，部署架構：
基於 Sharding-JDBC 的 Database Mesh 與 Service Mesh 互不干擾，相得益彰。服務之間的交互由 Service Mesh Sidecar接管，基於 SQL 的數據庫訪問由 Sharding-JDBC-Sidecar接管（隨着宿主機的生命週期創建和消亡的）。
非靜態 IP，完全動態和彈性的存在，無中心節點。數據運維等操作，啓動Sharding-JDBC-Server 進程作爲靜態 IP 入口，通過各種命令行或 UI 客戶端進行操作。