點關注，不迷路；持續更新Java相關技術及資訊！！！
你不點個贊嗎~~~
HashMap是基於哈希表實現的Map接口實現類。這個實現提供所有的map相關的操作，允許使用null的鍵和null的值。（HashMap與Hashtable大致是一樣的，只是HashMap是不同步的，且它允許你null的鍵和值。）；另外，HashMap內部元素排列是無序的。
假設哈希函數能將元素合理地分散在各個哈希桶中，那麼HashMap的put、get等基礎操作的效率會很高（時間複雜度是常數級別O(n)）。HashMap的迭代所有元素的時間與它的實例的容量（哈希桶的數量）及大小（鍵值對的數量）之和成正比。因此，如果你很在意HashMap的迭代性能，就不應該初始容量設置得很高，或者把負載因子設置得很低。
歡迎進羣交流
一個HashMap的實例有兩個參數會影響到它的性能：初始容量和負載因子。容量是指哈希表中桶的數量，初始容量就是哈希表創建時指定的初始大小。負載因子是一個度量，用來衡量當哈希表的容量滿到什麼程度時，哈希表就應該自動擴容。到哈希表中元素的數量超過負載因子和當前容量的乘積時，哈希表會重新計算哈希（rehashed）（即重建內部數據結構），哈希表桶的數量大約會變成原來的兩倍。
一般來說，默認把負載因子值設置成0.75，在時間成本和空間成本之間是比較好的權衡。該值再高一點能減少空間開銷，但會增加查找成本（表現在HashMap類的大多數操作中，包括get和put）。所以我們在設置初始化容量時，應該合理考慮預期裝載的元素數量以及負載因子，從而減少rehash的操作次數。如果初始容量大於最大條目數除以加載因子（initial capacity > max entries / load factor），則不會發生重新加載操作。
如果HashMap的實例需要存儲很多元素（鍵值對），創建HashMap時指定足夠大的容量可以令它的存儲效率比自動擴容高很多。
請注意如果很多的鍵使用的hashCode()方法結果都相同，那麼哈希表的性能會很慢。爲了改善影響，當鍵是Comparable時，HashMap會用這些鍵的排序來提升效率。
請注意，HashMap是不同步的。如果多條線程同時訪問一個HashMap，且至少有一條線程發生了結構性改動，那麼它必須在外部進行同步。（結構性改動是指任何增加或刪除鍵值對的操作，在源碼中具體體現是導致modCount屬性改動的操作，僅僅修改一個鍵對應的值則不屬於結構性改動）。外部同步通常通過同步一個封裝了這個map的對象完成。
如果沒有這樣的對象，那麼可以使用Collections.synchronizedMap把一個map轉換成同步的map，這個動作最好在創建的時候完成，避免在轉換前意外訪問到不同步的map。
Map m = Collections.synchronizedMap(new HashMap(...));
HashMap的迭代器所有集合相關的方法都是快速失敗的（fail-fast）：如果創建迭代器後，除了迭代器自身的remove方法之外，map發生了結構性改動，迭代器會拋出ConcurrentModificationException。因此，面對併發的修改，迭代嗎快速、乾淨利落地失敗，而不會冒任何風險。
請注意，迭代器快速失敗的特性在不同步的併發修改時，是不能作出硬性保證的。快速失敗的迭代器會盡最大努力拋出ConcurrentModificationException。因此，編寫依賴於此異常的程序以確保其正確性是錯誤的：迭代器的快速失敗行爲應該僅用於檢測錯誤。
構造函數
HashMap的構造函數一共有四種：
-
無參構造，初始容量默認16，負載因子默認0.75
-
指定初始容量，負載因子默認0.75
-
指定初始容量和負載因子
-
通過傳入的map構造
其中1、2、4都會調用第3種構造函數，第4種只是用已有的Map構造一個HashMap的便捷方法，所以這裏重點看3、4兩種構造函數的實現。
public class HashMap<K,V>
extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable {
//......
// 空表
static final Entry<?,?>[] EMPTY_TABLE = {};
// 哈希表
transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;
// 容器擴容閾值，當容器大小（size）達到此值時，容器就會擴容。
// size = 容量 * 負載因子
// 如果table == EMPTY_TABLE，那麼就會用這個值作爲初始容量，創建新的哈希表
int threshold;
// 負載因子
final float loadFactor;
// 構造函數3：指定初始容量和負載因子
public HashMap(int initialCapacity, float loadFactor) {
// 檢查參數
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " + loadFactor);
// 設置負載因子
this.loadFactor = loadFactor;
// 默認的閾值等於初始化容量
threshold = initialCapacity;
init();
}
// 構造函數4：用傳入的map構造一個新的HashMap
public HashMap(Map<? extends K, ? extends V> m) {
this(Math.max((int) ( m.size() / DEFAULT_LOAD_FACTOR) + 1,
DEFAULT_INITIAL_CAPACITY), DEFAULT_LOAD_FACTOR);
// 分配哈希表空間
inflateTable(threshold);
putAllForCreate(m);
}
//......
}
上面的源碼中，需要注意幾點：
- 擴容閾值默認等於初始容量，16。當哈希表爲空表時，HashMap會在內部以該閾值作爲初始容量建哈希表，哈希表實質是一個數組
- inflateTable方法就是建立哈希表，分配表內存空間的操作（inflate翻譯爲“膨脹”的意思，後面會詳述）。但是指定初始容量和負載因子的構造方法並沒有馬上調用inflateTable。查找源碼中全部調用inflateTable的地方有：
graph LR
HashMap構造函數-Map爲參數 --> inflateTable
put --> inflateTable
putAll --> inflateTable
clone --> inflateTable
readObject --> inflateTable
初步看上去，只有參數列表是Map的構造函數調用了inflateTable，但HashMap(Map map)構造函數內部的邏輯是先調用一下HashMap(int initialCapacity, float loadFactor)構造函數初始化完了容量和負載因子後，再調用inflateTable的。所以小結一點：HashMap在初始化階段不會馬上創建哈希表。
調用邏輯
爲了更好理解代碼的調用，下圖列出一些方法之間的調用關係：
內部數據結構
HashMap內部維護的數據結構是數組+鏈表，每個鍵值對都存儲在HashMap的靜態內部類Entry中，結構如下圖：
put的實現
public V put(K key, V value) {
if (table == EMPTY_TABLE) {
inflateTable(threshold);
}
if (key == null)
return putForNullKey(value);
int hash = hash(key);
int i = indexFor(hash, table.length);
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;
addEntry(hash, key, value, i);
return null;
}
void addEntry(int hash, K key, V value, int bucketIndex) {
// 如果容器大小大於等於閾值，且目標桶的entry不等於null
if ((size >= threshold) && (null != table[bucketIndex])) {
// 容器擴容: 哈希表原長度 * 2
resize(2 * table.length);
// 重新計算鍵的哈希值
hash = (null != key) ? hash(key) : 0;
// 重新計算哈希值對應存儲的哈希表的位置
bucketIndex = indexFor(hash, table.length);
}
createEntry(hash, key, value, bucketIndex);
}
- 在put方法內部，會先判斷哈希表是不是空表，如果是空表就建立哈希表（上面提到的內部數據結構中的數組），建好表後，就有空間可以存放鍵值對了。
- 要存放鍵值對，需要先根據key計算哈希碼（hash），哈希碼返回是一個int類型的數值，再根據哈希碼計算出在固定長度的數組中存放的位置（下標）
- 得到下標後，就要在哈希表中找到存儲的位置。HashMap會先加載指定下標中存放的Entry對象，如果Entry不爲空，就比較該Entry的hash和key（比較key的時候，用==和equals來比較）。如果跟put進來的hash、key匹配，就覆蓋該Entry上的value，然後直接返回舊的value；否則，就找該Entry指向的下一個Entry，直到最後一個Entry爲止。
- 如果HashMap加載指定下標中存放的Entry對象是null，又或者是找完整條Entry鏈表都沒有匹配的hash和key。那麼就調用addEntry新增一個Entry
- addEntry方法中會做一些前置處理。HashMap會判斷容器當前存放的鍵值對數量是否達到了設定的擴容閾值，如果達到了就擴容2倍。擴容後重新計算哈希碼，並根據新哈希碼和新數組長度重新計算存儲位置。做好潛質處理後，就調用createEntry新增一個Entry。
- 由於上面已經做了前置的處理，createEntry方法就不用擔心擴容的問題，放心存Entry即可。該方法會在給定的下標爲止存放put進來的key，value，當然這個key，value是包裝在Entry中的，讓後將Entry指向舊的Entry。
建哈希表的邏輯（inflateTable）
建哈希表是在inflateTable方法中實現的：
/**
* 將一個數換算成2的n次冪
* @param number
* @return
*/
private static int roundUpToPowerOf2(int number) {
// assert number >= 0 : "number must be non-negative";
return number >= MAXIMUM_CAPACITY
? MAXIMUM_CAPACITY
: (number > 1) ? Integer.highestOneBit((number - 1) << 1) : 1;
// 理解 Integer.highestOneBit((number - 1) << 1)
// 比如 number = 23，23 - 1 = 22，二進制是：10110
// 22 左移一位（右邊補1個0），結果是：101100
// Integer.highestOneBit() 函數的作用是取左邊最高一位，其餘位取0，
// 即：101100 -> 100000，換成十進制就是 32
}
/**
* inflate有“膨脹”、“充氣”的意思。
* 理解爲初始化哈希表，分配哈希表內存空間
*/
private void inflateTable(int toSize) {
// Find a power of 2 >= toSize
// 找出大於等於toSize的2的n次冪，作爲哈希表的容量
int capacity = roundUpToPowerOf2(toSize);
// 計算新的擴容閾值： 容量 * 負載因子
threshold = (int) Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1);
// 指定容量建哈希表
table = new Entry[capacity];
// 根據容量判斷是否需要初始化hashSeed
initHashSeedAsNeeded(capacity);
}
理解一下roundUpToPowerOf2方法：
roundUpToPowerOf2部分計算結果：
roundUpToPowerOf2(0) = 1
roundUpToPowerOf2(1) = 1
roundUpToPowerOf2(2) = 2
roundUpToPowerOf2(3) = 4
roundUpToPowerOf2(4) = 4
roundUpToPowerOf2(5) = 8
roundUpToPowerOf2(6) = 8
roundUpToPowerOf2(7) = 8
roundUpToPowerOf2(8) = 8
roundUpToPowerOf2(9) = 16
roundUpToPowerOf2(10) = 16
roundUpToPowerOf2(11) = 16
roundUpToPowerOf2(12) = 16
roundUpToPowerOf2(13) = 16
roundUpToPowerOf2(14) = 16
roundUpToPowerOf2(15) = 16
roundUpToPowerOf2(16) = 16
roundUpToPowerOf2(17) = 32
roundUpToPowerOf2(6)計算示例：
計算公式：Integer.highestOneBit((5 - 1) << 1)
計算5<<1：
00000101
<<1
-------------
00001010
1010的十進制是10，然後計算Integer.highestOneBit(10),
該函數的作用是取傳入數值的最高位然後其餘低位取0,
所以Integer.highestOneBit(10)應該等於二進制的1000，即8
值得注意的是，inflateTable中最後還調用了一個initHashSeedAsNeeded(capacity)方法，該方法是用來依據容量決定是否需要初始化hashSeed，hashSeed默認是0，如果初始化hashSeed，它的值將會是一個隨機值。
Alternative hashing與hashSeed
在源碼中有一個常量ALTERNATIVE_HASHING_THRESHOLD_DEFAULT，它的註釋提供了一些值得注意的信息：
/**
* The default threshold of map capacity above which alternative hashing is
* used for String keys. Alternative hashing reduces the incidence of
* collisions due to weak hash code calculation for String keys.
* <p/>
* This value may be overridden by defining the system property
* {@code jdk.map.althashing.threshold}. A property value of {@code 1}
* forces alternative hashing to be used at all times whereas
* {@code -1} value ensures that alternative hashing is never used.
*/
static final int ALTERNATIVE_HASHING_THRESHOLD_DEFAULT = Integer.MAX_VALUE;
大意是說，ALTERNATIVE_HASHING_THRESHOLD_DEFAULT是一個默認的閾值，當一個鍵值對的鍵是String類型時，且map的容量達到了這個閾值，就啓用備用哈希（alternative hashing）。備用哈希可以減少String類型的key計算哈希碼（更容易）發生哈希碰撞的發生率。該值可以通過定義系統屬性jdk.map.althashing.threshold來指定。如果該值是1，表示強制總是使用備用哈希；如果是-1則表示禁用。
HashMap有一個靜態內部類Holder,它的作用是在虛擬機啓動後根據jdk.map.althashing.threshold和ALTERNATIVE_HASHING_THRESHOLD_DEFAULT初始化ALTERNATIVE_HASHING_THRESHOLD，相關代碼如下：
/**
* Holder維護着一些只有在虛擬機啓動後才能初始化的值
*/
private static class Holder {
/**
* 觸發啓用備用哈希的哈希表容量閾值
*/
static final int ALTERNATIVE_HASHING_THRESHOLD;
static {
// 讀取JVM參數 -Djdk.map.althashing.threshold
String altThreshold = java.security.AccessController.doPrivileged(
new sun.security.action.GetPropertyAction(
"jdk.map.althashing.threshold"));
int threshold;
try {
// 如果該參數沒有值，採用默認值
threshold = (null != altThreshold)
? Integer.parseInt(altThreshold)
: ALTERNATIVE_HASHING_THRESHOLD_DEFAULT;
// 如果參數值爲-1，禁用備用哈希
// ALTERNATIVE_HASHING_THRESHOLD_DEFAULT也是等於Integer.MAX_VALUE
// 所以jdk默認是禁用備用哈希的
if (threshold == -1) {
threshold = Integer.MAX_VALUE;
}
// 參數爲其它負數，則視爲非法參數
if (threshold < 0) {
throw new IllegalArgumentException("value must be positive integer.");
}
} catch(IllegalArgumentException failed) {
throw new Error("Illegal value for 'jdk.map.althashing.threshold'", failed);
}
ALTERNATIVE_HASHING_THRESHOLD = threshold;
}
}
之前提到過，inflateTable中最後還調用了一個initHashSeedAsNeeded(capacity)方法，該方法是用來依據容量決定是否需要初始化hashSeed，hashSeed默認是0，如果初始化hashSeed。所以下面來看看這個方法：
/**
* A randomizing value associated with this instance that is applied to
* hash code of keys to make hash collisions harder to find. If 0 then
* alternative hashing is disabled.
*/
transient int hashSeed = 0;
/**
* 按需初始化哈希種子
*/
final boolean initHashSeedAsNeeded(int capacity) {
// 如果hashSeed != 0，表示當前正在使用備用哈希
boolean currentAltHashing = hashSeed != 0;
// 如果vm啓動了且map的容量大於閾值，使用備用哈希
boolean useAltHashing = sun.misc.VM.isBooted() &&
(capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD);
// 異或操作，如果兩值同時爲false，或同時爲true，都算是false。
boolean switching = currentAltHashing ^ useAltHashing;
if (switching) {
// 把hashSeed設置成隨機值
hashSeed = useAltHashing
? sun.misc.Hashing.randomHashSeed(this)
: 0;
}
return switching;
}
從hashSeed變量的註釋可以看出，哈希種子一個隨機值，在計算key的哈希碼時會用到這個種子，目的是爲了進一步減少哈希碰撞。如果hashSeed=0表示禁用備用哈希。
而Holder中維護的ALTERNATIVE_HASHING_THRESHOLD是觸發啓用備用哈希的閾值，該值表示，如果容器的容量（注意是容量，不是實際大小）達到了該值，容器應該啓用備用哈希。
Holder會嘗試讀取JVM啓動時傳入的參數-Djdk.map.althashing.threshold並賦值給ALTERNATIVE_HASHING_THRESHOLD。它的值有如下含義：
- ALTERNATIVE_HASHING_THRESHOLD = 1，總是使用備用哈希
- ALTERNATIVE_HASHING_THRESHOLD = -1，禁用備用哈希
在initHashSeedAsNeeded(int capacity)方法中，會判斷如果容器的容量>=ALTERNATIVE_HASHING_THRESHOLD，就會生成一個隨機的哈希種子hashSeed，該種子會在put方法調用過程中的hash方法中使用到：
/**
* 獲取key的哈希碼，並應用一個補充的哈希函數，構成最終的哈希碼。
* This is critical because HashMap uses power-of-two length hash tables, that
* otherwise encounter collisions for hashCodes that do not differ
* in lower bits. Note: Null keys always map to hash 0, thus index 0.
*/
final int hash(Object k) {
// 如果哈希種子是隨機值，使用備用哈希
// （方法調用鏈：inflateTable()-->initHashSeedAsNeeded()-->hash()，
// 在initHashSeedAsNeeded()中已判斷了是否需要初始化哈希種子）
int h = hashSeed;
if (0 != h && k instanceof String) {
return sun.misc.Hashing.stringHash32((String) k);
}
h ^= k.hashCode();
// This function ensures that hashCodes that differ only by
// constant multiples at each bit position have a bounded
// number of collisions (approximately 8 at default load factor).
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
計算存儲下標（indexFor）
/**
* 根據哈希碼計算返回哈希表的下標
*/
static int indexFor(int h, int length) {
// assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";
return h & (length-1);
}
這段代碼和簡單，卻有幾個有意思的地方。
爲什麼容量要設計成２的ｎ次冪
注意，容量實質就是內部數組的length，還要注意是2的n次冪，不是2的倍數。先看下面的測試代碼：
public class Main {
static final int hash(Object k) {
int hashSeed = 0;
int h = hashSeed;
if (0 != h && k instanceof String) {
return sun.misc.Hashing.stringHash32((String) k);
}
h ^= k.hashCode();
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
static int indexFor(int h, int length) {
return h & (length-1);
}
public static void main(String[] args) {
String key = "14587";
int h = hash(key);
int capacity = 16;
for (int i = 0; i < 10; i++) {
System.out.println(String.format("哈希碼: %d, 容量: %d, 下標: %d",
h, // 同一個哈希碼
(capacity<<i), // 不同的容量
indexFor(h,capacity<<i))); //計算出來的下標
}
}
// key: hello
// 哈希碼: 96207088, 容量: 16, 下標: 0
// 哈希碼: 96207088, 容量: 32, 下標: 16
// 哈希碼: 96207088, 容量: 64, 下標: 48
// 哈希碼: 96207088, 容量: 128, 下標: 112
// 哈希碼: 96207088, 容量: 256, 下標: 240
// 哈希碼: 96207088, 容量: 512, 下標: 240
// 哈希碼: 96207088, 容量: 1024, 下標: 240
// 哈希碼: 96207088, 容量: 2048, 下標: 240
// 哈希碼: 96207088, 容量: 4096, 下標: 240
// 哈希碼: 96207088, 容量: 8192, 下標: 240
// key: 4
// 哈希碼: 55, 容量: 16, 下標: 7
// 哈希碼: 55, 容量: 32, 下標: 23
// 哈希碼: 55, 容量: 64, 下標: 55
// 哈希碼: 55, 容量: 128, 下標: 55
// 哈希碼: 55, 容量: 256, 下標: 55
// 哈希碼: 55, 容量: 512, 下標: 55
// 哈希碼: 55, 容量: 1024, 下標: 55
// 哈希碼: 55, 容量: 2048, 下標: 55
// 哈希碼: 55, 容量: 4096, 下標: 55
// 哈希碼: 55, 容量: 8192, 下標: 55
// key: 14587
// 哈希碼: 48489485, 容量: 16, 下標: 13
// 哈希碼: 48489485, 容量: 32, 下標: 13
// 哈希碼: 48489485, 容量: 64, 下標: 13
// 哈希碼: 48489485, 容量: 128, 下標: 13
// 哈希碼: 48489485, 容量: 256, 下標: 13
// 哈希碼: 48489485, 容量: 512, 下標: 13
// 哈希碼: 48489485, 容量: 1024, 下標: 13
// 哈希碼: 48489485, 容量: 2048, 下標: 1037
// 哈希碼: 48489485, 容量: 4096, 下標: 1037
// 哈希碼: 48489485, 容量: 8192, 下標: 1037
}
上面的hash、indexFor都是從HashMap源碼中拷過來的，hashSeed=0也是HashMap默認的值，main方法中按key計算哈希碼再按哈希碼和數組長度計算下標也是put方法中的執行邏輯。從測試結果可以看出，相同的哈希碼，在多次擴容時，使用indexFor的算法，下標變動較少，這樣能減少擴容引起的移動Entry的操作次數。
可以看看key爲4，容量爲16、32、64…時indexFor計算下標的過程。
字符串“4”的哈希碼是：55（二進制110111）
當length = 16時：
h & (length-1)
= 55 & (16-1)
= 110111 & 1111
當length = 32時：
h & (32-1)
= 55 & (16-1)
= 110111 & 11111
當length = 64時：
h & (length-1)
= 55 & (64-1)
= 110111 & 111111
由於容量每次擴容都會翻倍（容量 x 2），翻到特定次數後（紅色虛線往左），跟h做與運算的位肯定是全部都是1，所以算出來的下標都會是一樣的。這樣子，雖然擴容會引起下標變動，但相對穩定。
試想想，如果容量是17、33、65…那麼lenght-1的二進制除了高位（最左一位）是1，其餘是0，不同hash和length-1做與運算算出來的下標就更容易有重複的下標。使lenght-1的全部位爲1，能使計算出來的下標分佈更均勻，減少哈希碰撞。
小結一下，容量設計成2的n次冪是爲了：
- 在put方法中，有調用indexFor計算下標，容量設計成2的n次冪能使下標相對均勻，減少哈希碰撞
- 在擴容相關的transfer方法中，也有調用indexFor重新計算下標。容量設計成2的n次冪能使擴容時重新計算的下標相對穩定，減少移動元素
擴容與線程安全問題
/**
* Rehashes the contents of this map into a new array with a
* larger capacity. This method is called automatically when the
* number of keys in this map reaches its threshold.
*
* If current capacity is MAXIMUM_CAPACITY, this method does not
* resize the map, but sets threshold to Integer.MAX_VALUE.
* This has the effect of preventing future calls.
*
* @param newCapacity the new capacity, MUST be a power of two;
* must be greater than current capacity unless current
* capacity is MAXIMUM_CAPACITY (in which case value
* is irrelevant).
*/
void resize(int newCapacity) {
// 緩存就哈希表數據
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}
// 用擴容容量創建一個新的哈希表
Entry[] newTable = new Entry[newCapacity];
transfer(newTable, initHashSeedAsNeeded(newCapacity));
table = newTable;
threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}
/**
* 把所有條目從當前哈希錶轉移到新哈希表
*/
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
從上圖顯示的轉移過程可以看出，鏈表在轉移後會逆序。3–>7–>9 變成 9–>7–>3。在單線程環境下，是不會出現閉合的迴路的。
但是在多線程環境下，有可能多條線程都調用transfer，而transfer方法中訪問了一個全局變量table，並修改下標中指向的Entry。由於轉移過程會導致鏈表逆序，就有可能出現閉環的引用：3–>7–>9–>3，然後，在調用get方法的時候，就出現死循環。
希望對大家有所幫助，一起進步。點個贊吧，給個肯定！