《Spring設計思想-事務篇》1.數據庫連接和Java線程的關係

0. 前言

Spring作爲Java框架王者，當前已經是基礎容器框架的實際標準。Spring 除了提供了 IoC、AOP特性外，還有一個極其核心和重要的特性：數據庫事務。事務管理涉及到的技術點比較多，想完全理解需要花費一定的時間，本系列《Spring設計思想-事務篇》將通過如下幾個方面來闡述Spring的數據庫事務：

數據庫連接java.sql.Connection的特性、事務表示、以及和Java線程之間的天然關係；
數據庫的隔離級別和傳播機制
Spring 基於事務和連接池的抽象和設計
Spring 事務的實現原理

而本文作爲**《Spring設計思想-事務篇》** 的開篇，將深入數據庫連接 (java.sql.Connection對象)的特性，事務表示，以及和Java線程之間的天然關係。懂得了底層的基本原理，在這些基礎的概念之上再來理解Spring 事務，就會容易很多。

1. Java事務控制的基本單位： `java.sql.Conection`

在Java中，使用了java.sql.Connection實例來表示和數據庫的一個連接，通信的方式目前基本上採用的是TCP/IP 連接方式。通過對Connection進行一系列的事務控制。

可能有人有如下的想法：
既然java.sql.Connection可以完成事務操作，那我在寫代碼的時候，直接創建一個然後使用不就行了？
然而在事實上，我們並不能這麼做，這是因爲，java.sql.Connection和數據庫之間有非常緊密的關係，其數據庫的資源是很有限的。

1.1 `java.sql.Connection`-有限的系統資源

應用程序和數據庫之間建立 Connection連接，則數據庫機器會爲之分配一定的線程資源來維護這種連接，連接數越多，消耗數據庫的線程資源也就越多；另外不同的connection實例之間，可能會操作相同的表數據，也就是高併發，爲了支持數據庫對ACID特性的支持，數據庫又會犧牲更多的資源。簡單地來說，建立Connection連接，會消耗數據庫系統的如下資源：

資源	說明
線程數	線程越多，線程的上下文切換會越頻繁，會影響其處理能力
創建Connection的開銷	由於Connection負責和數據庫之間的通信，在創建環節會做大量的初始化，創建過程所需時間和內存資源上都有一定的開銷
內存資源	爲了維護Connection對象會消耗一定的內存
鎖佔用	在高併發模式下，不同的Connection可能會操作相同的表數據，就會存在鎖的情況，數據庫爲了維護這種鎖會有不少的內存開銷

上述的幾種資源會限制數據庫的鏈接數和處理性能。

結論：
數據庫資源是比較寶貴的有限資源，當應用程序有數據庫連接需求過大時，很容易會達到數據庫的連接併發瓶頸。
關於創建Connection過程的開銷，可以參考《深入理解mybatis原理》 Mybatis數據源與連接池第五節 “爲什麼要使用連接池？”

1.2 數據庫最多支持多少Connection連接？

以 MYSQL爲例，可以通過如下語句查詢數據庫的最大支持情況：

-- 查看當前數據庫最多支持多少數據庫連接
show variables like '%max_connections%';
-- 設置當前運行時mysql的最大連接數，服務重啓連接數將還原
set GLOBAL max_connections = 200;
-- 修改 my.ini 或者my.cnf 配置文件
max_connections = 200;

數據庫的連接數設置的越大越好嗎？
肯定不是的，連接數越大，對使用大量的線程維護，伴隨着大量的線程上下文切換，並且與此同時，連接數越多，表數據鎖使用的概率會更大，反而會導致整體數據庫的性能下降。具體的設置範圍，應當具體的業務背景來調優。

2. `java.sql.Connection`對象本身的特性— 線性操作和可以不限次數執行SQL事務操作

java.sql.Connection 本身有如下兩個比較關鍵的特性：

