mybatis原理分析(三)---一級快取和二級快取

1.概述

上一篇博客《mybatis原理分析(二)—深入理解Executor》中介紹了mybatis中的一個重要的組件Executor，還有兩個該組件的實作類沒有介紹，那就是BaseExecutor和CachingExecutor，它們分別去處理一級快取的邏輯和二級快取的邏輯，這篇博客主要就是介紹這兩種快取的差別和命中場景，并且分析原始碼來看看mybatis是如何實作的一級快取和二級快取，

1.1 BaseExecutor

BaseExecutor是上一篇博客中介紹的三個Executor的父類，主要的功能就是維護一級快取和對事務的管理，事務是通過會話中呼叫commit、rollback來管理，重點在于快取這塊是如何處理的，它提供基本的api如query和update，在query方法中處理一級快取的邏輯，即根據sql以及引數等條件來判斷快取中是否有資料，有的話就走快取，沒有的話就會呼叫子類的doQuery方法來執行查詢，而在update方法中，對于快取方面的參與就是清空快取，

1.2 CachingExecutor

CachingExecutor，處理二級快取的邏輯，二級快取默認是關閉的，而一級快取默認是打開的且必須是打開的，之后會說明為什么，

二級快取可以根據引數來控制開啟或者關閉，它的實作是采用了裝飾者的方式，在CachingExecutor中聚合了一個BaseExecutor，處理完二級快取的邏輯后，剩余的邏輯就交給里面的Executor來實作，看下面的測驗代碼

將簡單執行器聚合到快取執行器中，來執行兩次查詢，控制臺的輸出內容如下：

第一次查詢快取中沒有所以命中率為0.而第二次查詢的時候可以看到命中率變成了0.5 說明第二次查詢命中了快取，兩次查詢中有一次查詢命中了快取，算出命中率為0.5

若直接使用簡單快取執行器的結果如下：

sql預編譯了兩次，并且執行了兩次sql查詢，不會走二級快取，

2.一級快取

一級快取也叫做會話級快取，生命周期僅存在于當前會話，不可以直接關關閉，但可以通過flushCache和localCacheScope對其做相應控制，一級快取默認打開，

2.1 一級快取的命中場景

因為快取中的key是由以下引陣列成的，所以快取的命中條件就是以下引數構成的key在快取中可以找到，

• SQL與引數相同
• 同一個會話
• 相同的MapperStatement ID
• RowBounds行范圍相同

2.2 觸發清空一級快取

1. 手動呼叫clearLocalCache,在BaseExecutor中有這個方法可以清空一級快取

   

2. 執行提交回滾，都會去呼叫上面的這個清空一級快取的方法

3. 執行update操作

4. 配置flushCache=true 在子查詢的時候不會清空 清空快取不能發生在子查詢里面，

   在query方法中有如下判斷，說明當flushCache設為true的時候，并且不是子查詢的時候，會清空一級快取，queryStack表示子查詢遞回的層數，

   

5. 快取作用域改為Statement 同理 子查詢的時候不會清空

   同樣在query方法中有另一個判斷，如下：判斷快取的作用與是不是statement否則，就會將其清空，

   可以在mybatis的組態檔中修改一級快取的作用域 如下：

4和5的差別是 4是在查詢前清空，5是在查詢后清空，

2.3 一級快取原始碼分析

如下的測驗代碼，debug除錯

首先進來的是BaseExecutor的方法，第一行代碼是動態系結sql，這里先不考慮是如何實作的，后面會當作一個專題寫一篇博客來介紹，

第二行就是做的創建快取key，點進去一探究進

就是將MapperStatement的id，分頁引數，sql陳述句，傳入的引數都保存在cachekey中，這也說明了為什么只有當這些條件都一樣的時候，才會命中快取，

創建好了快取key 會去呼叫BaseExecutor中的另一個多載的query方法

看紅色的框框，這里根據快取key從localCache中獲取物件，這個localCache也就是一級快取，localCache是一個PerpetualCache物件，里面有一個cache Map集合，

快取key作為鍵，查詢的結果作為value，

如果從快取中拿到了結果 則將結果回傳，如果沒有則將執行queryFromDatabase去查詢資料庫，會將快取key和結果集放入一級快取中，

