實在沒想到系列——HashMap實現底層細節之keySet,values,entrySet的一個底層實現細節

 

我在看HashMap源碼的時候發現了一個沒思考過的問題，在這次之前可以說是完全沒有思考過，所以一開始對這個點有疑問的時候,也沒有想到居然有這么個語法細節存在，弄得我百思不得其解，直到自己動手做實驗改寫了代碼才完全明白。

HashMap里面保存的數據最底層是一個Entry型的數組，這個Entry則保留了一個鍵值對，還有一個指向下一個Entry的指針。所以HashMap是一種結合了數組和鏈表的結構。正因為如此，你有3種對數據的觀測方式：keySet，values，entrySet。第一個是體現從key的值角度出發的結果。它里面包含了這個鍵值對表里面的所有鍵的值的集合，因為HashMap明確規定一個鍵只能對應一個值，所以不會有重復的key存在，這也就是為什么可以用集合來裝key。第二個values則是從鍵值對的值的角度看這個映射表，因為可以有多個key對應一個值，所以可能有多個相同的values。（這個觀點和函數的觀點相似）第三個角度是最基本的角度，也就是從鍵值對的角度思考這個問題。它返回一個鍵值對的集合。（鍵值對相等當且僅當鍵和值都相等）。

 

以上是大致的理解。在此基礎上，java的源碼:（這里我只用了keySet說明這個問題）

 

    public Set<K> keySet() {
        Set<K> ks = keySet;
        return (ks != null ? ks : (keySet = new KeySet()));
    }

    private final class KeySet extends AbstractSet<K> {
        public Iterator<K> iterator() {
            return newKeyIterator();
        }
        public int size() {
            return size;
        }
        public boolean contains(Object o) {
            return containsKey(o);
        }
        public boolean remove(Object o) {
            return HashMap.this.removeEntryForKey(o) != null;
        }
        public void clear() {
            HashMap.this.clear();
        }
    }

 

看上去簡單明了，可是我發現了一個細節並且與之糾纏了一個下午（這個語法細節隱藏的很深）。

這個地方我們可以看到，當向一個HashMap調用keySet()方法的時候就是返回一個集合，其內容是所有的key的值。可是問題是這個地方到底是怎么實現的。從代碼可以看到這個地方直接返回了一個叫keySet的東西。那么這個東西究竟是什么呢？按住command鍵可以直接去看這個變量聲明的地方：

在AbstractMap.class里面：

    transient volatile Set<K>        keySet = null;
    transient volatile Collection<V> values = null;

也就是說，這個地方是從HashMap的父類AbstractMap里面繼承過來的兩個集合類型（第一個就是我說的keySet，第二個和這個完全一樣的過程）。

可是問題還是沒有解決，這個keySet為什么能返回當前HashMap的key的值得集合呢？我一開始只是抱着“簡單看看”的想法來看這個地方，因為我的想象是可能能在哪里找到一個顯而易見的同步方法，使得keySet的里面的值隨着table（這也就是那個基礎數組，儲存了所有的鍵值對Entry）的值變化而變化。可是我發現：“沒有”。

第一時間我覺得我可能沒有找對位置，因為一般它提供的這些類的繼承關系比較復雜，可能不在這個地方，可能在別的地方實現了，可是我翻來覆去找半天確實發現沒有，也就是說：“沒有明確的代碼讓keySet同步HashMap”。這下問題就變大了，事實上如果你在AbstractMap里面找只找得到如下代碼：

    public Set<K> keySet() {
        if (keySet == null) {
            keySet = new AbstractSet<K>() {
                public Iterator<K> iterator() {
                    return new Iterator<K>() {
                        private Iterator<Entry<K,V>> i = entrySet().iterator();

                        public boolean hasNext() {
                            return i.hasNext();
                        }

                        public K next() {
                            return i.next().getKey();
                        }

                        public void remove() {
                            i.remove();
                        }
                    };
                }

                public int size() {
                    return AbstractMap.this.size();
                }

                public boolean isEmpty() {
                    return AbstractMap.this.isEmpty();
                }

                public void clear() {
                    AbstractMap.this.clear();
                }

                public boolean contains(Object k) {
                    return AbstractMap.this.containsKey(k);
                }
            };
        }
        return keySet;
    }

看上去完全不是一個同步過程，至少在我的理解中把一個容器的東西搬運到另外一個容器需要用循環把東西一個一個搬運過去，哪怕只是淺拷貝把指針的值丟過去。這一節代碼怎么看都和“讓keySet這個set持有table里面的key的值的集合”沒有任何關系。但是確確實實是這個地方實現了同步。

看如下代碼：

public class Main {

    public static void main(String[] args) {

        testIterator t = new testIterator();
        Set<Integer> set = t.keySet();
        System.out.println(set);

    }
}


class testIterator {
    public Set<Integer> keySet() {

        final ArrayList<Integer> result = new ArrayList<Integer>();
        result.add(1);
        result.add(2);
        result.add(3);

        Set<Integer> keySet = new AbstractSet<Integer>() {
            public Iterator<Integer> iterator() {
                return new Iterator<Integer>() {
                    private Iterator<Integer> i = result.iterator();

                    @Override
                    public boolean hasNext() {
                        return i.hasNext();
                    }

                    @Override
                    public Integer next() {
                        return i.next();
                    }

                    @Override
                    public void remove() {
                        i.remove();
                    }
                };
            }

            @Override
            public int size() {
                return 0;
            }
        };

        return keySet;
    }
}

