Why is HashMap insecure

Why is HashMap insecure

JDK1.8 in HashMap insecurity is mainly derived from data covering problem.

Note:
JDK1.8 uses tail interpolation when inserting elements.

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 = (tab = resize()).length;
        if ((p = tab[i = (n - 1) & hash]) == null) // 如果没有hash碰撞则直接插入元素
            tab[i] = newNode(hash, key, value, null);
        else {
    
    
            Node<K,V> e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
    
    
                for (int binCount = 0; ; ++binCount) {
    
    
                    if ((e = p.next) == null) {
    
    
                        p.next = newNode(hash, key, value, null);
                        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;
                }
            }
            if (e != null) {
    
     // existing mapping for key
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        ++modCount;
        if (++size > threshold)
            resize();
        afterNodeInsertion(evict);
        return null;
    }

(1) Data insertion coverage The
sixth line of code is to determine whether there is a hash collision. Assuming that two threads A and B are performing put operations, and the insertion subscript calculated by the hash function is the same, when thread A finishes executing the sixth line After the line of code, it is suspended due to the exhaustion of the time slice, and thread B inserts the element at the subscript after obtaining the time slice, and completes the normal insertion, and then thread A obtains the time slice because of the previous hash collision. Judgment, all at this time will not be judged, but directly inserted, which causes the data inserted by thread B to be overwritten by thread A, thus threading is not safe.

(2) The size of size covers
a ++size at line 38, threads A and B. When these two threads perform put operations at the same time, assume that the zise size of the current HashMap is 10, when thread A executes to line 38 , Get the size value of 10 from the main memory and prepare to perform the +1 operation, but because the time slice is exhausted, it has to give up the CPU. Thread B happily gets the CPU or gets the size value 10 from the main memory for +1 Operation, the put operation is completed and size=11 is written back to the main memory, then thread A gets the CPU again and continues to execute (at this time the value of size is still 10), when the put operation is completed, size=11 is written Back to the memory, at this time, threads A and B both performed a put operation, but the value of size only increased by 1, so the thread is not safe due to data overwriting.

Reference blog: Why is HashMap thread unsafe in JDK1.7 and JDK1.8?