這篇文章想要解釋Spring為什麼會選擇使用ThreadLocal將資源和事務繫結到執行緒上，這背後有著什麼樣的起因和設計動機，通過分析幫助大家更清晰地認識Spring的執行緒繫結機制。

“原始”的資料訪問寫法

訪問任何帶有事務特性的資源系統，像資料庫，都有著相同的特點：首先你需要獲得一個訪問資源的“管道”，對於資料庫來說，這個所謂的“管道”是JDBC裡的Connection,是Hibernate裡的Session.然後你會通過“管道”下達一系列的讀寫指令，比如資料庫的SQL，最後你會斷開這個“管道”，釋放對這個資源的連線。在Spring裡，用訪問資源的“管道”來指代資源，因此JDBC的Connection和Hibernate的Session都被稱之為“資源”(Resource)(本文會交替使用這兩種稱呼)。另一方面，資源與事務又有著緊密的關係，事務的開啟與提交都是在某個“Resource”上進行的。以Hibernate為例，一種“原始”的資料訪問程式往往會寫成這樣：

1. Session session = sessionFactory.openSession();//獲取“資源”
2. Transaction tx = null;  
3. try {  
4.     tx = session.beginTransaction(); //開始事務
5.     ....  
6.     DomainObject domainObject = session.load(...); //資料訪問操作
7.     ....  
8.     domainObject.processSomeBusinessLogic();//業務邏輯計算
9.     ....  
10.     session.save(domainObject); //另一個數據訪問操作
11.     ....  
12.     session.save(anotherDomainObject); //又一個數據訪問操作
13.     ....  
14.     session.commit(); //提交事務
15. }  
16. catch (RuntimeException e) {  
17.     tx.rollback();  
18.     throw e;  
19. }  
20. finally {  
21.     session.close(); //釋放資源
22. }  

上述程式碼的思路很直白：首先獲得資料庫“資源”，然後在該資源上開始一個事務，經過一系列夾雜著業務計算和資料訪問的操作之後，提交事務,釋放資源。

分層帶來的困擾

相信很多人一下就能看出上面程式碼的問題：業務邏輯與資料訪問摻雜在了一起，犯了分層的“忌諱”。一個良好的分層系統往往是這樣實現上述程式碼的：使用Service實現業務邏輯，使用DAO向Service提供資料訪問支援。

某個Service的實現類：

1. publicclass MyServiceImpl implements MyService {  
2.     publicvoid processBusiness(){  
3.         //在這裡獲得資源並開啟事務麼？NO！會引入資料訪問的API，“汙染"Service，破壞了分層!
4.         //Session session = sessionFactory.openSession();
5.         //session.beginTransaction();
6.         ....  
7.         DomainObject domainObject = myDao.getDomainObject(...); //資料訪問操作
8.         ....  
9.         domainObject.processSomeBusinessLogic();//業務邏輯計算
10.         ....  
11.         myDao.save(domainObject); //另一個數據訪問操作
12.         ....  
13.         myDao.save(anotherDomainObject); //又一個數據訪問操作
14.         ....          
15.     }     
16.     ....  
17. }  

某個DAO的Hibernate實現類：

1. publicclass MyDaoHibernateImpl implements MyDao {  
2.     publicvoid save(DomainObject domainObject){  
3.         //在這裡獲得資源並開啟事務麼？NO！你怎麼確定這個方法一定是一個獨立的事務
4.         //而不會是某個事務的一部分呢？比如我們上面的Service。
5.         //Session session = sessionFactory.openSession();
6.         //session.beginTransaction();
7.         ....  
8.         session.save(domainObject);  
9.     }     
10.     ....  
11. }  

1. 如何“透明”地進行事務定界(Transaction Demarcation)?
2. 如何構建一個“上下文”，在事務開始與事務提交時，以及在事務過程中所有資料訪問方法都能“隱式”地得到“同一個資源”(資料庫連線/Hibernate Session)。所謂“隱式”是指不能把同一個資源例項用引數的方式傳給資料訪問方法，否則必然會出現資料訪問層的上層程式碼受到資料訪問專有API汙染的問題(即破獲了分層)，而使用全域性變數顯然是不行的，因為全域性變數是唯一的，沒有哪個應用能容忍只使用一個數據庫連線，對於一個使用者請求一個執行緒的多執行緒Web應用環境更是如此。

