数据结构-Map jdk1.8

数据结构-Map jdk1.8

Hashmap

默认数组容量16，扩容0.75，转红黑树8，转回链表6

数据结构

数据结构终极目标:查的快改的也快
查询迅速:数组
增删迅速:链表

JDK1.8之前就是使用数组+链表的结构综合两者的优势

由于链表查询慢，O(n),JDK1.8之后，对链表进行了优化，当满足某些条件时,整个链表转为红黑树；

值放哪

下标的确认

    //方式一:取模   私以为这种方式可读性更改 没什么限制
    int index = hashCode % tab.cap ;//通过数组下标取模保证通过hashcode一定是在数组下标上

    //方式二:位运算 CPU操作速度更快，  有限制 需要数组容量是2的次方 才能保证tab.cao-1 = 011111111
    //进一步保证计算结果是hashCode的
    int index = hashCode & (tab.cap -1);

    //101110001110101110 1001 &0 1111 = 1001 = 9
    //方式二 要保证tab.cap-1 的结果时01111111才可以保证最终结果的值都来源于原始的hashcode，
    // 如果不是2的n次方，那位与运算时必定有些值是得不到的，不能均匀

这也是为什么数据初始容量要求是2的n次方了(比如16)

在使用方式二的运算，计算下标时只会用到原hashcode的低位，为了保证冲突更少，通过亦或运算将高16位与低位结合保证数据冲突的概率更低

当然如果下标已有值，即产生了hash冲突

Hash冲突

既然是hashmap，那hash冲突是无法避免的，hashmap当发现同一位置有值时，就往链表下走，而如果插入后链表长度达到8，则转红黑树
为什么转红黑树要求链表长度是8呢?
个人认为，优化的目标是为了提高查询效率，而转换成红黑树的过程也是需要CPU计算的，所以这个转换的条件需要提高的查询效率能抵消转换的消耗，
习惯性的以2的次方来算，O(n) vs O(logn),当达到8次是，链表查询0~8次，红黑树0~3次，这个查询效率的增加认为已经可以抵消了

部分源码

public V put(K key, V value) {
        //会重新计算hash值 并不会直接调用K的hashCode
        return putVal(hash(key), key, value, false, true);
 }

 static final int hash(Object key) {
        int h;
        //将32位的hashcode值重新计算，异或运算 确保低十六位上是来源于 高十六位与低十六位的综合结果
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        Node<K,V>[] tab; Node<K,V> p; int n, i;
        if ((tab = table) == null || (n = tab.length) == 0)
        //计算下标(n - 1) & hash
        if ((p = tab[i = (n - 1) & hash]) == null)
            //数值下标位置没值就放入数组
            tab[i] = newNode(hash, key, value, null);
        else {
            Node<K,V> e; K k;
            //hash冲突
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            //hash冲突后 如果已经是红黑树 则放红黑树
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
                //hash冲突后 先放链表
                 for (int binCount = 0; ; ++binCount) {
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        //如果放之后=8了，则转换为红黑树
                        if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                            treeifyBin(tab, hash);
                        break;
                    }
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    p = e;
                }
            }
            //hash冲突后且equals的情况下 替换原来的值
            if (e != null) { // existing mapping for key
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        //操作次数+1  用于迭代器的快速失效 即迭代器/foreach遍历期间如果有其他线程操作 则这个值会变，变了就fail-fast 抛异常
        ++modCount;
        if (++size > threshold)//16*0.75=12
            resize();//扩容 翻倍 扩容后不行则扩到需要的容量
        afterNodeInsertion(evict);
        return null;
    }

数组扩容

扩容后重新计算hash
a.私以为:扩容后直接遍历久数据，调用put方法 重新计算hash 下标， 则代码复用 
        这也可以满足要求
b.源码: 分数组/链表/红黑树 ，对三种不同结构直接采用不同算法，效率更快

迭代器

hashmap中的迭代器和foreach个人感觉没什么区别

public void forEach(BiConsumer<? super K, ? super V> action) {
        //迭代器方式类似，拿到tab，然后操作其中的Node，也需要fail-fast
        Node<K,V>[] tab;
        if (action == null)
            throw new NullPointerException();
        if (size > 0 && (tab = table) != null) {
            int mc = modCount;
            for (int i = 0; i < tab.length; ++i) {
                for (Node<K,V> e = tab[i]; e != null; e = e.next)
                    action.accept(e.key, e.value);
            }
            //每次迭代 都确认modCount有没有被操作，即map有没有被改，有则fail-fast
            if (modCount != mc)
                throw new ConcurrentModificationException();
        }
    }