[[402089]]

本文轉載自微信公眾號「Java極客技術」，作者鴨血粉絲。轉載本文請聯系Java極客技術公眾號。

前段時間阿粉的一個朋友和阿粉吃飯，在吃飯的時候和阿粉瘋狂的吐槽面試官，說面試官問的問題都是些什么問題呀，我一個干了三四年的開發，也不說問點靠譜的，阿粉很好奇，問題問完基礎的，一般不都是根據你自己的簡歷進行提問么?而接下來他說的出來的問題，阿粉表示，阿粉需要繼續學習了。

Mybatis是什么?

說到這個，讀者大人們肯定心想，阿粉是在開玩笑么?你一個 Java 程序員，你不知道Mybatis是啥么?不就是個持久層的框架么，這東西有啥好說的呢?但是阿粉還是要給大家說。

Mybatis是一個半自動 ORM(對象關系映射)框架，它內部封裝了JDBC，加載驅動、創建連接、創建 statement 等繁雜的過程，我們開發的時候只需要關注如何編寫 SQL 語句，而不用關心其他的。

為什么說 Mybatis 是一個半自動 ORM 的框架呢?

ORM，是Object和Relation之間的映射，而Mybatis 在查詢關聯對象或關聯集合對象時，需要手動編寫 sql 來完成，所以，稱之為半自動 ORM 框架，而Hibernate 屬于全自動 ORM 映射工具，使用 Hibernate 查詢關聯對象或者關聯集合對象時，可以根據對象關系模型直接獲取，所以它是全自動的。

這也是為什么有些面試官在面試初級程序員的時候，很喜歡說，你覺得 Mybatis , 和 Hibernate 都有什么優缺點，為啥你們選擇使用的 Mybatis 而不選擇使用 Hibernate 呢?

我們都說了 Mybatis是什么了，接下來肯定需要說說面試官都問了什么問題，能讓阿粉的朋友變得非常猶豫。

Mybatis的一級、二級緩存是什么你了解么?

Mybatis 的一級緩存

我們先說 Mybatis 的一級緩存，因為這是如果不手動配置，他是自己默認開啟的一級緩存，一級緩存只是相對于同一個 SqlSession 而言,參數和SQL完全一樣的情況下，我們使用同一個SqlSession對象調用一個Mapper方法，往往只執行一次SQL，因為使用SelSession第一次查詢后，MyBatis會將其放在緩存中，以后再查詢的時候，如果沒有聲明需要刷新，并且緩存沒有超時的情況下，SqlSession都會取出當前緩存的數據，而不會再次發送SQL到數據庫。

當我們面試的時候，說完這個，一般情況下，面試官一定會追問下去，畢竟技術就是要問到你的知識盲區才會停止。

那我們就來畫個圖表示一下一級緩存：

那面試官肯定會說，直接從數據庫查不就行了，為啥要一級緩存呢?

當我們使用MyBatis開啟一次和數據庫的會話時, MyBatis 會創建出一個 SqlSession 對象表示一次與數據庫之間的信息傳遞,在我們執行 SQL 語句的過程中,們可能會反復執行完全相同的查詢語句,如果不采取一些措施,我們每一次查詢都會查詢一次數據庫,而如果在極短的時間內做了很多次相同的查詢操作,那么這些查詢返回的結果很可能相同。

也就是說，如果我們在短時間內，頻繁的去執行一條 SQL ,查詢返回的結果本來應該是改變了，但是我們查詢出來的時候，會出現結果一致的情況,正是為了解決這種問題，也為了減輕數據庫的開銷，所以 Mybatis 默認開啟了一級緩存。

Mybatis 的二級緩存

Mybatis 的二級緩存一般如果你不對他進行設置，他是不會開啟的，而二級緩存是什么呢?Mybatis 中的二級緩存實際上就是 mapper 級別的緩存,而這時候肯定會有人說，那么不同之間的 Mapper 是同一個緩存么?

答案是否定的，他不是一個，Mapper 級別的緩存實際上就是相同的 Mapper 使用的是一個二級緩存，但是在二級緩存中，又有多個不同的 SqlSession ,而不同的 Mapper 之間的二級緩存也就是互相不會影響的。

就類似下面的圖：

這二級緩存是不是就看起來有點意思了?

那怎么能夠開啟二級緩存呢?

1.MyBatis 配置文件

<settings> 
 <setting name = "cacheEnabled" value = "true" /> 
</settings> 

2.MyBatis 要求返回的 POJO 必須是可序列化的