Spring使用基於AOP的宣告式事務定界解決了第一個問題，而使用基於ThreadLocal的資源與事務執行緒繫結成功地解決了第二個問題。(關於spring的具體實現，可以參考我的另一篇文章：Spring原始碼解析(一) Spring事務控制之Hibernate ，第一個問題所涉及原始碼主要是：

org.springframework.aop.framework.JdkDynamicAopProxy 和 org.springframework.transaction.interceptor.TransactionInterceptor 

第二個問題所涉及原始碼主要是：

org.springframework.transaction.support.AbstractPlatformTransactionManager 和 org.springframework.transaction.support.TransactionSynchronizationManager)

1.  “上下文”：Spring使用的是“執行緒上下文”，也就是TreadLocal,原因非常簡單，做為一種執行緒作用域變數，它能很好地被“隱式”獲取，即在當前執行緒下可以直接得到該變數(避免了引數傳遞)，同時又不會像全域性變數那樣作用域過大且全域性只有一個例項。實際上，從更大的背景上來看，大多數的spring應用為B/S架構的web應用，受servlet執行緒模型的影響，此類web應用都是一個使用者請求到達開啟一個新的執行緒進行處理，在此背景下，spring這種以執行緒作為上下文繫結資源和事務的處理方式無疑是非常合適的。
2. “資源與事務的生命週期”：如果只從“執行緒繫結”的字面上理解，很容易讓人誤解為繫結到執行緒上的資源和事務的生命週期與執行緒是等長的，這是錯誤的。實際上，資源和事務的生命週期與執行緒生命週期沒有必然聯絡，只是當資源和事務存在時，它們會以TreadLocal的形式繫結到執行緒上而已。而資源的生命週期與事務的生命週期才是等長的，我們把資源-事務這種生命週期關係稱為：Connection-Per-Transaction 或是 Session-Per-Transaction。
   

1. 對session的資料操作方法進行攔截，確認在執行操作前已經呼叫過begainTranscation()開啟了一個事務，否則會丟擲異常。這一點確保了對session的使用必須總是從建立一個事務開始的。
2. 當事務在commit或rollback後session會自動關閉。這一點確保了事務提交後session也將不可用。
   

1. 若當前執行緒執行到了一個需要進行事務控制的方法(如某個service的方法)，通過AOP攔截，spring會在方法執行前申請一個數據庫連線或者一個hibernate session.
2.  成功獲得資源後，開啟一個事務。
3. 將資源也就是資料庫連線或是hibernate session的例項存放於當前執行緒的ThreadLocal裡(也就是進行所謂的執行緒繫結)
4. 在方法執行過程中，任何需要獲得資料庫連線或是hibernate session進行資料訪問的地方都會從當前執行緒的ThreadLocal裡取出同一個資料庫連線或是hibernate session的例項進行操作(這個動作由Spring提供的各種Template類實現)。
5. 方法執行結束，同樣通過AOP攔截，spring取出繫結到當前執行緒上的事務(對於hibernate來說就是取出繫結在當前執行緒上一個SessionHolder例項，它儲存著當前的session與transaction例項)，執行提交。
6. 事務提交之後，釋放資源，清空當前執行緒上繫結的所有物件！
7. 如果該執行緒之後有新的事務發起，一切會重新開始，Spring會使用新的資料庫連線或是hibernate session例項，開始新的事務，兩個事務之間沒有任何關係。
   

1. Connection-Per-Transaction/Session-Per-Transaction幾乎總是你需要的。
2. 在分層架構中，有些變數或物件確實需要跨越分層工作（比如本文示例中的Connection/Session/Transaction),你可能需一種“上下文”(或者說是一種跨層的作用域)來存放這種變數或是物件，從而避免以“引數”的形式在層間傳遞它，執行緒區域性變數ThreadLocal可能正是你需要的.