目录
[📕 引言](#📕 引言)
[🌲多线程环境使用 ArrayList](#🌲多线程环境使用 ArrayList)
🚩自己使用同步机制 (synchronized 或者 ReentrantLock)
[🚩Collections.synchronizedList(new ArrayList);](#🚩Collections.synchronizedList(new ArrayList);)
[🚩使用 CopyOnWriteArrayList](#🚩使用 CopyOnWriteArrayList)
📕 引言
我们之前讲过的集合类，,大部分都不是线程安全的.
Vector, Stack, HashTable, 是线程安全的(都是自带了synchronized,不建议用), 其他的集合类不是线程安全的。
注意：加锁不能保证线程一定安全，不加锁也不能确定线程一定不安全，具体代码具体分析
为什么不建议使用呢？
因为我们在使用的时候，这些类就会自动的加锁，虽然编译器会自动优化为没有锁竞争的线程进行锁消除的优化，但是呢万一编译器没有优化好，就麻烦了
如果需要用到其他的类，就需要手动加锁，来保证线程安全（不同情况加锁方式也不同）
🌲多线程环境使用 ArrayList
🚩自己使用同步机制 (synchronized 或者 ReentrantLock)
这里就不在过多讲述了
🚩Collections.synchronizedList(new ArrayList);
-
synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的List.
-
synchronizedList 的关键操作上都带有 synchronized
相当于给ArrayList这些集合类，套一层壳，壳上是给关键方法都加了synchronized
🚩使用 CopyOnWriteArrayList
也是一种解决线程安全的问题的做法
使用CopyOnWrite容器即"写时拷贝"的容器
-
当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，
-
添加完元素之后，再将原容器的引用指向新的容器
例子：
这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。
所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。
优点:
- 在读多写少的场景下, 性能很高, 不需要加锁竞争.
缺点:
-
占用内存较多.
-
新写的数据不能被第一时间读取到
🎍多线程环境使用队列
这里简单讨论一下即可，前面讨论过。
-
ArrayBlockingQueue
基于数组实现的阻塞队列
-
LinkedBlockingQueue
基于链表实现的阻塞队列
-
PriorityBlockingQueue
基于堆实现的带优先级的阻塞队列
-
TransferQueue
最多只包含一个元素的阻塞队列
🎋多线程环境使用哈希表
HashMap 本身不是线程安全的.
在多线程环境下使用哈希表可以使用:
-
Hashtable(自带锁，只是线程比较安全，但不推荐使用)
-
ConcurrentHashMap(多线程使用哈希表，优先考虑这个)
🚩Hashtable
Hashtable在实现过程中只是简单的把关键方法加上了 synchronized 关键字.
观察源码即可：（就不一一展示了）
这相当于直接针对 Hashtable 对象本身加锁.
-
如果多线程访问同一个 Hashtable 就会直接造成锁冲突.
-
size 属性也是通过 synchronized 来控制同步, 也是比较慢的.
-
一旦触发扩容, 就由该线程完成整个扩容过程. 这个过程会涉及到大量的元素拷贝, 效率会非常低
🚩ConcurrentHashMap
相比于 Hashtable 做出了一系列的改进和优化.
1.使用"锁桶"的方式，来代替"一把全局锁"，有效的降低锁冲突的概率
2.HashMap的size，即使你插入的的元素是不同的链表上的元素，也会涉及到多个线程针对同一size变量进行修改。
引入 CAS ，通过 CAS 的方式来修改size，也就避免了加锁操作。也可进一步的提升效率
3.针对扩容操作的优化
核心思路："化整为零"
注意：
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