在前面我的一篇总结线程范围内共享数据文章中提到，为了数据能在线程范围内使用，我用了HashMap来存储不同线程中的数据，key为当前线程，value为当前线程中的数据。我取的时候根据当前线程名从HashMap中取即可。
因为当初学习HashMap和HashTable源码的时候，知道HashTable是线程安全的，因为里面的方法使用了synchronized进行同步，但是HashMap没有，所以HashMap是非线程安全的。在上面提到的例子中，我想反正不用修改HashMap，只需要从中取值即可，所以不会有线程安全问题，但是我忽略了一个步骤：我得先把不同线程的数据存到HashMap中吧，这个存就可能出现问题，虽然我存的时候key使用了不同的线程名字，理论上来说是不会冲突的，但是这种设计或者思想本来就不够严谨。这也是由于一个网友看到我的那篇文章后给我提出的问题，我后来仔细推敲了下，重新温习了下HashMap的源码，再加上网上查的一些资料，在这里总结一下HashMap到底什么时候可能出现线程安全问题。
我们知道HashMap底层是一个Entry数组，当发生hash冲突的时候，HashMap是采用链表的方式来解决的，在对应的数组位置存放链表的头结点。对链表而言，新加入的节点会从头结点加入。javadoc中有一段关于HashMap的描述：
此实现不是同步的。如果多个线程同时访问一个哈希映射，而其中至少一个线程从结构上修改了该映射，则它必须保持外部同步。（结构上的修改是指添加或删除一个或多个映射关系的任何操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象，则应该使用 Collections.synchronizedMap 方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的非同步访问，如下所示：
Map m = Collections.synchronizedMap(new HashMap(...));
可以看出，解决HashMap线程安全问题的方法很简单，下面我简单分析一下可能会出现线程问题的一些地方。
1. 向HashMap中插入数据的时候 |
在HashMap做put操作的时候会调用到以下的方法：
//向HashMap中添加Entry
void addEntry(int hash, K key, V value, int bucketIndex) {
if ((size >= threshold) && (null != table[bucketIndex])) {
resize(2 * table.length); //扩容2倍
hash = (null != key) ? hash(key) : 0;
bucketIndex = indexFor(hash, table.length);
}
createEntry(hash, key, value, bucketIndex);
}
//创建一个Entry
void createEntry(int hash, K key, V value, int bucketIndex) {
Entry<K,V> e = table[bucketIndex];//先把table中该位置原来的Entry保存
//在table中该位置新建一个Entry，将原来的Entry挂到该Entry的next
table[bucketIndex] = new Entry<>(hash, key, value, e);
//所以table中的每个位置永远只保存一个最新加进来的Entry，其他Entry是一个挂一个，这样挂上去的
size++;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
现在假如A线程和B线程同时进入addEntry，然后计算出了相同的哈希值对应了相同的数组位置，因为此时该位置还没数据，然后对同一个数组位置调用createEntry，两个线程会同时得到现在的头结点，然后A写入新的头结点之后，B也写入新的头结点，那B的写入操作就会覆盖A的写入操作造成A的写入操作丢失。
2. HashMap扩容的时候 |
还是上面那个addEntry方法中，有个扩容的操作，这个操作会新生成一个新的容量的数组，然后对原数组的所有键值对重新进行计算和写入新的数组，之后指向新生成的数组。来看一下扩容的源码：
//用新的容量来给table扩容
void resize(int newCapacity) {
Entry[] oldTable = table; //保存old table
int oldCapacity = oldTable.length; //保存old capacity
// 如果旧的容量已经是系统默认最大容量了，那么将阈值设置成整形的最大值，退出
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}
//根据新的容量新建一个table
Entry[] newTable = new Entry[newCapacity];
//将table转换成newTable
transfer(newTable, initHashSeedAsNeeded(newCapacity));
table = newTable;
//设置阈值
threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
那么问题来了，当多个线程同时进来，检测到总数量超过门限值的时候就会同时调用resize操作，各自生成新的数组并rehash后赋给该map底层的数组table，结果最终只有最后一个线程生成的新数组被赋给table变量，其他线程的均会丢失。而且当某些线程已经完成赋值而其他线程刚开始的时候，就会用已经被赋值的table作为原始数组，这样也会有问题。所以在扩容操作的时候也有可能会引起一些并发的问题。
3. 删除HashMap中数据的时候 |
删除键值对的源代码如下：
//根据指定的key删除Entry，返回对应的value
public V remove(Object key) {
Entry<K,V> e = removeEntryForKey(key);
return (e == null ? null : e.value);
}
//根据指定的key，删除Entry,并返回对应的value
final Entry<K,V> removeEntryForKey(Object key) {
if (size == 0) {
return null;
}
int hash = (key == null) ? 0 : hash(key);
int i = indexFor(hash, table.length);
Entry<K,V> prev = table[i];
Entry<K,V> e = prev;
while (e != null) {
Entry<K,V> next = e.next;
Object k;
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k)))) {
modCount++;
size--;
if (prev == e) //如果删除的是table中的第一项的引用
table[i] = next;//直接将第一项中的next的引用存入table[i]中
else
prev.next = next; //否则将table[i]中当前Entry的前一个Entry中的next置为当前Entry的next
e.recordRemoval(this);
return e;
}
prev = e;
e = next;
}
return e;
}
删除这一块可能会出现两种线程安全问题，第一种是一个线程判断得到了指定的数组位置i并进入了循环，此时，另一个线程也在同样的位置已经删掉了i位置的那个数据了，然后第一个线程那边就没了。但是删除的话，没了倒问题不大。
再看另一种情况，当多个线程同时操作同一个数组位置的时候，也都会先取得现在状态下该位置存储的头结点，然后各自去进行计算操作，之后再把结果写会到该数组位置去，其实写回的时候可能其他的线程已经就把这个位置给修改过了，就会覆盖其他线程的修改。
其他地方还有很多可能会出现线程安全问题，我就不一一列举了，总之HashMap是非线程安全的，在高并发的场合使用的话，要用Collections.synchronizedMap进行包装一下。另外还得感谢那位网友，我对HashMap线程安全问题的认识又进了一步~