集合类的线程安全问题

文章讨论了Java中的集合类在多线程环境下的线程安全性,强调了Vector、Stack和HashTable的线程安全问题,以及ArrayList、CopyOnWriteArrayList等的不同使用方法。重点介绍了ConcurrentHashMap的锁机制和优化,对比了Hashtable与HashMap/ConcurrentHashMap的区别。
摘要由CSDN通过智能技术生成

集合类

原来的集合类,大部分都不是线程安全的
Vector, Stack, HashTable, 是线程安全的(不建议用), 其他的集合类不是线程安全的.
加了锁,不一定就是线程安全的,不加锁也不一定是线程不安全的,需要具体问题具体分析
虽然get,set方法都加了synchronized,但是如果不能正确使用,也可能会出现线程安全问题
1.如果是多个线程,并发执行set操作,由于synchronized限制,是线程安全.
2.如果多个线程进行一些复杂的操作,比如先判定get的值是xxxx,再进行set,就出现了一种情况,使得整个逻辑变得不是一个原子级别的任务
即使把这里的get和set分别进行加锁,如果不能正确的使用,也可能产生线程安全问题,而且在单线程的情况下,有可能会因为synchronized影响到执行效率

多线程环境使用 ArrayList

自己使用同步机制 (synchronized 或者 ReentrantLock)

Collections.synchronizedList(new ArrayList);
ArrayList本身没有使用synchronized,但是你又不想自己加锁,就可以使用上面这个方法.,相当于让ArrayList像Vector一样工作

使用 CopyOnWriteArrayList

CopyOnWrite容器即写时复制的容器。
当我们往一个容器添加元素的时候,不直接往当前容器添加,而是先将当前容器进行Copy,
复制出一个新的容器,然后新的容器里添加元素,
添加完元素之后,再将原容器的引用指向新的容器。
这样做的好处是我们可以对CopyOnWrite容器进行并发的读,而不需要加锁,因为当前容器不会添加任何元素。
所以CopyOnWrite容器也是一种读写分离的思想,读和写不同的容器。
优点:
在读多写少的场景下, 性能很高, 不需要加锁竞争.
缺点:

  1. 占用内存较多.
  2. 新写的数据不能被第一时间读取到

多线程环境使用队列

  1. ArrayBlockingQueue
    基于数组实现的阻塞队列
  2. LinkedBlockingQueue
    基于链表实现的阻塞队列
  3. PriorityBlockingQueue
    基于堆实现的带优先级的阻塞队列
  4. TransferQueue
    最多只包含一个元素的阻塞队列

多线程环境使用哈希表

HashMap 本身不是线程安全的.
在多线程环境下使用哈希表可以使用:
Hashtable
ConcurrentHashMap

Hashtable

只是简单的把关键方法加上了 synchronized 关键字.
这相当于直接针对 Hashtable 对象本身(this)加锁.
如果多线程访问同一个 Hashtable 就会直接造成锁冲突(读也会).
size 属性也是通过 synchronized 来控制同步, 也是比较慢的.
一旦触发扩容, 就由该线程完成整个扩容过程. 这个过程会涉及到大量的元素拷贝, 效率会非常低.

ConcurrentHashMap

相比于 Hashtable 做出了一系列的改进和优化. 以 Java1.8 为例
读操作没有加锁(但是使用了 volatile 保证从内存读取结果), 只对写操作进行加锁. 加锁的方式仍然是是用 synchronized, 但是不是锁整个对象, 而是 “锁桶” (用每个链表的头结点作为锁对象), 大大降低了锁冲突的概率.
充分利用 CAS 特性. 比如 size 属性通过 CAS 来更新. 避免出现重量级锁的情况.
优化了扩容方式: 化整为零
发现需要扩容的线程, 只需要创建一个新的数组, 同时只搬几个元素过去.
扩容期间, 新老数组同时存在.
后续每个来操作 ConcurrentHashMap 的线程, 都会参与搬家的过程. 每个操作负责搬运一小部分元素.
搬完最后一个元素再把老数组删掉.
这个期间, 插入只往新数组加.
这个期间, 查找需要同时查新数组和老数组
在这里插入图片描述
ConcurrentHashMap的每一个哈希桶上都有一把锁,只有当两个线程访问同一个哈希桶的时候才会出现锁冲突

相关面试题

  1. ConcurrentHashMap的读是否要加锁,为什么?
    读操作没有加锁. 目的是为了进一步降低锁冲突的概率. 为了保证读到刚修改的数据, 搭配了
    volatile 关键字.
  2. 介绍下 ConcurrentHashMap的锁分段技术?
    这个是 Java1.7 中采取的技术. Java1.8 中已经不再使用了. 简单的说就是把若干个哈希桶分成一个"段" (Segment), 针对每个段分别加锁.目的也是为了降低锁竞争的概率. 当两个线程访问的数据恰好在同一个段上的时候, 才触发锁竞争.
  3. ConcurrentHashMap在jdk1.8做了哪些优化?
    取消了分段锁, 直接给每个哈希桶(每个链表)分配了一个锁(就是以每个链表的头结点对象作为锁对象).将原来 数组 + 链表 的实现方式改进成 数组 + 链表 / 红黑树 的方式. 当链表较长的时候(大于等于8 个元素)就转换成红黑树
  4. Hashtable和HashMap、ConcurrentHashMap 之间的区别?
    HashMap: 线程不安全. key 允许为 null
    Hashtable: 线程安全. 使用 synchronized 锁 Hashtable 对象, 效率较低. key 不允许为 null.
    ConcurrentHashMap: 线程安全. 使用 synchronized 锁每个链表头结点, 锁冲突概率低, 充分利用CAS 机制. 优化了扩容方式. key 不允许为 null
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值