代碼不多，文章不長，簡要描述了下 DataSource 演進過程的故事

文章產出背景

---

最近這段時間一直忙著集團內部安全等保加密相關事項，初步決定使用 shardingsphere 來進行

因為項目眾多，需要兼容的需求也隨之而來，加密數據源和動態數據源的互相兼容，以及分庫分表和加密數據源的兼容等等，反正一言不合就兼容

無疑，上面這些或多或少都和數據源有關系，所以在處理不同兼容性等問題時，也讓我再次對 DataSource 產生了了解的興趣，這個曾經被很多人遺忘的重要概念

老時代的數據查詢

---

在很久很久以前（反正忘了多久），那個時候程序員連接數據庫還是這么個操作

可以清楚的看到，曾經獲取數據庫連接的代碼還需要使用 DriverManager，大家都清楚，DriverManager#getConnection 是通過數據庫驅動直接與數據庫建立連接

而建立數據庫連接屬于耗費時間的事情，如果業務層每次進行 SQL 查詢都使用此方式，將會產生較大的系統開銷

一般系統的性能要求，單次請求需要穩定在 200 ms。經過在本地環境測試，DriverManager 形式創建數據庫連接需要 300~500 ms 左右，健身五分鐘，拍照兩小時？

隨著系統的發展迭代，出于 系統的復雜度以及對性能的要求，這種獲取連接的方式是難以接受的

連接池的出現

---

相信有些讀者能夠聯想出來，數據庫連接創建消耗資源這個場景好像在哪聽過，沒錯，和線程創建的情況基本類似。既然線程可以用線程池關聯，那數據庫連接是不是可以放到一個池子中？

是的，還真有存放數據庫連接的池化技術，叫做 連接池。應用程序從連接池中獲取數據庫連接，使用過再放到池子里，是不是感覺很 Nice？完美的解決了重復創建消耗資源的情況

看似完美的背后，其實還存在一個致命的問題，那就是最開始去連接池中獲取連接時，連接池中是沒有連接的，還需要走創建流程

連接池是怎么解決這一問題呢？通過創建連接池時初始化其中的連接，一般連接池都有這樣一個參數 initialSize，代表池子中初始化的連接數量

下圖是 Druid 在執行 init 方法時數據庫連接初始化的流程，當初始化連接小于池內連接時，進行循環創建，直到池內連接滿足初始化數量

連接池、線程池…這些池化技術的核心思想就是 空間換取時間。因為在絕大數情況下，空間并沒有那么稀缺，我們更關心的是系統的性能

數據源登場

---

連接池雖然 🐂 🍺 ，但是獨木難支，連接池沒有產生連接的能力，所以還需要配合類似 DriverManager 組件與數據庫驅動配合創建連接。如果這樣放到業務代碼里，那豈不是還得封裝一層？

這個時候，不約而同的想到一個公司，sun 公司是干啥的？制定規范的對不對，他們在 jdbc 2.0 版本推出一個 DataSource 的東東，用來進行規范約束

相當于把 DriverManager 和連接池概念揉合在一起，如果你想獲取數據庫連接，你通過我 DataSource 獲取，你不用關心連接池和數據庫連接怎么創建的，用就完了。其實，DataSource 獲取的連接來自于連接池，而連接池的連接其實還是從 DriverManager或類似組件中創建的

DriverManager 只是 jdbc 1.0 版本用來調用數據庫驅動的的工具包，jdbc 2.0 版本推出 DataSource 之后，典型的像 DruidDataSource 就沒有依賴 DriverManager，而是在自己實現類中調用了數據庫驅動。這里只是重點強調，數據庫連接不一定是使用 DriverManager 創建

總結下，數據源（DataSource）是 sun 公司指定用于獲取數據庫連接的規范接口，應用程序于數據庫連接抽象的中間層，它存在于 javax.sql 包，用來代替 DriverManager 的方式獲取數據庫連接

使用 DataSource 比 DriverManager 到底有什么好處呢

DriverManager

• 在應用程序里創建/關閉連接時會妨礙應用程序性能

• 不支持連接池，重復創建/關閉連接，浪費系統性能

DataSource

• 由于不在應用程序中創建/關閉連接，可以很好的提高應用程序性能

• 提供了連接池的功能，避免重復創建

這里畫一張圖來描述下，針對應用程序使用 DataSource 和 DriverManager 獲取連接的不同

有了 DataSource 之后，數據庫連接、用戶名、密碼都進行了統一的管理，作為 DataSource 屬性的一部分，并且將數據庫驅動名稱填充，底層自動加載

DataSource 技術解析

---

我們先來看下 DataSource 的接口描述以及對應的方法，先初步進行了解

DataSource 中只有兩個接口，是一個重載的關系，用于建立 DataSource 所代表數據源的數據庫連接

這里應該注意的是 CommonDataSource 接口，公共數據源接口用來定義以下三個數據源接口的公共方法

• javax.sql.DataSource：定義基礎獲取數據庫連接的接口

• javax.sql.ConnectionPoolDataSource：定義從數據庫連接池中獲取連接的接口

• javax.sql.XADataSource：定義獲取分布式事務連接的接口。一般少有直接使用 XA 分布式事務，具體原因參考 分布式 2PC、3PC 事務模型

第一、二種就比較容易理解，sun 公司定義規范時，就是希望你 普通獲取數據庫連接使用 DataSource，數據源底層如果是連接池那么使用 ConnectionPoolDataSource

后面發展逐漸脫離了原本的軌道預期，比如 DruidDataSource 就同時實現了兩者，類圖如下

其實這樣也沒啥事，DruidDataSource 一個類包裝兩種 DataSource 接口實現，這種方式對于使用者是無感知的

完事總結

---

文章使用循序漸進的方式，幫助大家梳理了一遍 DataSource 產出背景

講述了 jdbc 1.0 版本獲取數據庫連接的方式 DriverManager，發展到 2.0 后的 DataSource，以及其中引入的數據庫連接池技術

相信讀者看完對 DataSource 應該有了更深入的了解，感興趣的讀者可以去研讀 Hikari 和 Druid 實現的數據源，通過閱讀源碼的方式能夠更好的理解 DataSource 設計思路

總結

以上是生活随笔為你收集整理的DataSource接口，一个被大多数程序员忽略的接口的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。