爲了增加查詢的性能,MyBatis 提供了二級緩存架構,分爲一級緩存和二級緩存。
這兩級緩存最大的區別就是:一級緩存是會話級別的,只要出了這個 SqlSession,緩存就沒用了。而二級緩存可以跨會話,多個會話可以使用相同的緩存!
一級緩存使用簡單,默認就開啓。二級緩存需要手動開啓,相對複雜,而且要注意的事項也多,否則可能有隱患。
一級緩存
應用場景
訂單表與會員表是存在一對多的關係,爲了儘可能減少 join 查詢,進行了分階段查詢。即先查詢出訂單表,再根據 member_id 字段查詢出會員表,最後進行數據整合。而如果訂單表中存在重複的 member_id,就會出現很多重複查詢。
針對這種情況,MyBatis 通過一級緩存來解決:在同一次查詢會話(SqlSession)中如果出現相同的語句及參數,就會從緩存中取出,不再走數據庫查詢。
一級緩存只能作用於查詢會話中,所以也叫做會話緩存。
生效的條件
一級緩存要生效,必須滿足以下條件條件:
- 必須是相同的會話
- 必須是同一個 mapper,即同一個 namespace
- 必須是相同的 statement,即同一個 mapper 中的同一個方法
- 必須是相同的 SQL 和參數
- 查詢語句中間沒有執行 session.clearCache() 方法
- 查詢語句中間沒有執行 insert/update/delete 方法(無論變動記錄是否與緩存數據有無關係)
與 SpringBoot 集成時一級緩存不生效原因
因爲一級緩存是會話級別的,要生效的話,必須要在同一個 SqlSession 中。但是與 SpringBoot 集成的 MyBatis,默認每次執行 SQL 語句時,都會創建一個新的 SqlSession!所以一級緩存纔沒有生效。
當調用 mapper 的方法時,最終會執行到 SqlSessionUtils 的 getSqlSession 方法,在這個方法中會嘗試在事務管理器中獲取 SqlSession,如果沒有開啓事務,那麼就會 new 一個 DefaultSqlSession。
所以說,即便在同一個方法中,通過同一個 mapper 連續調用兩次相同的查詢方法,也不會觸發一級緩存。
解決與 SpringBoot 集成時一級緩存不生效問題
Spring Boot 基礎就不介紹了,推薦看這個實戰項目:
在上面的代碼中也看到了,MyBatis 在查詢時,會先從事務管理器中嘗試獲取 SqlSession,取不到纔會去創建新的 SqlSession。所以可以猜測只要將方法開啓事務,那麼一級緩存就會生效。
加上 @Transactional 註解,看下效果:
沒錯,的確生效了。在代碼中可以看到,從事務管理器中,獲取到了 SqlSession:
再看看源碼中是什麼時候將 SqlSession 設置到事務管理器中的。
SqlSessionUtils 中,在獲取到 SqlSession 後,會調用 registerSessionHolder 方法註冊 SessionHolder 到事務管理器:
具體是在 TransactionSynchronizationManager 的 bindResource 方法中操作的,將 SessionHolder 保存到線程本地變量 (ThreadLocal) resources 中,這是每個線程獨享的:
然後在下次查詢時,就可以從這裏取出此 SqlSession,使用同一個 SqlSession 查詢,一級緩存就生效了。
所以基本原理就是:如果當前線程存在事物,並且存在相關會話,就從 ThreadLocal 中取出。如果沒有事務,就重新創建一個 SqlSession 並存儲到 ThreadLocal 當中,共下次查詢使用。
至於緩存查詢數據的地方,是在 BaseExecutor 中的 queryFromDatabase 方法中。執行 doQuery 從數據庫中查詢數據後,會立馬緩存到 localCache(PerpetualCache類型) 中:
二級緩存
應用場景
業務系統中存在很多的靜態數據如,字典表、菜單表、權限表等,這些數據的特性是不會輕易修改但又是查詢的熱點數據。
一級緩存針對的是同一個會話當中相同 SQL,並不適合熱點數據的緩存場景。
爲了解決這個問題引入了二級緩存,它脫離於會話之外,多個會話可以使用相同的緩存。
看一個例子:
@RestController
@RequestMapping("item")
public class ItemController {
@Autowired
private ItemMapper itemMapper;
@GetMapping("/{id}")
public void getById(@PathVariable("id") Long id) {
System.out.println("==================== begin ====================");
Item item = itemMapper.selectById(id);
System.out.println(JSON.toJSONString(item));
}
}
當發送兩次 get 請求時(兩個不同的會話),通過日誌可以發現第二次查詢使用的是緩存。
開啓的方法
二級緩存需要手動來開啓,MyBatis 默認沒有開啓二級緩存。
1)在 yaml 中配置 cache-enabled 爲 true
mybatis-plus:
configuration:
cache-enabled: true
2)Mapper 接口上添加 @CacheNamespace 註解
3)實體類實現 Serializable 接口
生效的條件
- 當會話提交或關閉之後纔會填充二級緩存
- 必須是同一個 mapper,即同一個命名空間
- 必須是相同的 statement,即同一個 mapper 中的同一個方法
- 必須是相同的 SQL 語句和參數
- 如果 readWrite=true(默認就是true),實體對像必須實現 Serializable 接口
緩存清除條件
- 只有修改會話提交之後,纔會執行清空操作
- xml 中配置的 update 不能清空 @CacheNamespace 中的緩存數據
- 任何一種增刪改操作都會清空整個 namespace 中的緩存
源碼中是如何填充二級緩存的?
在生效條件中提到了,二級緩存必須要在會話提交或關閉之後,才能生效!
在查詢到結果後,會調用 SqlSession 的 commit 方法進行提交(如果開啓事務的話,提交 SqlSession 走的不是這裏了,但最終填充二級緩存的地方是一樣的):
在此方法中,最終會調用到 TransactionalCache 的 flushPendingEntries 方法中填充二級緩存:
SpringBoot 集成 MyBatis 的話,如果沒有開啓事務,每次執行查詢,都會創建新的 SqlSession,所以即使是在同一個方法中進行查詢操作,那也是跨會話的。
查詢時如何使用二級緩存?
在查詢的時候,最終會調用 MybatisCachingExecutor 的 query 方法,裏面會從 TransactionalCacheManager 中嘗試根據 key 獲取二級緩存的內容。
可以看到,這個 key 很長,由 mapper、調用的查詢方法、SQL 等信息拼接而成,這也是爲什麼想要二級緩存生效,必須滿足前面所說的條件。
如果能在二級緩存中查詢到,就直接返回了,不需要訪問數據庫。
具體的調用層數實在太多,用到了裝飾者模式,最終是在 PerpetualCache 中獲取緩存的:
打印日誌是在 LoggingCache 中:
爲什麼 MyBatis 默認不開啓二級緩存?
答案就是,不推薦使用二級緩存!
二級緩存雖然能帶來一定的好處,但是有很大的隱藏危害!
它的緩存是以 namespace(mapper) 爲單位的,不同 namespace 下的操作互不影響。且 insert/update/delete 操作會清空所在 namespace 下的全部緩存。
那麼問題就出來了,假設現在有 ItemMapper 以及 XxxMapper,在 XxxMapper 中做了表關聯查詢,且做了二級緩存。此時在 ItemMapper 中將 item 信息給刪了,由於不同 namespace 下的操作互不影響,XxxMapper 的二級緩存不會變,那之後再次通過 XxxMapper 查詢的數據就不對了,非常危險。
來看一個例子:
@Mapper
@Repository
@CacheNamespace
public interface XxxMapper {
@Select("select i.id itemId,i.name itemName,p.amount,p.unit_price unitPrice " +
"from item i JOIN payment p on i.id = p.item_id where i.id = #{id}")
List<PaymentVO> getPaymentVO(Long id);
}
@Autowired
private XxxMapper xxxMapper;
@Test
void test() {
System.out.println("==================== 查詢PaymentVO ====================");
List<PaymentVO> voList = xxxMapper.getPaymentVO(1L);
System.out.println(JSON.toJSONString(voList.get(0)));
System.out.println("==================== 更新item表的name ==================== ");
Item item = itemMapper.selectById(1);
item.setName("java併發編程");
itemMapper.updateById(item);
System.out.println("==================== 重新查詢PaymentVO ==================== ");
List<PaymentVO> voList2 = xxxMapper.getPaymentVO(1L);
System.out.println(JSON.toJSONString(voList2.get(0)));
}
上面的代碼,test() 方法中前後兩次調用了 xxxMapper.getPaymentVO 方法,因爲沒有加 @Transactional 註解,所以前後兩次查詢,是兩個不同的會話,第一次查詢完後,SqlSession 會自動 commit,所以二級緩存能夠生效;
然後在中間進行了 Item 表的更新操作,修改了下名稱;
由於 itemMapper 與 xxxMapper 不是同一個命名空間,所以 itemMapper 執行的更新操作不會影響到 xxxMapper 的二級緩存;
再次調用 xxxMapper.getPaymentVO,發現取出的值是走緩存的,itemName 還是老的。但實際上 itemName 在上面已經被改了!
執行日誌如下:
所以說,二級緩存的隱藏危害是比較大的,當有表關聯時,一個不注意就會出問題,不建議使用。
版權聲明:本文爲CSDN博主「xujingyiss」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。原文鏈接:https://blog.csdn.net/xujingyiss/article/details/123481116
更多文章推薦:
2.2,000+ 道 Java面試題及答案整理(2024最新版)
3.免費獲取 IDEA 激活碼的 7 種方式(2024最新版)
覺得不錯,別忘了隨手點贊+轉發哦!