1. 程式人生 > 其它 >Java原始碼分析:Guava之不可變集合ImmutableMap的原始碼分析

Java原始碼分析:Guava之不可變集合ImmutableMap的原始碼分析

一、案例場景

遇到過這樣的場景,在定義一個static修飾的Map時,使用了大量的put()方法賦值,就類似這樣——

public static final  Map<String,String> dayMap= new HashMap<>();
static {
    dayMap.put("Monday","今天上英語課");
    dayMap.put("Tuesday","今天上語文課");
    dayMap.put("Wednesday","今天上數學課");
    dayMap.put("Thursday","今天上音樂課");
    dayMap.put("Sunday","今天上程式設計課");
    ......
}

當時,我就在想,是否可以進一步優化下,使得程式碼看起來更為優雅些,然後,就發現了Google Guava裡的有一個類ImmutableMap,通過這個類可以實現類似建造者模式的鏈式程式設計,優化後的效果,如下:

public static final  Map<String,String> dayMap = ImmutableMap.<String, String>builder()
    .put("Monday","今天上英語課")
    .put("Tuesday","今天上語文課")
    .put("Wednesday","今天上數學課")
    .put("Thursday","今天上音樂課")
    .put("Sunday","今天上程式設計課")
    .build();

二、ImmutableMap原始碼分析

那麼,這個ImmutableMap究竟是如何實現這樣的功能呢?

在Google Guava官方教程中,Immutable字首的集合被定義為不可變集合,包括ImmutableSet、 ImmutableMap等,何為不可變集合?就是指,在集合建立後,集合裡所有的狀態在生命週期內都不可再修改了,只能讀。

那麼,什麼是可再修改的呢,像Jdk中的map、list等,建立後,還可以再通過put()或者add()反覆新增或者修改,這種就是可再修改的集合。既然是不可再修改集合,是不是就一定不能再修改了呢?也不是,其實,通過反射還是可以被修改的,但這已經不是不可變集合之所以存在的初衷了。

總結一句話是,不可變集合是執行緒安全的且可當成常量使用的。

接下來,就進入到ImmutableMap內部,可以看到,其實現了Map介面,跟HashMap有點類似地方在於,Map介面都算是他們的基類,都可以實現父類引用指向子類物件,即向上轉型。

public abstract class ImmutableMap<K, V> implements Map<K, V>, Serializable {}

這是一個抽象類,若要實現這樣呼叫 ImmutableMap.<String, String>builder(),表面上就可以猜測到<String, String>builder()一定是被static定義的靜態方法,進到原始碼裡,發現確實如此——

/**
 * Returns a new builder. The generated builder is equivalent to the builder
 * created by the {@link Builder} constructor.
 */
public static <K, V> Builder<K, V> builder() {
  return new Builder<K, V>();
}

這個方法的定義對於一些初級程式設計師而言,可能會覺得很奇怪,其實這個方法格式的本質是這樣的 ——

public <T> T method(T t)

這是一種泛型的約定規範,第一個定義一種泛型,表示當前方法有一個範型變數型別,用T表示;第二個T是表示method的返回型別為T。

回過頭來看這個builder()方法,就很好理解了,<K, V>是定義一種泛型,表示當前方法的泛型變數,Builder<K, V>表示返回一個泛型變數為<K, V>的物件。

前面定義 ImmutableMap.<String, String>builder(),在這個builder()方法裡,就會返回一個new Builder<String, String>()的物件,這個物件通過構造器,初始化了一個大小為ImmutableCollection.Builder.DEFAULT_INITIAL_CAPACITY的陣列entries,而這個DEFAULT_INITIAL_CAPACITY的預設值是4。

public static class Builder<K, V> {
    Comparator<? super V> valueComparator;
    ImmutableMapEntry<K, V>[] entries;
    int size;
    boolean entriesUsed;
    
   public Builder() {
      this(ImmutableCollection.Builder.DEFAULT_INITIAL_CAPACITY);
    }

    Builder(int initialCapacity) {
      this.entries = new ImmutableMapEntry[initialCapacity];
      this.size = 0;
      this.entriesUsed = false;
    }
    ......
}

那麼問題來了,這個 ImmutableMapEntry<K, V>[] 是什麼型別的陣列呢?

這個ImmutableMapEntry<K, V>類 ,是繼承一個ImmutableEntry<K, V>類 ——

class ImmutableMapEntry<K, V> extends ImmutableEntry<K, V> {

  static <K, V> ImmutableMapEntry<K, V>[] createEntryArray(int size) {
    return new ImmutableMapEntry[size];
  }

  ImmutableMapEntry(K key, V value) {
    super(key, value);
    checkEntryNotNull(key, value);
  }
}

注意一點, checkEntryNotNull(key, value)做了一個校驗,這就意味著,存入的key和value值都不能為空。

static void checkEntryNotNull(Object key, Object value) {
  if (key == null) {
    throw new NullPointerException("null key in entry: null=" + value);
  } else if (value == null) {
    throw new NullPointerException("null value in entry: " + key + "=null");
  }
}

在父類ImmutableEntry<K, V>類裡,定義了key和value兩個泛型變數,可見,當外部呼叫builder().put(key,value)來儲存key-value資料時,其實是將key-value資料儲存到ImmutableEntry物件的key與value裡。

class ImmutableEntry<K, V> extends AbstractMapEntry<K, V> implements Serializable {
  final K key;
  final V value;
  ......
}

提到ImmutableEntry<K, V>陣列來儲存key-value資料,就不得不提一下HashMap。

