【多线程】线程安全的集合类

小轩在不在哟

已于 2022-09-30 11:20:14 修改

阅读量1.3k

点赞数

分类专栏：多线程 Java学习之旅操作系统文章标签： java java-ee intellij-idea

于 2022-04-13 19:50:11 首次发布

本文链接：https://blog.csdn.net/xqs196301/article/details/124155722

版权

90 篇文章 2 订阅

订阅专栏

10 篇文章 0 订阅

订阅专栏

9 篇文章 0 订阅

订阅专栏

1. 前言

原来的集合类, 大部分都不是线程安全的.
Vector, Stack, HashTable, 是线程安全的(不建议用), 其他的集合类不是线程安全的.

自己使用同步机制 (synchronized 或者 ReentrantLock)
Collections.synchronizedList(new ArrayList);
synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的 List.
synchronizedList 的关键操作上都带有 synchronized
使用 CopyOnWriteArrayList
CopyOnWrite容器即写时复制的容器

这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会
添加任何元素。
所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。

优点:
在读多写少的场景下, 性能很高, 不需要加锁竞争.
缺点:
占用内存较多.
新写的数据不能被第一时间读取到.

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

只是简单的把关键方法加上了 synchronized 关键字.
这相当于直接针对 Hashtable 对象本身加锁.

相当于一个Hashtable只有一把锁，两个线程访问Hashtable中的任意数据都会出现锁竞争，效率比较低

相比于 Hashtable 做出了一系列的改进和优化. 以 Java1.8 为例

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

锁桶图示如下：
在这里插入图片描述

ConcurrentHashMap 每个哈希桶都有一把锁
只有两个线程访问的恰好是同一个哈希桶上的数据才会出现锁冲突

ConcurrentHashMap 源码分析文章：点此传送门跳转💨

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