說起 mybatis，作為 java 程序員應該是無人不知，它是常用的數據庫訪問框架。與 spring 和 struts 組成了 java web 開發的三劍客--- ssm。當然隨著 spring boot 的發展，現在越來越多的企業采用的是 springboot + mybatis 的模式開發，我們公司也不例外。而 mybatis 對于我也僅僅停留在會用而已，沒想過怎么去了解它，更不知道它的緩存機制了，直到那個生死難忘的 bug。故事的背景比較長，但并不是啰嗦，只是讓讀者知道這個 bug 觸發的場景，加深記憶。在遇到類似問題時，可以迅速定位。
先說下故事的前提，為了防止用戶在動態中輸入特殊字符，用戶的動態都是編碼后發到后臺，而后臺在存入到 db 表之前會解碼以方便在 db 中查看以及上報到搜索引擎。在查詢用戶動態的時候先從 db 表中讀取并在后臺做一次編碼再傳到前端，前端再解碼就可以正常展示了。流程如下圖：
有一天后端預發環境發布完畢后，用戶的動態頁面有的動態顯示正常，而有的卻是被編碼過的。看到現象后的第一個反應就是有問題的動態被編碼了兩次，但是編碼操作只會在 service 層的 findbyid 中有。理論不會在上層犯這種低級錯誤。話不多說便開始排查新增加的代碼，發現只要進入了新增加代碼中的某個 if 分支則被編碼了兩次。分支中除了再次調用 findbyid（必要性不討論），也無其他特殊代碼了。百思不得其解后請教了旁邊的老司機，老司機說可能是 mybatis 緩存。于是看了下我代碼，將編碼的操作從 findbyid 中移出來后再次發布到預發，正常了，心想老司機不愧是老司機。本次 bug 觸發的有兩個條件需要注意：
- 整個操作過程都在一個函數中，而函數上面加了 @transactional 的注解（對 mybatis 來說是在同一個 session 中）
- 一般只會調用 findbyidy 一次，如果進入分支則會調用兩次 （第一次調用后做了編碼后被緩存，第二次從緩存讀后繼續被編碼）
便開始谷歌 mybatis 的緩存機制，搜到了一篇非常不錯的文章《聊聊mybatis緩存機制》，推薦大家看一下。但是這篇文章講到了源碼，涉及的比較深。而且并沒講 springboot 下 mybatis 下的緩存知識點，遂作此篇，以作補充。
緩存的配置
springboot + mybatis 環境搭建很簡單而且網上一堆教程，這里不班門弄斧了，記得在項目中將 mytatis 的源碼下載下來即可。mybaits 一共有兩級緩存：一級緩存的配置 key 是 localcachescope，而二級緩存的配置 key 是 cacheenabled，從名字上可以得出以下信息：
- 一級緩存是本地或者說局部緩存，它不能被關閉，只能配置緩存范圍。session 或者 statement。
- 二級緩存才是 mybatis 的正統，功能會更強大些。
先來看下在 springboot中 如何配置 mybatis 緩存的相關信息。默認情況下 springboot 下的 mybatis 一級緩存為 session 級別，二級緩存也是打開的，可以在 mybatis 源碼中的 org.apache.ibatis.session.configuration.class 文件中看到（idea中打開），如下圖：
也可以通過以下測試程序查看緩存開啟情況：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
@runwith(springrunner.class)@springboottestpublic class learnapplicationtests { private sqlsessionfactory factory; @before public void setup() throws exception { inputstream inputstream = resources.getresourceasstream("mybatis/mybatis-config.xml"); factory = new sqlsessionfactorybuilder().build(inputstream); } @test public void showdefaultcacheconfiguration() { system.out.println("一級緩存范圍: " + factory.getconfiguration().getlocalcachescope()); system.out.println("二級緩存是否被啟用: " + factory.getconfiguration().iscacheenabled()); }} |
如果要設置一級緩存的緩存級別和開關二級緩存，在 mybatis-config.xml （當然也可以在 application.xml/yml 中配置）加入如下配置即可：
|
1
2
3
4
|
<settings> <setting name="cacheenabled" value="true/false"/> <setting name="localcachescope" value="session/statement"/></settings> |
但需要注意的是二級緩存 cacheenabled 只是個總開關，如果要讓二級緩存真正生效還需要在 mapper xml 文件中加入 。一級緩存只在同一 session 或者 statement 之間共享，二級緩存可以跨 session，開啟后它們默認具有如下特性：
- 映射文件中所有的 select 語句將被緩存
- 映射文件中所有的 insert/update/delete 語句將刷新緩存
一二級緩存同時開啟的情況下，數據的查詢順序是 二級緩存 -> 一級緩存 -> 數據庫。一級緩存比較簡單，而二級緩存可以設置更多的屬性，只需要在 mapper 的 xml 文件中的 中配置即可，具體如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<cache type = "org.mybatis.caches.ehcache.loggingehcache" //指定使用的緩存類，mybatis默認使用hashmap進行緩存,可以指定第三方緩存 eviction = "lru" //默認是 lru 淘汰緩存的算法，有如下幾種： //1.lru – 最近最少使用的:移除最長時間不被使用的對象。 //2.fifo – 先進先出:按對象進入緩存的順序來移除它們。 //3.soft – 軟引用:移除基于垃圾回收器狀態和軟引用規則的對象。 //4.weak – 弱引用:更積極地移除基于垃圾收集器狀態和弱引用規則的對象 flushinterval = "1000" //清空緩存的時間間隔，單位毫秒，可以被設置為任意的正整數。 默認情況是不設置，也就是沒有刷新間隔，緩存僅僅調用語句時刷新。 size = "100" //緩存對象的個數，任意正整數，默認值是1024。 readonly = "true" //緩存是否只讀，提高讀取效率 blocking = "true" //是否使用阻塞緩存，默認為false，當指定為true時將采用blockingcache進行封裝，blocking， //阻塞的意思，使用blockingcache會在查詢緩存時鎖住對應的key，如果緩存命中了則會釋放對應的鎖， //否則會在查詢數據庫以后再釋放鎖這樣可以阻止并發情況下多個線程同時查詢數據，詳情可參考blockingcache的源碼。 /> |
觸發緩存
配置一級緩存為 session 級別
controller 中調用兩次 getone，代碼如下：
|
1
2
3
4
5
6
7
8
|
@requestmapping("/getuser")public userentity getuser(long id) { //第一次調用 userentity user1=usermapper.getone(id); //第二次調用 userentity user2=usermapper.getone(id); return user1;} |
調用： http://localhost:8080/getuser?id=1，打印結果如下：
從圖中的 1/2/3/4 可以看出每次 mapper 層的一次接口調用如 getone 就會創建一個 session，并且在執行完畢后關閉 session。所以兩次調用并不在一個 session 中，一級緩存并沒有發生作用。開啟事務，controller 層代碼如下：
|
1
2
3
4
5
6
7
8
9
|
@requestmapping("/getuser")@transactional(rollbackfor = throwable.class)public userentity getuser(long id) { //第一次調用 userentity user1=usermapper.getone(id); //第二次調用 userentity user2=usermapper.getone(id); return user1;} |
打印結果如下：
由于在同一個事務中，雖然調用了 select 操作兩次但是只執行了一次 sql ，緩存發揮了作用。這就跟一開始我遇到的那個 bug 場景一樣：同一 session 且 select 調用 > 1 次。如果在兩次調用中間插入 update 操作，緩存會立即失效。只要 session 中有 insert、update 和 delete 語句，該 session 中的緩存會立即被刷新。但是注意這只是在同一 session 之間。不同 session 之間如 session1 和 session2，session1 里的 insert/update/delete 并不會影響 session 2 下的緩存，這在高并發或者分布式的情況下會產生臟數據。所以建議將一級緩存級別調成 statement。
配置一級緩存為 statement 級別
再次將（1）中的無事務和有事務的代碼分別執行一遍，打印結果始終如下：
配置成 satement 后，一級緩存相當于被關閉了。statement 級別暫時不好模擬，但是我猜測 statement 級別即在同一執行 sql 的接口中（如上面的 getone 中）緩存，出了 getone 緩存即失效。
配置二級緩存，同時為了避免一級緩存的干擾，將一級緩存設置為 statement
controller 中去掉 @transactional 注解代碼如下：
|
1
2
3
4
5
6
|
@requestmapping("/getuser")public userentity getuser(long id) { userentity user1=usermapper.getone(id); userentity user2=usermapper.getone(id); return user1;} |
當然二級緩存開關保證打開，在 mapper xml 文件中加入 ，整個文件代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<?xml version="1.0" encoding="utf-8" ?><!doctype mapper public "-//mybatis.org//dtd mapper 3.0//en" "http://mybatis.org/dtd/mybatis-3-mapper.dtd" ><mapper namespace="com.binggle.learn.dao.mapper.usermapper" ><resultmap id="baseresultmap" type="com.binggle.learn.dao.entity.userentity" > <id column="id" property="id" jdbctype="bigint" /> <result column="name" property="name" jdbctype="varchar" /> <result column="sex" property="sex"/></resultmap><sql id="base_column_list" > id, name, sex</sql><select id="getone" parametertype="java.lang.long" resultmap="baseresultmap" > select <include refid="base_column_list" /> from users where id = #{id};</select><cache /></mapper> |
執行 http://localhost:8080/getuser?id=1，打印結果如下：
從圖中紅框可以看出第二次查詢命中緩存，0.5 是命中率。再次執行 http://localhost:8080/getuser?id=1
打印結果如下：
這次一次 sql 也沒執行了，緩存命中率上升到 0.75了，所以說二級緩存全局緩存。但它的緩存范圍也是有限的，一級緩存在同一個 session 中。二級緩存雖然可以跨 session 但也只能在同一 namespace 中，所謂 namespace 即 mapper xml 文件。具體實驗請看《聊聊 mybatis 的緩存機制》中的關于二級緩存的實驗 4 和 5。再看下二級緩存配置對二級緩存的影響，為了明顯的看出效果，只改如下配置：
|
1
2
3
4
|
<cache size="1" //一次只能緩存一個對象 flushinterval="5000" //刷新時間為 5s/> |
controller 代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
@requestmapping("/getuser")public userentity getuser(long id, long id2) { //第一個對象 1 system.out.println("================緩存對象 1================="); userentity user1 = usermapper.getone(id); //另一個對象 2 system.out.println("========緩存對象 2，剔除緩存中的對象 1======="); userentity user2=usermapper.getone(id2); user2 = usermapper.getone(id2); //再次讀取第一個對象 system.out.println("==========緩存被剔除，執行查詢 sql==========="); user1 = usermapper.getone(id); //暫停 5s try { sleep(5000); }catch (exception e){ e.printstacktrace(); } system.out.println("============5s 后再次查詢對象 2============="); user2 = usermapper.getone(id2); return user1;} |
執行 http://localhost:8080/getuser?id=1&id2=2 最后打印的結果如下：
太長了，拼接下：
可以看出二級緩存只能緩存一個對象且 5s 后就失效了，配置生效。緩存配置中還有一個重要的配置 type，該配置可以配置第三方的 cache，特別在高并發和分布式情況下。當然，使用更專業的分布式緩存才是王道，例如 redis 等。
總結
本來想總結點什么的，但是覺得推薦文章中總結的非常好，直接引用了：
- mybatis一級緩存的生命周期和sqlsession一致。
- mybatis一級緩存內部設計簡單，只是一個沒有容量限定的hashmap，在緩存的功能性上有所欠缺。
- mybatis的一級緩存最大范圍是sqlsession內部，有多個sqlsession或者分布式的環境下，數據庫寫操作會引起臟數據，建議設定緩存級別為statement。
- mybatis的二級緩存相對于一級緩存來說，實現了sqlsession之間緩存數據的共享，同時粒度更加的細，能夠到namespace級別，通過cache接口實現類不同的組合，對cache的可控性也更強。
- mybatis在多表查詢時，極大可能會出現臟數據，有設計上的缺陷，安全使用二級緩存的條件比較苛刻。
- 在分布式環境下，由于默認的mybatis cache實現都是基于本地的，分布式環境下必然會出現讀取到臟數據，需要使用集中式緩存將mybatis的cache接口實現，有一定的開發成本，直接使用redis、memcached等分布式緩存可能成本更低，安全性也更高。
- 個人建議mybatis緩存特性在生產環境中進行關閉，單純作為一個orm框架使用可能更為合適。
參考
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://juejin.im/post/5cacaf2df265da03a97acd25