在JDK1.8當中,HashMap是由陣列+連結串列+紅黑樹組成,它內部的陣列是由Node<K,V>[]定義,而這個 Node<K,V> 實現的是Map.Entry<K,V>——

ImmutableMapEntry<K, V>頂部同樣是實現了Entry<K,V>——

可見,ImmutableMap與HashMap一樣,其儲存key-value的物件所屬的類,都直接或者間接地實現了Entry<K,V>介面。

分析到這裡,再看回Builder<K, V>類原始碼,就很容易明白 ,這個ImmutableMapEntry<K, V>[] entries與HashMap的陣列類似,都是用來儲存key-value的資料。

接下來,就是分析put的邏輯原理了。

前面分析到的Builder類,其實是屬於抽象類 ImmutableMap<K, V>中的內部靜態類,這就意味著,執行ImmutableMap.<String, String>builder().put("Monday","今天上英語課")的本質,其實是相當於執行了ImmutableMap.new Builder<K, V>().put("Monday","今天上英語課")。

put方法的原始碼如下:

public Builder<K, V> put(K key, V value) {
  ensureCapacity(size + 1); 
  ImmutableMapEntry<K, V> entry = entryOf(key, value);
  // don't inline this: we want to fail atomically if key or value is null
  entries[size++] = entry;
  return this;
}

一、先看第一行程式碼呼叫的方法,其作用是判斷當新增一個key-value物件存到陣列時,是否會有溢位的可能,若出現溢位的情況,就先對陣列進行擴容。

private void ensureCapacity(int minCapacity) {
  if (minCapacity > entries.length) {
    entries =
        Arrays.copyOf(
            entries, ImmutableCollection.Builder.expandedCapacity(entries.length, minCapacity));
    entriesUsed = false;
  }
}

二、第二行ImmutableMapEntry<K, V> entry = entryOf(key, value)就是建立一個新的ImmutableMapEntry物件,通過構造器初始化賦值給物件的key與value——

static <K, V> ImmutableMapEntry<K, V> entryOf(K key, V value) {
    return new ImmutableMapEntry<K, V>(key, value);
  }

三、第三行程式碼 entries[size++] = entry是將新增的ImmutableMapEntry物件儲存到陣列空閒的位置上,這樣通過put(key,value)快取進來的key-value值,就通過物件的形式存入到了陣列當中。

四、最後一行,是返回一個this,ImmutableMap能實現鏈式程式設計的原因,就是在這個this上。

當理解了這個this,就會理解ImmutableMap設計的精妙之處。

當我們使用鏈式程式設計ImmutableMap.<String, String>builder().put("key1","value1").put("key2","value2") .put("key2","value3")來賦值時,其內部就是反覆呼叫了內部靜態類Builder當中的put()方法,那麼問題來了,為什麼能反覆呼叫呢?

答案就是這個返回的this,其返回的還是Builder物件本身啊,Builderd物件當然可以繼續呼叫其put方法了。在這個反覆呼叫的過程中, 只有entries[size++] 是一直在新增變化的。

這其實是建造者設計模式的一種體現,只不過平常遇到的建造者設計模式,大多都是將物件的各個屬性靈活進行拼裝,組成一個定製化的物件,而這裡,則是靈活去定製化一個數組儲存情況。

最後就是,就是執行.build()方法了——

ImmutableMap.<String, String>builder()
    .put("Monday","今天上英語課")
    ......
    .build();

這個build()原始碼裡寫的很複雜,這裡直接簡單優化了下,大概意思,就是將entries陣列包裝成一個實現Map介面的子物件進行返回。

public ImmutableMap<K, V> build() {
  switch (size) {
    case 0:
      return of();
    case 1:
      return  new SingletonImmutableBiMap<K, V>(k1, v1);
    default:
      return  new RegularImmutableMap<K, V>(entries, table, mask);
  }
}

當陣列長度超過1時,其可以返回SingletonImmutableBiMap或者RegularImmutableMap,兩者都是間接實現了Map介面,對比一下各自的類定義——

final class SingletonImmutableBiMap<K, V> extends ImmutableBiMap<K, V> {
  final transient K singleKey;
  final transient V singleValue;
  ......
}
final class RegularImmutableMap<K, V> extends ImmutableMap<K, V> {
  // entries in insertion order
  private final transient Entry<K, V>[] entries;
  // array of linked lists of entries
  private final transient ImmutableMapEntry<K, V>[] table;
  // 'and' with an int to get a table index
  private final transient int mask;
  ......
}

發現,都有一個共同特點,類與類中的屬性,都是以final修飾符來定義的,這就意味著,一旦呼叫build()方法建立初始化後,就不可以再改變了。

這就是ImmutableMap集合不可變的真正原因所在。

最後,還有一個問題是,當通過ImmutableMap建立完成一個Map物件後,再試圖通過put來插入資料時,會發生什麼情況呢?

這時,再通過put方法呼叫時,例如,以上邊定義的dayMap為例,在某個方法裡,再試圖通過dayMap..put("Monday","今天上英語課") 來修改或者新增map資料時,這裡呼叫的put就已經不是內部類Builder<K, V>()裡的put方法了,而是ImmutableMap本身的put方法,這個方法的原始碼如下——

/**
 * Guaranteed to throw an exception and leave the map unmodified.
 *
 * @throws UnsupportedOperationException always
 * @deprecated Unsupported operation.
 */
@CanIgnoreReturnValue
@Deprecated
@Override
public final V put(K k, V v) {
  throw new UnsupportedOperationException();
}

其註釋表示,map unmodified,即無法再被修改,若仍呼叫put執行,只會喜提一個異常 UnsupportedOperationException。