记一次JDK1.8HashMap resize()方法线程不安全验证_hashmap 1.8resize安全-优快云博客

HashMap线程安全性问题算是老生常谈的问题了，HashMap的线程不安全性主要就体现在resize()方法中了，本文就针对HashMap resize()方法做一些线程安全性的测试，注意JDK版本为1.8，1.7不适用

1.先上JDK1.8 HashMap源代码

final Node<K,V>[] resize() {
        Node<K,V>[] oldTab = table;
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;
        int newCap, newThr = 0;
        if (oldCap > 0) {
            if (oldCap >= MAXIMUM_CAPACITY) {
                threshold = Integer.MAX_VALUE;
                return oldTab;
            }
            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                     oldCap >= DEFAULT_INITIAL_CAPACITY)
                newThr = oldThr << 1; // double threshold
        }
        else if (oldThr > 0) // initial capacity was placed in threshold
            newCap = oldThr;
        else {               // zero initial threshold signifies using defaults
            newCap = DEFAULT_INITIAL_CAPACITY;
            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
        }
        if (newThr == 0) {
            float ft = (float)newCap * loadFactor;
            newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                      (int)ft : Integer.MAX_VALUE);
        }
        threshold = newThr;
        @SuppressWarnings({"rawtypes","unchecked"})
            Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
        table = newTab;
        if (oldTab != null) {
            for (int j = 0; j < oldCap; ++j) {
                Node<K,V> e;
                if ((e = oldTab[j]) != null) {
                    oldTab[j] = null;
                    if (e.next == null)
                        newTab[e.hash & (newCap - 1)] = e;
                    else if (e instanceof TreeNode)
                        ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                    else { // preserve order
                        Node<K,V> loHead = null, loTail = null;
                        Node<K,V> hiHead = null, hiTail = null;
                        Node<K,V> next;
                        do {
                            next = e.next;
                            if ((e.hash & oldCap) == 0) {
                                if (loTail == null)
                                    loHead = e;
                                else
                                    loTail.next = e;
                                loTail = e;
                            }
                            else {
                                if (hiTail == null)
                                    hiHead = e;
                                else
                                    hiTail.next = e;
                                hiTail = e;
                            }
                        } while ((e = next) != null);
                        if (loTail != null) {
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        if (hiTail != null) {
                            hiTail.next = null;
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }

本文只针对前半部分做测试(30行以前），具体扩容部分下次有时间补上，我们可以看见源码中主要流程是先创建一个新的哈希表，前面代码主要是确定新的哈希表的大小以及负载大小（即扩容大小),有了这两个参数，就可以创建一个哈希表了，紧接着就让原本的table（原哈希表指针）指向新创建的哈希表，然后再搬运数据到新的哈希表中，那么这里很自然就有一个问题了，由于是先让table指向新的哈希表再开始搬运数据，如果在table指向新引用后而数据搬运之前有一个线程来访问哈希表，此时新的哈希表中是没有数据的，原本旧的哈希表的数据是不是会取不到呢？于是就有了下面的测试（原本打算继承HashMap重写resize方法在搬运数据之前让线程睡眠来验证的，结果发现resize方法是final修饰的，坑爹）：

public class ResizeTest {
	private static HashMap<Integer, Integer> map = new HashMap<Integer, Integer>();
	public static void main(String[] args) throws FileNotFoundException {
		File file = new File("D:/testResize.txt");
		final PrintStream pw = new PrintStream(new FileOutputStream(file));
		new Thread(){
			public void run(){
				System.setOut(pw);
				while(true){
					if(map.get(1) == null){
						System.out.println("why?");
					}
					System.out.print(map.get(1));
				}
			}
		}.start();
		
		for(int i = 0; i < 2<<29; i++){
			map.put(i, i);
		}
		System.out.println("main end!");
	}
	
	
}

我们把数据全打印到一个文件里便于查找我们想要的数据，测试很简单，就是主线程不断的向hashmap中写数据（循环的次数一定要大以来引发足够多的扩容次数，从而增大引发并发问题的概率），再起一个线程不断的读取一个key的值，如果不存在线程安全的问题，那么只要读key的线程第一次读取到数据后就不会存在读取不到的情况（因为主线程没有去删除key的操作），再说明白点如果hashmap是线程安全的，那我们文件中的数据是不应该出现“why?"字样的（当然也可能出现在文件开头，但是概率很小），真实测试结果呢？

可以看见出现了why?字样（这里有些不明白为什么只出现一次，反复测试都只出现一次，猜测可能是因为写文件操作比较费时，耗时远远大于哈希重排，所以写完一次时哈希重排早已完成），这就证明了我们前面的猜测是正确的，也就是hashmap的确存在线程安全问题，当然在搬运数据时也存在并发问题，下次再针对搬运数据的并发问题作进一步测试

2.思考

上面的测试用例只能针对jdk1.8的，因为jdk1.7是先搬运数据到新的哈希表然后再让原有的table指向新的哈希表，乍一看jdk1.7的设计似乎更合理，其实不然，因为resize是导致hashmap并发问题的罪魁祸首，而我们知道哈希重排只用一个线程就可以完成了，参与哈希重排的线程越多就越容易引发并发问题，而jdk1.7由于是先搬运数据（哈希重排最耗时的操作)再改变引用指针，那就意味着在搬运的过程中就可能会有更多的线程进入到resize方法，而jdk1.8由于在搬运数据之前就把table指向一个空的哈希表，当其他线程在put操作时，直接插入到新的哈希表了，就不用再去参与哈希重排了，而缺点就是可能出现“不可重复读”(就像上面的测试结果一样），总之jdk1.8的思想就是参与哈希重排的线程越少越好