BaseExecutor中的query和queryFromDatabase 也是解決嵌套子查詢中回圈依賴問題的關鍵，后面會單獨寫一篇博客來講這個知識點，現在我們只要關注于一級快取是如何實作的即可，

3 二級快取

二級快取也稱作是應用級快取，與一級快取不同的，是它的作用范圍是整個應用，而且可以跨執行緒使用，所以二級快取有更高的命中率，適合快取一些修改較少的資料，在流程上是先訪問二級快取，在訪問一級快取，

3.1 二級快取的設計

一個應用級別的快取，需要考慮如何存盤快取，溢位淘汰機制的設計等，

mybatis中，使用了責任鏈的設計模式，將這一串的邏輯，設計成可拔插，自由組裝的組件，責任鏈模式顧名思義就是每一個階段處理一個階段的責任，將責任細化，方便擴展和使用，

涉及到的組件如下：都是一個一個套娃的形式，內部聚合了下一個組件，這樣執行完這一層的邏輯可以交給下一個組件執行

事務組件TransactionalCache->同步組件SynchronizedCache->日志組件LoggingCache->序列化組件SerializedCache->移除淘汰組件LruCache->存盤策略組件PerpetualCache

從這一串默認的二級快取的執行組件中可以看出，mybatis使用的默認的溢位淘汰機制是最近最少使用(LRU)，使用的存盤策略是記憶體存盤，

仔細看看原始碼里每一個組件都干了些什么

1. 除錯原始碼，可以發現上面這一串的邏輯是在執行了commit的時候進行的，commit處打個斷點，

2. CachingExecutor

   由CachingExecutor內部聚合的Executor去執行會話提交，然后提交事務快取管理器的暫存區，進行更新二級快取的操作，

   

3. TransactionalCacheManager

   管理二級快取空間和對應的暫存區的關系，一一對應，有多少個二級快取空間，每個執行緒內就有多少個暫存區，

   遍歷暫存區，執行事務組件的commit方法

4. TransactionalCache

   判斷是否設定了提交后清空，然后執行flushPendingEntries，遍歷快取在事務快取管理器的暫存區里的物件，一個一個的執行下一個組件的putObject方法，也就是將暫存區里的鍵值對都更新到二級快取空間中，
   
   

5. SynchronizedCache

   這個組件只做一件事情，為每個方法做同步處理，加上了synchronized，因為二級快取是執行緒共享的，所以需要做同步處理

   

6. LoggingCache

   這是日志組件，僅對getObject方法做了修改，列印出日志，計算輸出二級快取的命中率
   

7. SerializedCache

   序列化組件，put的時候將查詢結果進行序列化，get的時候進行反序列化，因為二級快取是跨執行緒使用的，若保存在快取中的物件不進行序列化的話，之后多個執行緒拿到的物件是同一個物件 這樣會有執行緒安全的問題，
   

8. LruCache

   溢位淘汰機制組件，默認是最近最少使用的淘汰掉，

   
   

9. PerpetualCache

   存盤策略組件，采用記憶體存盤，

   

3.2 二級快取的使用

二級快取默認是不開啟的，需要為其宣告快取空間才可以使用，通過在mapper上設定注解

或者在mybatis的組態檔中，設定打開二級快取的支持

然后在mapper中設定

< cache/> 表示開啟這個mapper的二級快取空間

值得注意的是，如果UserMapper中加了二級快取的注解 并且UserMapper.xml中同時設定了< cache/> 將會報錯，需要將其中之一改成二級快取的空間參考，例如在xml中將< cache/> 改成 指向注解宣告的快取空間，

@CacheNamespace 注解詳細的配置資訊見下圖，說明可以對這個二級快取做自定義，實作自定義的相關實作類，例如自定義的存盤實作類，自定義的快取溢位淘汰機制，默認是最近最少使用，

3.3 二級快取的命中場景

1. 相同sql和引數
2. 相同的statement的id
3. RowBounds行范圍相同
4. 會話提交之后

3.4 二級快取原始碼分析

3.4.1 query查詢操作，

1. 首先執行的CachingExecutor的query方法，獲取動態系結sql，創建快取key然后執行另一個多載的query方法，快取key和一級快取中的一樣，
   

