文章目录
- [1. 多线程环境使用 ArrayList](#1. 多线程环境使用 ArrayList)
-
- [1. 1 Collections.synchronizedList(new ArrayList)](#1. 1 Collections.synchronizedList(new ArrayList))
- [1.2 CopyOnWriteArrayList](#1.2 CopyOnWriteArrayList)
- [2. 多线程环境使用队列](#2. 多线程环境使用队列)
-
- [2.1 ArrayBlockingQueue](#2.1 ArrayBlockingQueue)
- [2.2 LinkedBlockingQueue](#2.2 LinkedBlockingQueue)
- [2.3 PriorityBlockingQueue](#2.3 PriorityBlockingQueue)
- [2.4 TransferQueue](#2.4 TransferQueue)
- [3. 多线程环境使用哈希表](#3. 多线程环境使用哈希表)
-
- [3.1 Hashtable](#3.1 Hashtable)
- [3.2 ConcurrentHashMap](#3.2 ConcurrentHashMap)
原来的集合类，⼤部分都不是线程安全的
但是Vector，Stack，HashTable，是线程安全的(不建议⽤)，其他的集合类不是线程安全的
针对这些线程不安全的集合类，要想在多线程环境下使用，就需要考虑好 线程安全问题了（加锁）
同时，标准库，也给我们提供了一些搭配的组件，保证线程安全
1. 多线程环境使用 ArrayList
1. 1 Collections.synchronizedList(new ArrayList)
Collections.synchronizedList(new ArrayList)
这个东西会返回一个新的对象，这个新的对象，就相当于给 ArrayList 套了一层外衣
这个外衣就是在方法上直接使用 synchronized 的
1.2 CopyOnWriteArrayList
CopyOnWriteArrayList 称为写实拷贝
比如，两个线程使用同一个 ArrayList ，可能会读，也可能会修改
如果要是两个线程读，可以直接进行读
如果某个线程需要进行修改，就把 ArrayList 复制出一份副本，修改这个副本
于此同时，另一个线程仍然可以读取书库（从原来的数据上进行读取）
一旦这边修改完毕，就会使用修改好的这份数据，替代掉原来的数据（往往就是一个引用赋值）
上述这个过程进行修改，就不需要加锁了
但是上述操作会存在一些问题
- 当前操作的 ArrayList 不能太大（拷贝成本，不能太高）
- 更适合于一个线程去修改，而不是多个线程同时修改（多个线程去，一个线程修改）
这种场景适合于 服务器的配置更新
可以通过配置文件，来描述配置的详细内容（本身不会很大）
配置的内容会被读到内存中，再由其他的线程，读取这里的内容
但是修改这个配置内容，往往只有一个线程来修改
如果程序员修改了配置文件，通过某种操作（使用命令）让服务器重新加载配置，就可使使用 写实拷贝 的方式
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 的改良方式：
- ConcurrentHashMap 相对比上述的HashMap，最核心的改进，就是把一个全局的大锁，改进成了 每个链表独立的一把小锁
这样做大幅度降低了锁冲突的概率
一个 hash 表，有很多这样的链表，两个线程恰好同时访问一个链表的情况，本身就比较少 - 充分利用到了 CAS 特性，把一些不必要加锁的环节给省略加锁了
比如，需要使用变量记录 hash 表中的元素个数
此时，就可以使用原子操作（CAS）修改元素个数 - ConcurrentHashMap 还有一个激进的操作，针对读操作没有加锁
读和读之间，读和写之间，都不会有锁竞争
那么是否会存在"读一半 修改了一半"的数值呢？
ConcurrentHashMap 在底层编码过程中，比较谨慎的处理了一些细节
修改的时候会避免使用 ++ -- 这种非原子的操作
使用 = 进行修改，本身就是原子的
读的时候，要么读的就是写之前的旧值，要么是读到写之后的心智，不会出现读到一个 一半的值
（写和写之间还是需要加锁的） - ConcurrentHashMap 针对扩容操作，做出了单独的优化
本身 Hashtable 或者 HashMap 在扩容的时候，都是需要把所有的元素都拷贝一遍（如果元素很多，拷贝就比较耗时）
比如，用户访问 1000 次，999 次都很流畅，其中一次就卡了（正好这一次触发扩容，导致出现卡顿）
ConcurrentHashMap 的优化方式就是"化整为零 "
一旦需要扩容，确实需要搬运，不是在一次操作中搬运完成，而是分成多次 来搬运
每次只搬运一部分数据，这样就可以避免这单次操作过于卡顿
ConcurrentHashMap 基本的使用方法和普通的 HashMap 完全一样
在第一点中，我们是怎么把每个链表单独加锁的呢？
其实就是把每个链表的头结点，作为锁对象
synchronized 可以使用任意对象作为锁对象
在这个时候，我们有的时候会提到分段锁
什么是分段锁呢？
在 java 8 之前， ConcurrentHashMap 就是基于分段锁的方式实现的
等到 java 8 开始之后，就成了直接在链表头结点，加锁的形式