不出意外这是多线程的最后一篇文章，主要介绍的是面试中比较常考的一个点——多线程下使用容器，我们开始吧~
我们知道，在单线程环境下ArrayList、HashMap等容器使用起来非常方便，但在多线程环境中，如果多个线程同时对容器进行修改，就可能导致数据不一致、数组越界甚至死循环等问题
那么在多线程环境下我们该如何安全地使用这些容器呢？
1. 多线程下使用ArrayList
首先最直接也最简单的方式：加锁
List<Integer>list=newArrayList<>();synchronized(list){list.add();}这样写显然是可行的，也很灵活，但是对代码的侵入性强、且很容易出错（一旦出错年终奖就没了，，）
因此在实际开发过程中，更常见的做法是使用Java提供的线程安全容器，对并发控制进行统一封装（尽量把坑留给框架，而不是自己）
Collections.synchronizedList会返回一个线程安全的List，其内部通过在关键方法上加上synchronized来保证线程安全
虽然在一定程度上保证了线程安全，但是由于所有操作共用一把锁，并发度低，在读多写少场景下性能较一般，比较适合低并发场景
除了Collections.synchronizedList，Java还提供了另一种思路的线程安全list——CopyOnWriteArrayList
从名字就能看出来，它采用的是一种非常经典的并发设计思想：写时拷贝
写时拷贝的核心思路是：
- 读操作不加锁
- 写操作时先拷贝一份底层数组
- 在新数组上完成修改
- 最后一次性替换引用
好处很明显，实现了读写分离，写操作不会影响正在进行的读操作，读操作不加锁不会阻塞，并发性能很高；写操作内部使用ReentrantLock保证线程安全
同样它也存在问题，写操作时需要拷贝数组，内存开销较大；如果list本身很大或者写操作频繁，性能会明显下降；多个线程同时写入写操作仍会互相竞争锁
对比一下
| 方案 | 并发度 | 侵入性 | 适用场景 |
|---|---|---|---|
| 自行加锁 | 低 | 高 | 临时方案 |
| synchronizedList | 低 | 低 | 低并发 |
| CopyOnWriteArrayList | 高（读） | 低 | 读多写少 |
2. 多线程环境下使用队列
在多线程环境中，队列往往承担着线程协作的角色，例如经典的生产者-消费者模型
Java 在 java.util.concurrent 包中提供了一组 阻塞队列（BlockingQueue） 的实现，用于简化这类并发场景
阻塞队列的核心特性是，队列为空时take()阻塞，队列已满时put()阻塞，以此避免频繁的轮询和手动加锁
2.1 常见的BlockingQueue实现
- ArrayBlockingQueue：基于数组实现，容量固定，内存连续，结构简单
- LinkedBlockingQueue：基于链表实现，可以指定容量，吞吐量高（线程池中默认使用的就是这种队列实现）
- PriorityBlockingQueue：基于堆实现，支持元素优先级，出队顺序由优先级决定，而不是FIFO，适用于任务有明显优先级区分的场景
- TransferQueue：支持直接把元素交给消费者，如果没有消费者才会进入队列，更强调线程之间的“交接”，使用场景相对较少，但在高并发任务调用中性能表现优秀
3. 多线程环境下使用Map
和 ArrayList 类似，HashMap 在单线程环境下使用非常方便，但在多线程环境中却是典型的线程不安全容器
如果多个线程同时对HashMap进行put/resize等操作，可能会导致数据覆盖、链表结构被破坏、JDK7中可能出现死循环等
3.1 HashTable
HashTable是Java早期提供的线程安全Map，其实现方法也很直接：给几乎所有public方法加上了synchronized
这确实保证了线程安全，但问题同样明显，所有操作共用一把锁、并发度较低、在高并发场景下性能较差
因此，HashTable基本上只存在于学校教材中，实际开发中很少使用
3.2 ConcurrentHashMap
并发环境下的首选！！
它的设计目标非常明确：在保证线程安全的前提下，尽可能提高并发访问性能
为此，它主要做了三方面的优化：
① 细化锁粒度，从“锁整张表”到“锁单个桶”
JDK8中，写操作只锁当前桶（链表或红黑树），不同桶上的操作可以并发进行
这样一来只有在操作同一个桶时线程才可能发生阻塞，并发性能大幅提升
②原子操作维护size
Q: 为什么size在并发下这么难？
A: 多个线程同时size++，读size的线程可能看到中间状态，如果给size加全局锁，每次put/remove都要竞争，性能急剧下降
ConcurrentHashMap内部不是使用一个size，而是多个计数单元，类似
baseCount// 基础计数counterCells[]// 多个计数槽可以理解为使用多个小本子记账，而不是所有人挤在一本账上
写操作时尽量“就近记账”，通过原子操作（CAS）对计数进行更新，在并发冲突较大时，将计数分散到多个计数单元中，不同线程更新不同计数单元，从而减少竞争
在调用size()时，会将各个计数单元的值进行累加，得到当前Map的元素数量。由于统计过程中可能存在并发写入，size()返回的是一个瞬时近似值，但在绝大多数业务场景下是可以接收的
这样设计在避免全局锁的同时，显著提升了高并发下的整体性能
③渐进式rehash
扩容是Map中开销最大的操作之一，如果扩容时一次性创建新数组将所有元素整体搬迁，那么在高并发场景下性能会非常糟糕
ConcurrentHashMap的做法是，新表和旧表同时存在，扩容过程被“拆散”到后续的多次操作中完成
具体表现为：每次put/get/remove时，顺带迁移一小部分旧数据，直到所有桶都完成迁移（蚂蚁搬家，一点一点搬）
这种渐进式扩容的方式，有效避免了长时间阻塞
综上上上所述，ConcurrentHashMap的优势主要在于锁粒度小、并发度高、针对热点操作做了大量优化、在高并发场景下性能稳定可靠
因此在多线程环境中，除非有非常明确的理由，否则应该优先选择ConcurrentHashMap，而不是HashMap或者HashTable
完结撒花★,°:.☆(￣▽￣)/$:.°★。