線性操作：即在操作的時序上，事務和事務之間的執行是線性排開依次執行的
當建立了 java.sql.Connection 連接後，可以不限次數執行事務SQL請求
由於Connection對象的通信值基於TCP/IP協議的，當初始化後在手動關閉之前和數據庫保持心跳存活連接，所以，可以使用Connection對象執行不限次數的SQL語句請求，包括事務請求
注意！！ 這個看似比較簡單的表述，在實際使用過程中非常重要，數據庫連接池就是基於此特性建立的

如下圖所示：

有上圖所示，對於java.sql.Connection對象的操作，一般會遵循序列化的事務操作模式，即：一個新事務的開啓，必須在上一個事務完成之後(如果存在的話)；換成另外一種表述方式就是：對connection的操作必須是線性的。

3. 如何在Java中實現對`java.sql.Connection`對象的線性操作？

3.1. 一個線程的整個生命週期中，可以獨佔一個`java.sql.Connection` 連接嗎？

Java中，當然一個線程可以在整個生命週期獨佔一個java.sql.Connection，使用該對象完成各種數據庫操作，因爲一個線程內的所有操作都是同步的和線性的。然而，在實際的項目中，並不會這樣做，原因有兩個：

Java中的線程數量可能遠超數據庫連接數量，會出現僧多粥少的情況
如上面章節1.2中提到的，一個MYSQL服務器的最大連接數量是有上限的，例子中提到的就是上限200;而在稍微大型一點的Java WEB項目中，光用戶的HTTP請求線程數，就不止200個，這樣就會出現部分線程無法獲取到數據庫連接，進而無法完成業務操作。
Java線程在工作過程中，真正訪問JDBC數據庫連接所佔用的時間比例很短
線程在接收到用戶請求後，有很多業務邏輯需要處理：比如參數校驗，權限驗證，數值計算，然後持久化結果；其中可能只有持久化結果環節需要訪問JDBC數據庫連接,其餘的時間範圍內，JDBC數據庫連接 都是空閒狀態。換言之，如果線程整個生命週期中獨佔JDBC數據庫連接，那麼，真個連接池的空閒率很高，使用率很低。
綜上所述，Java線程和JDBC數據庫連接的關係如下：

結論：
結合上述的兩個癥結，爲了提高JDBC數據庫連接的使用效率，目前普遍的解決方案是：當線程需要做數據庫操作時，纔會真正請求獲取JDBC數據庫連接,線程使用完了之後，立即釋放，被釋放的JDBC數據庫連接等待下次分配使用
基於這個結論，會衍生兩個問題需要解決：

Java多線程訪問同一個java.sql.Connection會有什麼問題？如何解決？

JDBC數據庫連接 如何管理和分配？(這個解決方案是：連接池，後面章節會詳細闡述)

通過上述的圖示中，可以看到，一個數據庫連接對象,在線程進行事務操作時，線程在此期間內是獨佔數據庫連接對象的，也就是說，在事務進行期間，有一個非常重要的特性，就是：數據庫連接對象可以吸附在線程上，我把這種特性稱之爲事務對象的線程吸附性 這種特性，正是由於這種特性，在Spring實現上，使用了基於線程的ThreadLocal來表示這種線程依附行爲。

3.1 Java多線程訪問同一個`java.sql.Connection`會有什麼問題？

Java多線程訪問同一個java.sql.Connection會導致事務錯亂。例如：現有線程thread #1 和線程thread #2,兩個線程會有如下數據庫操作:

thread #1:
update xxx; update yyy; commit;
thread #2:
delete zzz; insert ttt; rollback;
語句執行的序列在connection對象上，可能表現成了：
delete zzz; update xxx; insert ttt; rollback; update yyy; commit;

有上圖可以看到，Thread #1的請求 update xxx 被thread #2回退掉，導致語句丟失，thread #1的事務不完整

3.2 Java多線程訪問同一個`java.sql.Connection` 的原則

解決上述事務不完整的問題，從本質上而言，就是多線程訪互斥資源的方法。多線程互斥訪問資源的方式在Java中的實現方式有很多，如下使用有一個最簡單的使用 synchronized 關鍵字來實現 :