2. 這里做的事情就比較多了，從statement中得到二級快取空間，判斷二級快取空間是否存在，也就是有沒有開啟二級快取的支持，如果有，則進入第一個if，沒有的話就交給里面BaseExecutor執行它的query邏輯，
   

3. flushCacheIfRequired(ms) 檢查是否設定了清空二級快取的引數，如果是true，則執行清空二級快取，默認的查詢相關的statement中的flushCacheRequired屬性是false，可以通過手動的將其設定為true，那么在執行查詢的時候也會清空二級快取，

4. ensureNoOutParams 如果是callcabelStatement 不支持對出參的快取，拋出例外

5. tcm.getObject 從二級快取中找是否存在快取key對應的結果，如果此時還沒有創建二級快取空間對應的暫存區，則執行創建，事務快取管理器里面維護了一個暫存區Map，二級快取空間作為key，暫存區作為value，一一對應，并且將這個key，記錄下來，表明它沒有命中，

   TransactionalCache 中的 private final Set entriesMissedInCache;就是用來記錄沒有命中的快取key

   

6. 如果此時二級快取中沒有，則執行查詢操作，

7. 將結果集，放入到事務快取管理器的暫存區中，

   

   

   TransactionalCache 中的 private final Map<Object, Object> entriesToAddOnCommit //暫存區，key是之前創建出來的快取key，value是對應的查詢結果，

3.4.2 commit提交操作，

1. 首先來到CachingExecutor 中的comit方法 主要做兩件事情，一是將會話提交，清空一級快取，二是提交事務快取管理器中的所有暫存區，進行更新二級快取的操作，
   

2. TransactionalCacheManager 中的commit

   會話提交這里不考慮，看看事務快取管理器中的commit方法

   遍歷暫存區，對每一個暫存區執行提交操作，

   

3. TransactionalCache 中的commit

   執行flushPendingEntries 和 reset

   

4. flushPendingEntries

   遍歷暫存區所有的鍵值對，全部放到二級快取空間中，然后遍歷之前存放的沒有命中二級快取中的快取key，如果這個鍵在暫存區沒有出現過，則將這個鍵和null值提交給二級快取空間，這樣做的目的是為了避免無效的查詢，多次的去查詢資料庫，而造成資料庫很大的壓力負擔，也就是解決快取穿透的問題，
   

3.4.3 update操作

1. 首先來到的是CachingExecutor中的update方法，做兩件事情，清空暫存區并設定提交清空標記為true，交給baseExecutor執行它的update邏輯，

2. 檢查清空快取標記是否為true，對于update相關的statement中的flushCacheRequired屬性默認是true，所以對于update操作必然會清空二級快取，而Select相關的statement中的flushCacheRequired屬性默認是false，如果將這個屬性手動的設定為true，則也會執行清空二級快取的操作，讓我們看看快取事務管理器中的clear是做了哪些事情

   

3. 根據二級快取空間拿到對應的暫存區，執行clear

   

4. 設定提交時清空標記為true，然后清空暫存區，可以看到此時并沒有真正的對二級快取空間進行清空，而僅僅是設定了提交時清空標記，等到執行commit的時候，才會清空二級快取空間，

   

3.5 為什么只有會話提交成功才會更新或清空二級快取

假設現在資料庫中有一行資料，name=gongsenlin，age=18

此時第一個執行緒，執行了update操作，將age更新成了16，并且執行了select方法，若不是按照mybatis的設計思路提交后才更新二級快取，而是直接在查詢后就更新二級快取，

那么此時第二個執行緒執行select方法，會看到二級快取中有資料，則直接從二級快取中獲取，會查詢到name=gongsenlin，age=16，

但是此時第一個執行緒突然出現了錯誤，回滾了，之前的更新操作失效了，那么此時資料庫中的資料又回到了name=gongsenlin，age=18，

但是第二個執行緒卻讀到了age=16，造成了臟讀，所以mybatis是為了避免多執行緒臟讀的出現，才設計成提交后更新或清空二級快取，

4. 后續

下一篇博客介紹mybatis中的Jdbc處理器—StatementHandler，