HashMap为什么是线程不安全的
import java.util.HashMap;
/**
* 由于 HashMap 的线程不安全性,最终的 HashMap 值可能不符合预期。
* 例如,预期值应该是 0(因为增加和减少操作相互抵消),但实际上可能得到一个不同的值。
*/
public class HashMapThreadUnsafeDemo {
public static void main(String[] args) throws InterruptedException {
// 创建一个 HashMap
HashMap<String, Integer> map = new HashMap<>();
// 初始化 HashMap
map.put("key", 0);
// 创建并启动线程
Thread incrementThread = new Thread(new IncrementTask(map));
Thread decrementThread = new Thread(new DecrementTask(map));
incrementThread.start();
decrementThread.start();
// 等待所有线程完成
incrementThread.join();
decrementThread.join();
// 输出最终的 HashMap
System.out.println("最终的 HashMap: " + map);
}
static class IncrementTask implements Runnable {
private final HashMap<String, Integer> map;
public IncrementTask(HashMap<String, Integer> map) {
this.map = map;
}
@Override
public void run() {
try {
for (int i = 0; i < 1000; i++) {
int value = map.get("key");
value++;
map.put("key", value);
System.out.println("IncrementThread: key=" + value);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
static class DecrementTask implements Runnable {
private final HashMap<String, Integer> map;
public DecrementTask(HashMap<String, Integer> map) {
this.map = map;
}
@Override
public void run() {
try {
for (int i = 0; i < 1000; i++) {
int value = map.get("key");
value--;
map.put("key", value);
System.out.println("DecrementThread: key=" + value);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
同时put碰撞导致数据丢失
两个同样put的key发生了碰撞,根据hash值计算出来的bucket位置一样,两个线程又同时判断该位置是空的,可以写入两个不同的value便会添加到数组的同一个位置,最终就只会保留一个数据,丢失一个数据
可见性问题无法保证
死循环造成CPU100%
- 散列冲突和链表遍历
在 HashMap 中,如果散列冲突较多,且链表较长,那么在遍历时可能会出现性能问题。虽然现代 HashMap 实现(如 Java 8 中的 HashMap)已经采用了数组加链表(或红黑树)的方式,但在极端情况下仍然可能出现问题。 - 多线程并发修改
在多线程环境下,如果没有适当的同步机制,多个线程同时修改 HashMap 可能会导致数据不一致,甚至死循环。例如,在 HashMap 的迭代过程中,如果其他线程修改了 HashMap,可能会抛出 ConcurrentModificationException。 - 散列函数设计不当
如果散列函数设计不当,可能会导致大量的散列冲突,进而导致性能问题。虽然 HashMap 内部的散列函数通常已经经过优化,但在某些特殊情况下仍可能出现问题。
推荐使用线程安全同时性能比较好的ConcurrentHashMap
ConcurrentHashMap在java7、8中的不同
java7版本的ConcurrentHashMap
[外链图片转存中…(img-myliuXrq-1734854427939)]
每个Segment之间都独立的一把锁。默认情况下是16个Segment,所以最大的情况下可以支撑16个线程进行并发操作。16可以在初始的改为其他值,但是改为之后就不能再扩容了
java8版本的ConcurrentHashMap
红黑树的特点
红黑树是每个节点都带有颜色属性的二叉查找树,本质是对二叉查找树BST的一种平衡策略。
[外链图片转存中…(img-QHM5hdLX-1734854427940)]
[外链图片转存中…(img-r5F8YwGQ-1734854427940)]
图示类型,
第一种是空着的位置代表当前还没有元素来填充
第二种是和HashMap非常类似的拉链法结构
第三种是红黑树结构
异同和优缺点
数据结构 | 并发度 | 保证并发安全的原理 | 遇到Hash碰撞 | 查询时间复杂度 | |
---|---|---|---|---|---|
java7 | 采用Segment分段锁来实现 | 每个Segment独立加锁,最大的并发个数就是Segment的个数(默认是16) | 采用Segment分段锁来保证安全 | 使用拉链法 | 遍历链表的时间复杂度时O(n),n为链表长度 |
java8 | 使用数组+链表+红黑树 | 锁粒度更细,并发度比之前有提高 | 采用Node+CAS+synchronized保证安全 | 先使用拉链法,在链表长度超过一定阈值时,将链表转换为红黑树 | 如果变成遍历红黑树,时间复杂度降低为O(log(n)),n为树的节点个数 |
为什么Map的桶中超过8个才转为红黑树?
为什么需要转换
每次遍历一个链表,平均查找时间复杂度是O(n),n是链表的长度,为了提升查找性能,需要把链表转化为红黑树的形式。
[外链图片转存中…(img-m3MSyO3u-1734854427940)]
[外链图片转存中…(img-32VpH1Ub-1734854427940)]
总结
- 防止用户自己实现了不好的哈希算法时链表过长,导致查询效率低
- 转为红黑树是一种保底策略,用来保证极端情况下查询的效率
- 通常情况下并没有必要转为红黑树,所以就选择了概率非常小,也就是长度为8的概率
- 如果平时开发中发现HashMap或是ConcurrentHashMap内部出现了红黑树的结构,往往就说明我们的哈希算法出了问题
同样是线程安全,ConcurrentHashMap和Hashtable的区别
出现时间 | 实现线程安全方式 | 性能 | 迭代时修改的不同 | |
---|---|---|---|---|
hashtable | JDK1.0 | 通过synchronized关键字 | 线程数量增加的时候性能急剧下降,因为每次都要锁住整个对象,其他线程期间不能操作,会有额外的上下文切换等开销 | 不允许在迭代期间修改内容,其原理是监测modCount变量 |
concurrentHashMap | JDK1.5 | 采用Node+CAS+synchronized保证安全 | 仅会对一部分上锁而不是全部都上锁 | 在迭代期间修改内容也不会抛出异常 |
CopyOnWriteArrayList的特点
没有之前
List的数组和链表实现为ArrayList和LinkedList,线程安全的有Vector和Collentions.synchronizedList(),但是锁的粒度比较大,在迭代期间进行添加元素或者删除元素等操作,都会抛出异常。
使用场景
- 读操作可以尽可能地快,而写即使慢一些也没有关系
- 读多写少:黑名单场景
读写规则
对读写锁规则进行升级,CopyOnWriteArrayList读取时完全不用加锁的,可以在写入的同时进行读取。
特点
CopyOnWrite的含义
当容器需要被修改的时候,不直接修改当前容器。
- 先将当前容器进行copy,复制出一个新的容器
- 然后修改新的容器
- 完成修改之后,再将原容器的引用指向新的容器
优点
- 利用“不变性”原理保证旧容器线程安全
- 可以对CopyOnWrite容器进行并发的读,而不需要加锁
- CopyOnWrite容器时一种读写分离的思想体现
迭代期间允许修改集合内容
创建迭代器后,还可以添加上或修改内容。
缺点
内存占用问题
CopyOnWrite的写时复制机制,在进行写操作的时候内存里会同时驻扎两个对象的内存,这一点会占用额外的内存
在元素较多或者复杂的情况下,复制的开销很大
复制过程不仅会占用双倍内存,还需要消耗CPU等资源会降低整体性能
数据一致性问题
由于CopyOnWrite容器的修改对于其他线程来说并不是实时能看到的,只有在修改完之后才能体现出来
迭代器COWiterator类
迭代器有两个重要的属性,分别是Object[] snapshot和 int cursor。snapshot代表数组的快照,cursor则是迭代器的游标。