java.sql.Connection sharedConnection = <創建流程>
## thread #1 的業務僞代碼：

synchronized(sharedConnection){
         `update xxx`;    
         `update yyy`;  
         `commit`;
}
## thread #2 的業務僞代碼：

synchronized(sharedConnection){
       `delete zzz`;   
       `insert ttt`; 
       `rollback`;
}

上述的僞代碼在執行上能夠體現成如下的形式，即同一時間內，只有一個線程佔用Connection對象。
假設Thread #2先獲取到了Connection鎖，如下圖所示：

存在的問題
那上述的流程還有有點問題：假如 thread #2 在執行語句 delete zzz,insert ttt,rollback 的過程中，在insert ttt之前有一段業務代碼拋出了異常，導致語句只執行到了 delete zzz，這會導致在connection對象上有一個尚未提交的delete zzz請求; 當thread #1拿到了connection 對象的鎖之後，接着執行 update xxx; update yyy; commit;
即:在兩個線程執行完了之後，對connection的操作爲delete zzz; update xxx; update yyy; commit;
示例如下：

解決方案： 確保每個線程在使用Connection對象時，最終要明確對Connection做commit 或者rollback。
調整後的僞代碼如下所示：

java.sql.Connection sharedConnection = <創建流程>
## thread #1 的業務僞代碼：

synchronized(sharedConnection){
       try{
         ` update xxx`;    
         `update yyy`;  
         `commit`;
       } catch(Exception e){
          `rollback`; //之所以rollback ,是確保在執行事務的過程中，在connection對象上，清空尚未提交的所有SQL語句
      }
}
## thread #2 的業務僞代碼：

synchronized(sharedConnection){
       try{
       `delete zzz`;   
       `insert ttt`; 
       `rollback`;
       } catch(Exception e){
          `rollback`; //之所以rollback ,是確保在執行事務的過程中，在connection對象上，清空尚未提交的所有SQL語句
      }
}

綜上所述，解決多個線程訪問同一個Connection對象時，必須遵循兩個基本原則：

以資源互斥的方式訪問Connection對象；
在線程執行結束時，應當最終及時提交(commit)或回滾(rollback)對Connection的影響；不允許存在尚未被提交或者回滾的語句。

4. 當一個事務結束，`java.sql.Connection`實例有必要釋放銷燬嗎？

正常情況下，我們在寫業務代碼時，會有類似的流程：

創建一個java.sql.Connection實例；
基於java.sql.Connection 做相關事務提交操作
銷燬java.sql.Connection 實例

而實際上，在第三步驟，是完全沒有必要銷燬java.sql.Connection 實例的，這是因爲，在第二章節我們介紹的Connection的性質：當建立了 java.sql.Connection 連接後，可以不限次數執行事務SQL請求, 也就是說，當此次事務結束後，我可以緊接着使用這個Connection對象開啓下一個事務。
另外，由於創建一個java.sql.Connection 實例的代價本身就比較大，筆者測試的數據庫建立Connection的時間，一般都在至少0.1s級別，如果每一個事務在執行的時候，都要花費額外的0.1s 來做連接，會嚴重影響當前服務的性能和吞吐量。
結合上面的敘述，目前的做法，在完成事務後，並不會銷燬java.sql.Connection實例，而是將其回收到連接池中。

5. 連接池 ---- 統一管理`java.sql.Connection`的容器

一般連接池需要如下幾個功能：

管理一批Connection對象，一般會有連接數上限設置；
爲每一個獲取Connection請求做資源分配；如果資源不足，設置等待時間
根據實際Connection的使用情況，爲了提高系統之間的利用率，動態調整連接池中Connection對象的數量，如應用實際使用的連接數比較少時，會自動關閉掉一些處於無用狀態的連接；當請求量大的時候，再動態創建。

目前比較流行的幾個連接池解決方案有：HikariCP, 阿里的Druid, apache的DBCP等，具體的實現不是本文的重點，有興趣的同學可以研究下。