3.Mapper 的 xml 配置文件中加入 標簽

既然我們想要了解這個二級緩存，那么必然，我們還得知道它里面的配置都有哪些含義。

我們先從標簽看起，然后從源碼里面看都有哪些配置信息提供給我們使用：

blocking : 直譯就是調度，而在 Mybatis 中,如果緩存中找不到對應的 key ，是否會一直 blocking ,直到有對應的數據進入緩存。

eviction : 緩存回收策略

而緩存回收策略，在源碼中是有直接體現的，那么他們分別都對應了什么形式呢?

typeAliasRegistry.registerAlias("PERPETUAL", PerpetualCache.class); 
typeAliasRegistry.registerAlias("FIFO", FifoCache.class); 
typeAliasRegistry.registerAlias("LRU", LruCache.class); 
typeAliasRegistry.registerAlias("SOFT", SoftCache.class); 
typeAliasRegistry.registerAlias("WEAK", WeakCache.class); 

• PERPETUAL : 選擇 PERPETUAL 來命名緩存，暗示這是一個最底層的緩存，數據一旦存儲進來，永不清除.好像這種緩存不怎么受待見。
• FIFO : 先進先出：按對象進入緩存的順序來移除它們
• LRU : 最近最少使用的：移除最長時間不被使用的對象。
• SOFT : 軟引用：移除基于垃圾回收器狀態和軟引用規則的對象。
• WEAK : 弱引用：更積極地移除基于垃圾收集器狀態和弱引用規則的對象。

大家雖然看著 PERPETUAL 排在了第一位，但是它可不是默認的，在 Mybatis 的緩存策略里面，默認的是 LRU 。

PERPETUAL :

源代碼如下：

public class PerpetualCache implements Cache { 
  private final String id; 
  private Map<Object, Object> cache = new HashMap<>(); 
  public PerpetualCache(String id) { 
    this.id = id; 
  } 

恩?看著是不是有點眼熟，它怎么就只是包裝了 HashMap ? 你還別奇怪，他還真的就是使用的 HashMap ，不得不說，雖然人家是使用的 HashMap ，但是那可是比咱們寫的高端多了。

既然使用 HashMap ,那么必然就會有Key,那么他們的Key是怎么設計的?

CacheKey:

public class CacheKey implements Cloneable, Serializable { 
  private static final long serialVersionUID = 1146682552656046210L; 
  public static final CacheKey NULL_CACHE_KEY = new NullCacheKey(); 
  private static final int DEFAULT_MULTIPLYER = 37; 
  private static final int DEFAULT_HASHCODE = 17; 
  private final int multiplier; 
  private int hashcode; //用于表示CacheKey的哈希碼 
  private long checksum; //總和校驗，當出現復合key的時候，分布計算每個key的哈希碼，然后求總和 
  private int count;//當出現復合key的時候，計算key的總個數 
  // 8/21/2017 - Sonarlint flags this as needing to be marked transient.  While true if content is not serializable, this is not always true and thus should not be marked transient. 
  private List<Object> updateList;//當出現復合key的時候，保存每個key 
   

確實牛逼，至于內部如何初始化，如何進行操作，大家有興趣的可以去閱讀一下源碼，導入個源碼包，打開自己看一下。

FIFO: 先進先出緩沖淘汰策略

public class FifoCache implements Cache { 
 
  private final Cache delegate; //被裝飾的Cache對象 
  private final Deque<Object> keyList;//用于記錄key 進入緩存的先后順序 
  private int size;//記錄了緩存頁的上限，超過該值需要清理緩存（FIFO） 
 
  public FifoCache(Cache delegate) { 
    this.delegate = delegate; 
    this.keyList = new LinkedList<>(); 
    this.size = 1024; 
  } 

在 FIFO 淘汰策略中使用了 Java 中的 Deque,而 Deque 一種常用的數據結構，可以將隊列看做是一種特殊的線性表，該結構遵循的先進先出原則。Java中，LinkedList實現了Queue接口,因為LinkedList進行插入、刪除操作效率較高。

當你看完這個源碼的時候，是不是就感覺源碼其實也沒有那么難看懂，里面都是我們已經掌握好的知識，只不過中間做了一些操作，進行了一些封裝。

LRU : 最近最少使用的緩存策略

而 LUR 算法，阿粉之前都說過，如果對這個算法感興趣的話，文章地址給大家送上，經典的 LRU 算法，你真的了解嗎?

而我們需要看的源碼則是在 Mybatis 中的源碼，

public class LruCache implements Cache { 
 
