Java EE 多线程之线程安全的集合类

原来的集合类，⼤部分都不是线程安全的

但是Vector，Stack，HashTable，是线程安全的(不建议⽤)，其他的集合类不是线程安全的

针对这些线程不安全的集合类，要想在多线程环境下使用，就需要考虑好 线程安全问题了（加锁）

同时，标准库，也给我们提供了一些搭配的组件，保证线程安全

1. 多线程环境使用 ArrayList

1. 1 Collections.synchronizedList(new ArrayList)

Collections.synchronizedList(new ArrayList)
这个东西会返回一个新的对象，这个新的对象，就相当于给 ArrayList 套了一层外衣
这个外衣就是在方法上直接使用 synchronized 的

1.2 CopyOnWriteArrayList

CopyOnWriteArrayList 称为写实拷贝

比如，两个线程使用同一个 ArrayList ，可能会读，也可能会修改

如果要是两个线程读，可以直接进行读
如果某个线程需要进行修改，就把 ArrayList 复制出一份副本，修改这个副本
于此同时，另一个线程仍然可以读取书库（从原来的数据上进行读取）
一旦这边修改完毕，就会使用修改好的这份数据，替代掉原来的数据（往往就是一个引用赋值）

上述这个过程进行修改，就不需要加锁了

---

但是上述操作会存在一些问题

1. 当前操作的 ArrayList 不能太大（拷贝成本，不能太高）
2. 更适合于一个线程去修改，而不是多个线程同时修改（多个线程去，一个线程修改）

---

这种场景适合于 服务器的配置更新

可以通过配置文件，来描述配置的详细内容（本身不会很大）

配置的内容会被读到内存中，再由其他的线程，读取这里的内容
但是修改这个配置内容，往往只有一个线程来修改

如果程序员修改了配置文件，通过某种操作（使用命令）让服务器重新加载配置，就可使使用 写实拷贝 的方式

2. 多线程环境使用队列

2.1 ArrayBlockingQueue

基于数组实现的阻塞队列

2.2 LinkedBlockingQueue

基于链表实现的阻塞队列

2.3 PriorityBlockingQueue

基于堆实现的带优先级的阻塞队列

2.4 TransferQueue

最多只包含⼀个元素的阻塞队列

3. 多线程环境使用哈希表

HashMap 本⾝不是线程安全的
在多线程环境下使⽤哈希表可以使⽤:
• Hashtable
• ConcurrentHashMap

3.1 Hashtable

Hashtable 保证线程安全，主要就是给关键方法，加上 synchronized
synchronized 是直接加到方法上的（相当于给 this 加锁）

只要两个线程，在同时操作同一个 Hashtable 就会出现锁冲突

---

但是实际上，对于哈希表来时，锁不一定非要这么加，有些情况，其实并不涉及到线程安全问题

两个不同的 key 映射到同一个数组下标上就会出现 hash 冲突
这个时候，我们可以使用链表来解决 hash 冲突

按照上述这样的方式，并且在不考虑触发扩容的前提下
操作不同的链表的时候就是线程安全的

相比之下，如果两个线程，操作的是同一个链表，会容易出现问题

如果两个线程，操作的是不同的链表，就根本不用加锁，只有说操作的是同一个链表才需要加锁

3.2 ConcurrentHashMap

ConcurrentHashMap 的改良方式：

1. ConcurrentHashMap 相对比上述的HashMap，最核心的改进，就是把一个全局的大锁，改进成了 每个链表独立的一把小锁
   这样做大幅度降低了锁冲突的概率
   一个 hash 表，有很多这样的链表，两个线程恰好同时访问一个链表的情况，本身就比较少
2. 充分利用到了 CAS 特性，把一些不必要加锁的环节给省略加锁了
   比如，需要使用变量记录 hash 表中的元素个数
   此时，就可以使用原子操作（CAS）修改元素个数
3. ConcurrentHashMap 还有一个激进的操作，针对读操作没有加锁
   读和读之间，读和写之间，都不会有锁竞争
   那么是否会存在“读一半 修改了一半”的数值呢？
   ConcurrentHashMap 在底层编码过程中，比较谨慎的处理了一些细节
   修改的时候会避免使用 ++ – 这种非原子的操作
   使用 = 进行修改，本身就是原子的
   读的时候，要么读的就是写之前的旧值，要么是读到写之后的心智，不会出现读到一个 一半的值
   （写和写之间还是需要加锁的）
4. ConcurrentHashMap 针对扩容操作，做出了单独的优化
   本身 Hashtable 或者 HashMap 在扩容的时候，都是需要把所有的元素都拷贝一遍（如果元素很多，拷贝就比较耗时）
   比如，用户访问 1000 次，999 次都很流畅，其中一次就卡了（正好这一次触发扩容，导致出现卡顿）
   ConcurrentHashMap 的优化方式就是“化整为零”
   一旦需要扩容，确实需要搬运，不是在一次操作中搬运完成，而是分成多次 来搬运
   每次只搬运一部分数据，这样就可以避免这单次操作过于卡顿

ConcurrentHashMap 基本的使用方法和普通的 HashMap 完全一样

在第一点中，我们是怎么把每个链表单独加锁的呢？
其实就是把每个链表的头结点，作为锁对象
synchronized 可以使用任意对象作为锁对象

在这个时候，我们有的时候会提到分段锁
什么是分段锁呢？
在 java 8 之前， ConcurrentHashMap 就是基于分段锁的方式实现的
等到 java 8 开始之后，就成了直接在链表头结点，加锁的形式