mybatis中提供有一級緩存 和 二級緩存，這里記錄一下一級緩存

一級緩存（mybatis中默認開啟）

SqlSession級別的緩存，操作數(shù)據(jù)庫時需要構造SQLSession對象， 在對象中有一個數(shù)據(jù)結構（HashMap）用于存儲緩存數(shù)據(jù)，不同的SQLSession對象之間的緩存數(shù)據(jù)是不共享的，即獨立的

根據(jù)第一點，簡單一點講就是一級緩存是屬于對象的（個人記法）

從別處搞來一個圖，便于我們理解：

下面用spring整合mybatis來測試一下mybatis的一級緩存：

1、下面是service層實現(xiàn)， 可以看到，我兩次查詢了同一個數(shù)據(jù)，理論上由于mybatis中默認開啟一級緩存， 那么第二次肯定時要從緩存中獲取，而不是創(chuàng)建SqlSession對象重新從數(shù)據(jù)庫獲取

@Autowired
private LsjmUserMapper lsjmUserMapper;
 
@Override
public LsjmUser getUser() {
 // 第一次查詢
 LsjmUser user = lsjmUserMapper.getUserByName("300");
 System.out.println(user.toString());
 
 // 第二次查詢
 LsjmUser user1 = lsjmUserMapper.getUserByName("300");
 System.out.println(user1.toString());
 return user;
}

前臺頁面觸發(fā)這個service后，控制臺打印：

從日志信息可以很明顯的看到，代碼中的兩次查詢構建了兩個SqlSession對象，也就是說第二次查詢并沒有從前一次的SqlSession緩存中獲取，而是自己新建一個SQLSession對象，重新查詢，，看似，mybatis的一級緩存失效了？

2、spring 中 結合 mybatis中，默認情況下，數(shù)據(jù)庫處于自動提交模式，每一條sql語句處于一個單獨的事務中，語句執(zhí)行完畢時，如果執(zhí)行成功則隱式提交事務。而mybatis的一級緩存在這種情況下是無效的，想要一級緩存起作用，則要開啟事務：

開啟事務： spring使用ThreadLocal獲取當前資源綁定同一個SQLSession

未開啟事務：每次查詢，spring關閉舊的SslSession，創(chuàng)建一個新的Sqlsession對象，一級緩存補氣作用

下面Service層中的代碼同樣對同一個數(shù)據(jù)查詢了兩次，這次開啟了事務管理

@Autowired
private LsjmUserMapper lsjmUserMapper;
 
@Override
@Transactional // 開啟事務控制，當前，spring配置文件中得先配置好
public LsjmUser getUser() {
 // 第一次查詢
 LsjmUser user = lsjmUserMapper.getUserByName("300");
 System.out.println(user.toString());
 
 // 第二次查詢
 LsjmUser user1 = lsjmUserMapper.getUserByName("300");
 System.out.println(user1.toString());
 return user;
}

前臺頁面觸發(fā)Service后：控制臺打印日志：

可以看出來第一次查詢時，構造了一個SqlSession對象，從數(shù)據(jù)庫查詢數(shù)據(jù)，然后將查詢的結果存儲到一級緩存SqlSession中，第二次查詢時，直接Fetched SqlSession，而不是再重新建一個，此時就是從緩存中直接取數(shù)據(jù)了

開啟事務后取如何取到同一個SqlSession，源碼解析可以參考這里：spring結合mybatis時一級緩存失效問題

有一點需要注意：

如果對某個SqlSession執(zhí)行了commit，則會清空這個SqlSession中的一級緩存，目的是為了防止臟讀，在上面的例子中，如果第一次查詢后，做了一次更新操作，然后sqlSession.commit()了，此時會清空整個SqlSession的一級緩存，那么第二次查詢時就得重新的從數(shù)據(jù)中查詢了。

以上這篇mybatis中的一級緩存深入剖析就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論