這個地方的結果是：

[1, 2, 3]

 

為什么呢？這個地方的代碼是按照HashMap的代碼改寫的，我再改寫一下如下所示：

 

public class Main {

    public static void main(String[] args) {
        ArrayList<Integer> array = new ArrayList<Integer>();
        array.add(1);
        array.add(2);
        array.add(3);
        
        mySet set = new mySet(array.iterator());
        System.out.println(set);
    }

}

class mySet extends AbstractSet<Integer> {

    private Iterator<Integer> iter;

    public mySet(Iterator<Integer> i) {
        iter = i;
    }

    @Override
    public Iterator<Integer> iterator() {
        return iter;
    }

    @Override
    public int size() {
        return 0;
    }

}

也是一樣的效果。換句話說，直接讓一個set它持有一個別人的Iterrator，它會認為自己是它。同時如果調試運行會發現set的值真的變了。同時這么做是有問題的，調試運行的結果和直接運行不一樣同時再加上一句：System.out.println(set); 會發現第一次打印了1，2，3，第二次為null。換句話說這樣的代碼產生了不確定的行為。但是這代碼可以說明一些問題，至少表示離問題近了。

 

到目前為止，可以知道keySet返回的並不是個“新”的東西，所以也沒有把HashMap里面的key的值一個一個放到set的這個過程，而是通過生成一個set，這個set直接和HashMap的Iterator掛鈎來反映HashMap的變化。這個地方的“掛鈎”的具體過程是keySet繼承了AbstractSet這個抽象類，這個抽象類需要重寫iterator() 方法。

 

具體的代碼調用過程如下：

當你調用HashMap的keySet()方法的時候：

public Set<K> keySet() {
        Set<K> ks = keySet;
        return (ks != null ? ks : (keySet = new KeySet()));
    }

    private final class KeySet extends AbstractSet<K> {
        public Iterator<K> iterator() {
            return newKeyIterator();
        }
        public int size() {
            return size;
        }
        public boolean contains(Object o) {
            return containsKey(o);
        }
        public boolean remove(Object o) {
            return HashMap.this.removeEntryForKey(o) != null;
        }
        public void clear() {
            HashMap.this.clear();
        }
    }

可見：會返回一個名字叫keySet的Set。但是這個keySet如上面所寫的是來自AbstractMap的一個引用。我前面思路錯的原因是因為我一直認為需要去AbstractMap里面找它的具體實現，其實不是的。這個ks的第一次初始化就反映了問題的本質是通過引用。看它的初始化過程：返回了一個“newKeyIterator();”對象。那么這個對象是什么呢？

再往前的代碼：

    Iterator<K> newKeyIterator()   {
        return new KeyIterator();
    }

 

它調用了一個方法返回了一個 KeyIterator 對象。這個對象的代碼如圖所示：

    private final class KeyIterator extends HashIterator<K> {
        public K next() {
            return nextEntry().getKey();
        }
    }

它又基礎自HashIterator。看上去這個過程比較復雜，其實看源代碼的話可以很清楚它的意圖：keySet和values和entrySet本質既然一樣，就可以通過封裝其相同的部分（也就是這里的HashIterator），再各自實現最重要的next方法。

這是HashIterator的源代碼：

    private abstract class HashIterator<E> implements Iterator<E> {
        Entry<K,V> next;        // next entry to return
        int expectedModCount;   // For fast-fail
        int index;              // current slot
        Entry<K,V> current;     // current entry

        HashIterator() {
            expectedModCount = modCount;
            if (size > 0) { // advance to first entry
                Entry[] t = table;
                while (index < t.length && (next = t[index++]) == null)
                    ;
            }
        }

        public final boolean hasNext() {
            return next != null;
        }

        final Entry<K,V> nextEntry() {
            if (modCount != expectedModCount)
                throw new ConcurrentModificationException();
            Entry<K,V> e = next;
            if (e == null)
                throw new NoSuchElementException();

            if ((next = e.next) == null) {
                Entry[] t = table;
                while (index < t.length && (next = t[index++]) == null)
                    ;
            }
            current = e;
            return e;
        }

 

可見，對於迭代器的操作，其實都是根據底層的table來實現的，也就是直接操作鍵值對。在得到Entry之后再獲得它的key或者value。正因為如此，迭代器的底層直接根據table進行操作，所以如果有別的容器持有了這個迭代器內部類，就可以直接實現同步中的可見性：對HashMap的改變體現在table，而傳遞出去的內部類可以訪問table。

而這之所以可以實現的更底層一步的地方是迭代器的具體實現。一方面它是一個內部類可以直接訪問HashMap的table，另外一個方面是它用了類似指針的next引用，也就可以實現迭代。這種暴露一個內部類來實現外部訪問的方式我還真是第一次具體見到。

到這里我們就可以明白這整個過程了。