  private final Cache delegate; 
  private Map<Object, Object> keyMap; 
  private Object eldestKey;//記錄最少被使用的緩存項key 
 
  public LruCache(Cache delegate) { 
    this.delegate = delegate; 
    setSize(1024);//重新設置緩存的大小，會重置KeyMap 字段 如果到達上限 則更新eldestKey 
  } 
    public void putObject(Object key, Object value) { 
      delegate.putObject(key, value); 
      // 刪除最近未使用的key 
      cycleKeyList(key); 
    } 

SOFT: 基于垃圾回收器狀態和軟引用規則的對象

在看到基于垃圾回收器的時候，阿粉就已經開始興奮了，竟然有GC的事情，那還不趕緊看看，這如此高大上(裝杯)的事情，來瞅瞅吧!

public class SoftCache implements Cache { 
  //在SoftCache 中，最近使用的一部分緩存項不會被GC回收，這就是通過將其value添加到 
  private final Deque<Object> hardLinksToAvoidGarbageCollection; 
  //引用隊列，用于記錄GC回收的緩存項所對應的SoftEntry對象 
  private final ReferenceQueue<Object> queueOfGarbageCollectedEntries; 
  //底層被修飾的Cache 對象 
  private final Cache delegate; 
  //連接的個數，默認是256 
  private int numberOfHardLinks; 
 
  public SoftCache(Cache delegate) { 
    this.delegate = delegate; 
    this.numberOfHardLinks = 256; 
    this.hardLinksToAvoidGarbageCollection = new LinkedList<>(); 
    this.queueOfGarbageCollectedEntries = new ReferenceQueue<>(); 
  } 
   
  public void putObject(Object key, Object value) { 
      // 清除被GC回收的緩存項 
      removeGarbageCollectedItems(); 
      // 向緩存中添加緩存項 
      delegate.putObject(key, new SoftEntry(key, value, queueOfGarbageCollectedEntries)); 
    } 
   public Object getObject(Object key) { 
       Object result = null; 
       // 查找對應的緩存項 
       @SuppressWarnings("unchecked") // assumed delegate cache is totally managed by this cache 
       SoftReference<Object> softReference = (SoftReference<Object>) delegate.getObject(key); 
       if (softReference != null) { 
         result = softReference.get(); 
         // 已經被GC 回收 
         if (result == null) { 
           // 從緩存中清除對應的緩存項 
           delegate.removeObject(key); 
         } else { 
           // See #586 (and #335) modifications need more than a read lock  
           synchronized (hardLinksToAvoidGarbageCollection) { 
             hardLinksToAvoidGarbageCollection.addFirst(result); 
             if (hardLinksToAvoidGarbageCollection.size() > numberOfHardLinks) { 
               hardLinksToAvoidGarbageCollection.removeLast(); 
             } 
           } 
         } 
       } 
       return result; 
     } 
    public void clear() { 
        synchronized (hardLinksToAvoidGarbageCollection) { 
          // 清理強引用集合 
          hardLinksToAvoidGarbageCollection.clear(); 
        } 
        // 清理被GC回收的緩存項 
        removeGarbageCollectedItems(); 
        delegate.clear(); 
      } 
    //其中指向key的引用是強引用，而指向value的引用是弱引用 
    private static class SoftEntry extends SoftReference<Object> { 
      private final Object key; 
   
      SoftEntry(Object key, Object value, ReferenceQueue<Object> garbageCollectionQueue) { 
        super(value, garbageCollectionQueue); 
        this.key = key; 
      } 
    } 

WEAK : 基于垃圾收集器狀態和弱引用規則的對象

public class WeakCache implements Cache { 
  private final Deque<Object> hardLinksToAvoidGarbageCollection; 
  private final ReferenceQueue<Object> queueOfGarbageCollectedEntries; 
  private final Cache delegate; 
  private int numberOfHardLinks; 
 
  public WeakCache(Cache delegate) { 
    this.delegate = delegate; 
    this.numberOfHardLinks = 256; 
    this.hardLinksToAvoidGarbageCollection = new LinkedList<>(); 
    this.queueOfGarbageCollectedEntries = new ReferenceQueue<>(); 
  } 

WeakCache在實現上與SoftCache幾乎相同，只是把引用對象由SoftReference軟引用換成了WeakReference弱引用。 

在這里阿粉也就不再多說了，關于 Mybatis 的二級緩存，你了解了么?下次遇到面試官問這個的時候，你應該知道怎么成功(裝杯)不被打了吧。