6.結語

本文對最基本的數據庫連接和線程之間的關係進行了探討，以及數據庫連接的管理-**連接池的角色和職能進行了概括。本文沒有複雜的概念陳述和實現介紹，是希望讀者腦海裏對數據庫事務的jdbc表示對象java.sql.Connection對象有一個清晰的認知，方便後續更復雜的Spring事務原理的詳細介紹。
接下來的幾篇，將會開始細化，具體話題如下：

數據庫的隔離級別和傳播機制
Spring 基於事務和連接池的抽象和設計
Spring 事務的實現原理

有興趣的同學可以持續關注，或者有感興趣的話題可以拋出來，一起探討。

作者聲明
如需轉載，請註明出處，亦山札記 https://blog.csdn.net/luanlouis
另外作者已開通微信訂閱號，精品文章同步更新，歡迎關注~

《Spring設計思想-事務篇》1.數據庫連接和Java線程的關係

0. 前言

1. Java事務控制的基本單位： `java.sql.Conection`

1.1 `java.sql.Connection`-有限的系統資源

1.2 數據庫最多支持多少Connection連接？

2. `java.sql.Connection`對象本身的特性— 線性操作和可以不限次數執行SQL事務操作

3. 如何在Java中實現對`java.sql.Connection`對象的線性操作？

3.1. 一個線程的整個生命週期中，可以獨佔一個`java.sql.Connection` 連接嗎？

3.1 Java多線程訪問同一個`java.sql.Connection`會有什麼問題？

3.2 Java多線程訪問同一個`java.sql.Connection` 的原則

4. 當一個事務結束，`java.sql.Connection`實例有必要釋放銷燬嗎？

5. 連接池 ---- 統一管理`java.sql.Connection`的容器

6.結語

使用neovim打造go ide(支持代碼跳轉, 代碼補全, 實時語法檢查)

挑戰程序設計競賽 2.3章習題 poj 3046 Ant Counting

Shell/Python中的用戶名獲取

Junit 4 Tutorials(Junit 4 教程) Junit4 七、超時測試

基於HTML5 Canvas和jQuery 的畫圖工具的實現

Spring Cloud Hystrix設計原理

Spring Cloud-Feign設計原理

《深入理解mybatis原理》 Mybatis數據源與連接池

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

《Spring設計思想-事務篇》1.數據庫連接和Java線程的關係

0. 前言

1. Java事務控制的基本單位 ： java.sql.Conection

1.1 java.sql.Connection-有限的系統資源

1.2 數據庫最多支持多少Connection連接？

2. java.sql.Connection對象本身的特性— 線性操作和可以不限次數執行SQL事務操作

3. 如何在Java中實現對java.sql.Connection對象的線性操作？

3.1. 一個線程的整個生命週期中，可以獨佔一個java.sql.Connection 連接嗎？

3.1 Java多線程訪問同一個java.sql.Connection會有什麼問題？

3.2 Java多線程訪問同一個java.sql.Connection 的原則

4. 當一個事務結束，java.sql.Connection實例有必要釋放銷燬嗎？

5. 連接池 ---- 統一管理java.sql.Connection的容器

6.結語

1. Java事務控制的基本單位： `java.sql.Conection`

1.1 `java.sql.Connection`-有限的系統資源

2. `java.sql.Connection`對象本身的特性— 線性操作和可以不限次數執行SQL事務操作

3. 如何在Java中實現對`java.sql.Connection`對象的線性操作？

3.1. 一個線程的整個生命週期中，可以獨佔一個`java.sql.Connection` 連接嗎？

3.1 Java多線程訪問同一個`java.sql.Connection`會有什麼問題？

3.2 Java多線程訪問同一個`java.sql.Connection` 的原則

4. 當一個事務結束，`java.sql.Connection`實例有必要釋放銷燬嗎？

5. 連接池 ---- 統一管理`java.sql.Connection`的容器