一、案例場景

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

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

當時，我就在想，是否可以進一步優(yōu)化下，使得代碼看起來更為優(yōu)雅些，然后，就發(fā)現(xiàn)了Google Guava里的有一個類ImmutableMap，通過這個類可以實現(xiàn)類似建造者模式的鏈式編程，優(yōu)化后的效果，如下：

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

二、ImmutableMap源碼分析

那么，這個ImmutableMap究竟是如何實現(xiàn)這樣的功能呢？

在Google Guava官方教程中，Immutable前綴的集合被定義為不可變集合，包括ImmutableSet、 ImmutableMap等，何為不可變集合？就是指，在集合創(chuàng)建后，集合里所有的狀態(tài)在生命周期內(nèi)都不可再修改了，只能讀。

那么，什么是可再修改的呢，像Jdk中的map、list等，創(chuàng)建后，還可以再通過put()或者add()反復(fù)新增或者修改，這種就是可再修改的集合。既然是不可再修改集合，是不是就一定不能再修改了呢？也不是，其實，通過反射還是可以被修改的，但這已經(jīng)不是不可變集合之所以存在的初衷了。

總結(jié)一句話是，不可變集合是線程安全的且可當成常量使用的。

接下來，就進入到ImmutableMap內(nèi)部，可以看到，其實現(xiàn)了Map接口，跟HashMap有點類似地方在于，Map接口都算是他們的基類，都可以實現(xiàn)父類引用指向子類對象，即向上轉(zhuǎn)型。

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

這是一個抽象類，若要實現(xiàn)這樣調(diào)用 ImmutableMap.<String, String>builder()，表面上就可以猜測到<String, String>builder()一定是被static定義的靜態(tài)方法，進到源碼里，發(fā)現(xiàn)確實如此——

/**
 * 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>();
}

這個方法的定義對于一些初級程序員而言，可能會覺得很奇怪，其實這個方法格式的本質(zhì)是這樣的 ——

public <T> T method(T t)

這是一種泛型的約定規(guī)范，第一個定義一種泛型，表示當前方法有一個范型變量類型，用T表示；第二個T是表示method的返回類型為T。

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

前面定義 ImmutableMap.<String, String>builder()，在這個builder()方法里，就會返回一個new Builder<String, String>()的對象，這個對象通過構(gòu)造器，初始化了一個大小為ImmutableCollection.Builder.DEFAULT_INITIAL_CAPACITY的數(shù)組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>[] 是什么類型的數(shù)組呢？

這個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兩個泛型變量，可見，當外部調(diào)用builder().put(key，value)來存儲key-value數(shù)據(jù)時，其實是將key-value數(shù)據(jù)存儲到ImmutableEntry對象的key與value里。

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

提到ImmutableEntry<K, V>數(shù)組來存儲key-value數(shù)據(jù)，就不得不提一下HashMap。

在JDK1.8當中，HashMap是由數(shù)組+鏈表+紅黑樹組成，它內(nèi)部的數(shù)組是由Node<K,V>[]定義，而這個 Node<K,V> 實現(xiàn)的是Map.Entry<K,V>——

ImmutableMapEntry<K, V>頂部同樣是實現(xiàn)了Entry<K,V>——

可見，ImmutableMap與HashMap一樣，其存儲key-value的對象所屬的類，都直接或者間接地實現(xiàn)了Entry<K,V>接口。

分析到這里，再看回Builder<K, V>類源碼，就很容易明白 ，這個ImmutableMapEntry<K, V>[] entries與HashMap的數(shù)組類似，都是用來存儲key-value的數(shù)據(jù)。

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

前面分析到的Builder類，其實是屬于抽象類 ImmutableMap<K, V>中的內(nèi)部靜態(tài)類，這就意味著，執(zhí)行ImmutableMap.<String, String>builder().put("Monday","今天上英語課")的本質(zhì)，其實是相當于執(zhí)行了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;
}

一、先看第一行代碼調(diào)用的方法，其作用是判斷當新增一個key-value對象存到數(shù)組時，是否會有溢出的可能，若出現(xiàn)溢出的情況，就先對數(shù)組進行擴容。

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)就是創(chuàng)建一個新的ImmutableMapEntry對象，通過構(gòu)造器初始化賦值給對象的key與value——

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

三、第三行代碼 entries[size++] = entry是將新增的ImmutableMapEntry對象存儲到數(shù)組空閑的位置上，這樣通過put(key，value)緩存進來的key-value值，就通過對象的形式存入到了數(shù)組當中。

四、最后一行，是返回一個this，ImmutableMap能實現(xiàn)鏈式編程的原因，就是在這個this上。

當理解了這個this，就會理解ImmutableMap設(shè)計的精妙之處。

當我們使用鏈式編程ImmutableMap.<String, String>builder().put("key1","value1").put("key2","value2") .put("key2","value3")來賦值時，其內(nèi)部就是反復(fù)調(diào)用了內(nèi)部靜態(tài)類Builder當中的put()方法，那么問題來了，為什么能反復(fù)調(diào)用呢？

答案就是這個返回的this，其返回的還是Builder對象本身啊，Builderd對象當然可以繼續(xù)調(diào)用其put方法了。在這個反復(fù)調(diào)用的過程中， 只有entries[size++] 是一直在新增變化的。

這其實是建造者設(shè)計模式的一種體現(xiàn)，只不過平常遇到的建造者設(shè)計模式，大多都是將對象的各個屬性靈活進行拼裝，組成一個定制化的對象，而這里，則是靈活去定制化一個數(shù)組存儲情況。

最后就是，就是執(zhí)行.build()方法了——

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

這個build()源碼里寫的很復(fù)雜，這里直接簡單優(yōu)化了下，大概意思，就是將entries數(shù)組包裝成一個實現(xiàn)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);
  }
}

當數(shù)組長度超過1時，其可以返回SingletonImmutableBiMap或者RegularImmutableMap，兩者都是間接實現(xiàn)了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;
  ......
}

發(fā)現(xiàn)，都有一個共同特點，類與類中的屬性，都是以final修飾符來定義的，這就意味著，一旦調(diào)用build()方法創(chuàng)建初始化后，就不可以再改變了。

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

最后，還有一個問題是，當通過ImmutableMap創(chuàng)建完成一個Map對象后，再試圖通過put來插入數(shù)據(jù)時，會發(fā)生什么情況呢？

這時，再通過put方法調(diào)用時，例如，以上邊定義的dayMap為例，在某個方法里，再試圖通過dayMap..put("Monday","今天上英語課") 來修改或者新增map數(shù)據(jù)時，這里調(diào)用的put就已經(jīng)不是內(nèi)部類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，即無法再被修改，若仍調(diào)用put執(zhí)行，只會喜提一個異常

UnsupportedOperationException

總結(jié)

本篇文章就到這里了，希望能給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！

最新評論