JUC并发工具---并发容器

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%

  1. 散列冲突和链表遍历
    在 HashMap 中,如果散列冲突较多,且链表较长,那么在遍历时可能会出现性能问题。虽然现代 HashMap 实现(如 Java 8 中的 HashMap)已经采用了数组加链表(或红黑树)的方式,但在极端情况下仍然可能出现问题。
  2. 多线程并发修改
    在多线程环境下,如果没有适当的同步机制,多个线程同时修改 HashMap 可能会导致数据不一致,甚至死循环。例如,在 HashMap 的迭代过程中,如果其他线程修改了 HashMap,可能会抛出 ConcurrentModificationException。
  3. 散列函数设计不当
    如果散列函数设计不当,可能会导致大量的散列冲突,进而导致性能问题。虽然 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的区别

出现时间实现线程安全方式性能迭代时修改的不同
hashtableJDK1.0通过synchronized关键字线程数量增加的时候性能急剧下降,因为每次都要锁住整个对象,其他线程期间不能操作,会有额外的上下文切换等开销不允许在迭代期间修改内容,其原理是监测modCount变量
concurrentHashMapJDK1.5采用Node+CAS+synchronized保证安全仅会对一部分上锁而不是全部都上锁在迭代期间修改内容也不会抛出异常

CopyOnWriteArrayList的特点

没有之前

List的数组和链表实现为ArrayList和LinkedList,线程安全的有Vector和Collentions.synchronizedList(),但是锁的粒度比较大,在迭代期间进行添加元素或者删除元素等操作,都会抛出异常。

使用场景

  • 读操作可以尽可能地快,而写即使慢一些也没有关系
  • 读多写少:黑名单场景

读写规则

对读写锁规则进行升级,CopyOnWriteArrayList读取时完全不用加锁的,可以在写入的同时进行读取。

特点

CopyOnWrite的含义

当容器需要被修改的时候,不直接修改当前容器。

  1. 先将当前容器进行copy,复制出一个新的容器
  2. 然后修改新的容器
  3. 完成修改之后,再将原容器的引用指向新的容器
优点
  • 利用“不变性”原理保证旧容器线程安全
  • 可以对CopyOnWrite容器进行并发的读,而不需要加锁
  • CopyOnWrite容器时一种读写分离的思想体现
迭代期间允许修改集合内容

创建迭代器后,还可以添加上或修改内容。

缺点

内存占用问题

CopyOnWrite的写时复制机制,在进行写操作的时候内存里会同时驻扎两个对象的内存,这一点会占用额外的内存

在元素较多或者复杂的情况下,复制的开销很大

复制过程不仅会占用双倍内存,还需要消耗CPU等资源会降低整体性能

数据一致性问题

由于CopyOnWrite容器的修改对于其他线程来说并不是实时能看到的,只有在修改完之后才能体现出来

迭代器COWiterator类

迭代器有两个重要的属性,分别是Object[] snapshot和 int cursor。snapshot代表数组的快照,cursor则是迭代器的游标。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

bufanjun001

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值