深入学习掌握JUC并发编程系列（六） -- 并发工具梳理-CSDN博客

本文链接：https://blog.csdn.net/snapepotter/article/details/126683937

深入学习掌握JUC并发编程系列（六） -- 并发工具梳理

一、自定义线程池
二、ThreadPoolExecutor
三、AQS原理
- 1. AQS概述
- 2. 使用AQS自定义锁（不可重入）
四、ReentrantLock原理
五、读写锁（ReentrantReadWriteLock）
六、信号量（Semaphore）
七、倒计时锁（CountdownLatch）
八、循环栅栏（CyclicBarrier）
九、线程安全集合类
十、ConcurrentHashMap
十一、LinkedBlockingQueue
十二、ConcurrentLinkedQueue
十三、CopyOnWriteArrayList

一、自定义线程池

步骤1：自定义拒绝策略接口 RejectPolicy（任务队列满时）

@FunctionalInterface
interface RejectPolicy<T> {
    void reject(BlockingQueue<T> queue, T task);
}

步骤2：自定义任务队列 BlockingQueue

@Slf4j(topic = "c.BlockingQueue")
class BlockingQueue<T> {
    // 1. 任务队列
    private Deque<T> queue = new ArrayDeque<>();
 
    // 2. 锁
    private ReentrantLock lock = new ReentrantLock();
 
    // 3. 生产者条件变量
    private Condition fullWaitSet = lock.newCondition();
 
    // 4. 消费者条件变量
    private Condition emptyWaitSet = lock.newCondition();
 
    // 5. 容量
    private int capcity;
 
    public BlockingQueue(int capcity) {
        log.info("构造BlockingQueue");
        this.capcity = capcity;
    }
 
    // 带超时阻塞获取
    public T poll(long timeout, TimeUnit unit) {
        lock.lock();
        try {
            // 将 timeout 统一转换为 纳秒
            long nanos = unit.toNanos(timeout);
            while (queue.isEmpty()) {
                try {
                    // 返回值是剩余时间
                    if (nanos <= 0) {
                        return null;
                    }
                    nanos = emptyWaitSet.awaitNanos(nanos);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            T t = queue.removeFirst();
            fullWaitSet.signal();
            return t;
        } finally {
            lock.unlock();
        }
    }
 
    // 阻塞获取
    public T take() {
        lock.lock();
        try {
            while (queue.isEmpty()) {
                try {
                    emptyWaitSet.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            T t = queue.removeFirst();
            fullWaitSet.signal();
            return t;
        } finally {
            lock.unlock();
        }
    }
 
    // 阻塞添加
    public void put(T task) {
        lock.lock();
        try {
            while (queue.size() == capcity) {
                try {
                    log.debug("等待加入任务队列 {} ...", task);
                    fullWaitSet.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            log.debug("加入任务队列 {}", task);
            queue.addLast(task);
            emptyWaitSet.signal();
        } finally {
            lock.unlock();
        }
    }
 
    // 带超时时间阻塞添加
    public boolean offer(T task, long timeout, TimeUnit timeUnit) {
        lock.lock();
        try {
            long nanos = timeUnit.toNanos(timeout);
            while (queue.size() == capcity) {
                try {
                    if(nanos <= 0) {
                        return false;
                    }
                    log.debug("等待加入任务队列 {} ...", task);
                    nanos = fullWaitSet.awaitNanos(nanos);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            log.debug("加入任务队列 {}", task);
            queue.addLast(task);
            emptyWaitSet.signal();
            return true;
        } finally {
            lock.unlock();
        }
    }
 
    // 获取阻塞队列大小
    public int size() {
        lock.lock();
        try {
            return queue.size();
        } finally {
            lock.unlock();
        }
    }
    // 队列满时的拒绝策略
    public void tryPut(RejectPolicy<T> rejectPolicy, T task) {
        lock.lock();
        try {
            // 判断队列是否满
            if(queue.size() == capcity) {
                log.info("队列已满,按照拒绝策略处理任务 {}",task);
                rejectPolicy.reject(this, task);
            } else {  // 有空闲
                log.debug("队列未满,加入任务队列 {}", task);
                queue.addLast(task);
                emptyWaitSet.signal();
            }
        } finally {
            lock.unlock();
        }
    }
 
}

步骤3：自定义线程池 ThreadPool

@Slf4j(topic = "c.ThreadPool")
class ThreadPool {
    // 任务队列
    private BlockingQueue<Runnable> taskQueue;
 
    // 线程集合
    private HashSet<Worker> workers = new HashSet<>();
 
    // 核心线程数
    private int coreSize;
 
    // 获取任务时的超时时间
    private long timeout;
    private TimeUnit timeUnit;
 
    //拒绝策略
    private RejectPolicy<Runnable> rejectPolicy;
 
    // 执行任务
    public void execute(Runnable task) {
        log.info("接收到任务需要执行: "+task);
        // 当任务数没有超过 coreSize 时，直接交给 worker 对象执行
        // 如果任务数超过 coreSize 时，加入任务队列暂存
        synchronized (workers) {
            if(workers.size() < coreSize) {
                log.info("coreSize未满");
                Worker worker = new Worker(task);
                log.debug("新增 worker  {} 来执行任务 {}", worker, task);
                workers.add(worker);
                worker.start();
            } else {
                log.info("coreSize已经满了!!!!,尝试先将任务放入队列 {}",task);
//                taskQueue.put(task);
                // 1) 死等
                // 2) 带超时等待
                // 3) 让调用者放弃任务执行
                // 4) 让调用者抛出异常
                // 5) 让调用者自己执行任务
                taskQueue.tryPut(rejectPolicy, task);
            }
        }
    }
 
    public ThreadPool(int coreSize, long timeout, TimeUnit timeUnit, int queueCapcity, RejectPolicy<Runnable> rejectPolicy) {
        log.info("构造ThreadPool");
        this.coreSize = coreSize;
        this.timeout = timeout;
        this.timeUnit = timeUnit;
        this.taskQueue = new BlockingQueue<>(queueCapcity);
        this.rejectPolicy = rejectPolicy;
    }
 
    // 工作线程    
    class Worker extends Thread{
        // 执行任务主体
        private Runnable task;
        public Worker(Runnable task) {
            this.task = task;
        }
        // 执行已有任务或从队列中获取一个任务执行.
        // 如果都执行完了,就结束线程
        @Override
        public void run() {
            log.info("跑起来了,让我看看有没有task来做");
            // 执行任务
            // 1) 当 task 不为空，执行任务
            // 2) 当 task 执行完毕，再接着从任务队列获取任务并执行
//            while(task != null || (task = taskQueue.take()) != null) {
            while(task != null || (task = taskQueue.poll(timeout, timeUnit)) != null) {
                try {
                    log.debug("获取到任务了,正在执行...{}", task);
                    task.run();
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    log.info("搞定一个任务 {},尝试获取新任务执行",task);
                    task = null;
                }
            }
            synchronized (workers) {
                log.debug("worker 因长时间没有可执行任务 将被释放 {}", this);
                workers.remove(this);
            }
 
        }
    }
}

步骤4 ：测试

@Slf4j(topic = "c.TestCustomThreadPool")
public class TestCustomThreadPool {
    public static void main(String[] args) {
        ThreadPool threadPool = new ThreadPool(1,3000, TimeUnit.MILLISECONDS, 1,
(queue, task)->{
            // 1. 死等
//            queue.put(task);
            // 2) 带超时等待
//            queue.offer(task, 1500, TimeUnit.MILLISECONDS);
            // 3) 让调用者放弃任务执行
//            log.debug("放弃{}", task);
            // 4) 让调用者抛出异常
//            throw new RuntimeException("任务执行失败 " + task);
            // 5) 让调用者自己执行任务
            log.info("当前拒绝策略: 让调用者自己执行任务,没有开新线程,直接调用的run()");
            task.run();
        });
        for (int i = 0; i < 4; i++) {
            int j = i;
            threadPool.execute(() -> {
                try {
                    log.info("我先睡1s");
                    Thread.sleep(1000L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                log.debug("我是第 {} 个任务,我马上执行完了", j);
            });
        }
    }
}

二、ThreadPoolExecutor

1. 线程池状态

线程池状态信息存储在一个原子变量 ctl 中
使用一个int （ctl）的高 3 位表示线程池状态，低 29 位表示线程数量
TERMINATED > TIDYING > STOP > SHUTDOWN > RUNNING（第一位是符号位，RUNNING 是负数，所以最小）
原子变量ctl：将线程池状态与线程个数合二为一，可以用一次 cas 原子操作进行赋值

// c 为旧值， ctlOf 返回结果为新值
ctl.compareAndSet(c, ctlOf(targetState, workerCountOf(c))));
// rs 为高 3 位代表线程池状态， wc 为低 29 位代表线程个数，ctl 是合并它们
private static int ctlOf(int rs, int wc) { return rs | wc; }

2. 构造方法

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                         RejectedExecutionHandler handler)

参数：
- corePoolSize：核心线程数目 (最多保留的线程数)
- maximumPoolSize：最大线程数目（= 核心线程数 + 救急线程数）
- keepAliveTime：生存时间（救急线程）
- unit：生存时间的时间单位（救急线程）
- workQueue：阻塞队列
- threadFactory：线程工厂（可以为线程创建时起个好名字）
- handler：拒绝策略
阻塞队列
- 有界：当任务超过了队列大小，会创建 maximumPoolSize - corePoolSize 数目的救急线程执行任务
- 无界：没有救急线程
救急线程：与核心线程相比，存在，由参数生存时间以及时间单位决定
线程数超过 maximumPoolSize：执行拒绝策略
拒绝策略（ jdk 提供的 4 种实现，以及其它框架提供的实现）：
- AbortPolicy：让调用者抛出 RejectedExecutionException 异常（默认策略）
- CallerRunsPolicy：让调用者运行任务
- DiscardPolicy：放弃本次任务
- DiscardOldestPolicy：放弃队列中最早的任务，当前任务取而代之
- Dubbo 实现：在抛出 RejectedExecutionException 异常之前会记录日志，并 dump 线程栈信息，方便定位问题
- Netty 实现：创建一个新线程来执行任务
- ActiveMQ 实现：带超时等待（60s），尝试放入队列（类似之前自定义的拒绝策略）
- PinPoint 实现：使用一个拒绝策略链，逐一尝试策略链中每种拒绝策略

3. JDK Executors类中提供的工厂方法-创建线程池

newFixedThreadPool：固定线程数
- 核心线程数 == 最大线程数（没有救急线程，存活时间为0）
- 阻塞队列无界，可以放任意数量的任务
- 适用：任务数已知，任务相对耗时

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

newCachedThreadPool：缓冲线程
- 没有核心线程，全是救急线程（存活时间60s）
- 救急线程可以随着任务数增加，无限创建
- SynchronizedQueue：没有容量，没有线程取任务，任务放不进队列（一手交钱一手交货）
- 适用：任务数比较密集，任务执行时间较短

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>());
}

newSingleThreadExecutor：单个线程
- 只有1个核心线程，阻塞队列无界
- 适用：多个任务排队按顺序执行（串行），多余线程在阻塞队列（无界）等待
- 区别：
  - 自己创建1个线程：如果任务执行失败而终止（没有任何补救措施），线程池会再新建一个线程，保证线程池正常工作
  - newFixedThreadPool(1)：初始为1，以后可以修改，对外暴露的是ThreadPoolExecutor 对象，可以强转后调用 setCorePoolSize 等方法进行修改
  - newSingleThreadExecutor：始终为1，不可修改，只对外暴露了 ExecutorService 接口，不能调用 ThreadPoolExecutor 中特有的方法

public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService               //装饰器模式
        (new ThreadPoolExecutor(1, 1,
                                0L, TimeUnit.MILLISECONDS,
                                new LinkedBlockingQueue<Runnable>()));
}

4. 提交任务的方法

// 执行任务
void execute(Runnable command);
 
// 提交任务 task，用返回值 Future 获得任务执行结果
<T> Future<T> submit(Callable<T> task);
 
// 提交 tasks 中所有任务
<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks)
    throws InterruptedException;
 
// 提交 tasks 中所有任务，带超时时间
<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks,
                              long timeout, TimeUnit unit)
    throws InterruptedException;
 
// 提交 tasks 中所有任务，哪个任务先成功执行完毕，返回此任务执行结果，其它任务取消
<T> T invokeAny(Collection<? extends Callable<T>> tasks)
    throws InterruptedException, ExecutionException;
 
// 提交 tasks 中所有任务，哪个任务先成功执行完毕，返回此任务执行结果，其它任务取消，带超时时间
<T> T invokeAny(Collection<? extends Callable<T>> tasks,
                long timeout, TimeUnit unit)
 throws InterruptedException, ExecutionException, TimeoutException;

5. 关闭线程池的方法

shutdown()：线程池状态变为 SHUTDOWN：void shutdown();
- 不会接收新任务
- 阻塞队列中的已提交任务会执行完
- 用interrupt方法打断空闲的线程
- 不会阻塞调用线程的执行
shutdownNow()：线程池状态变为STOP：List<Runnable> shutdownNow();
- 不会接收新任务
- 将阻塞队列中的任务返回（List）
- 用interrupt方法打断正在执行任务的线程（所有线程）
其它方法：

// 不是 RUNNING 状态的线程池，此方法就返回 true
boolean isShutdown();
 
// 线程池状态是否是 TERMINATED
boolean isTerminated();
 
// 调用 shutdown 后，调用线程不会等待所有任务运行结束，因此如果想在线程池 TERMINATED 后做些事情，可以利用此方法等待
boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException;

三、AQS原理

1. AQS概述

全称：AQS（AbstractQueuedSynchronizer 抽象队列同步器）
定义：构建阻塞式锁和同步器的框架，（抽象类）在Java.util.concurrent.locks包下面
特点：
- state 属性：表示资源状态（独占模式和共享模式）
  - getState - 获取 state 状态
  - setState - 设置 state 状态
  - compareAndSetState - cas 机制设置 state 状态
  - 独占模式：只有一个线程能够访问资源
  - 共享模式：可以允许多个线程访问资源（可以设置上限）
  - 子类需要定义如何维护state属性（资源状态），来控制如何获取锁和释放锁
- 等待队列：基于 FIFO 的队列（类似 Monitor 的 EntryList）
- 条件变量：实现等待、唤醒机制，支持多个条件变量（类似 Monitor 的 WaitSet）
使用：继承AQS父类
- 子类需要实现（重写）方法：（默认抛出 UnsupportedOperationException）tryAcquire、tryRelease、tryAcquireShared、tryReleaseShared、isHeldExclusively
- 获取锁：if (!tryAcquire(arg)) { // 获取锁失败，入队, 可以选择阻塞当前线程（park/unpark） }
- 释放锁：if (tryRelease(arg)) { // 释放锁成功，让阻塞线程恢复运行}

2. 使用AQS自定义锁（不可重入）

继承AQS，自定义同步器类，实现独占锁

final class MySync extends AbstractQueuedSynchronizer {   
    @Override
    protected boolean tryAcquire(int acquires) {
        if (acquires == 1){
            if (compareAndSetState(0, 1)) {
                setExclusiveOwnerThread(Thread.currentThread());   //设置owner为当前线程
                return true;
            }
        }
        return false;
    }   
    @Override
    protected boolean tryRelease(int acquires) {
        if(acquires == 1) {
            if(getState() == 0) {
                throw new IllegalMonitorStateException();
            }
            setExclusiveOwnerThread(null);
            setState(0);
            return true;
        }
        return false;
    }   
    protected Condition newCondition() {
        return new ConditionObject();
    }   
    @Override      //是否持有独占锁
    protected boolean isHeldExclusively() {
        return getState() == 1;
    }
}

自定义锁，调用同步器类中的方法

class MyLock implements Lock {   
    static MySync sync = new MySync();   
    @Override
    // 尝试，不成功，进入等待队列
    public void lock() {
        sync.acquire(1);
    }   
    @Override
    // 尝试，不成功，进入等待队列，可打断
    public void lockInterruptibly() throws InterruptedException {
        sync.acquireInterruptibly(1);
    }   
    @Override
    // 尝试一次，不成功返回，不进入队列
    public boolean tryLock() {
        return sync.tryAcquire(1);
    }   
    @Override
    // 尝试，不成功，进入等待队列，有时限
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
        return sync.tryAcquireNanos(1, unit.toNanos(time));
    }   
    @Override
    // 释放锁
    public void unlock() {
        sync.release(1);
    }   
    @Override
    // 生成条件变量
    public Condition newCondition() {
        return sync.newCondition();
    }
}

四、ReentrantLock原理

1. 非公平锁实现原理

构造器默认非公平锁 public ReentrantLock() {sync = new NonfairSync();}
加锁解锁流程：
- 加锁没有竞争时，Thread-0成功拥有锁，compareAndSetState(0，1)成功
- 加锁有竞争时：Thread-1竞争（四次尝试获取锁）
  - CAS 尝试将 state 由 0 改为 1，结果失败
  - 进入 tryAcquire 逻辑， state 仍然是 1，结果失败
  - 进入 addWaiter 逻辑，构造 Node 队列（双向链表），Node 的创建是懒惰的
  - 黄色三角：该 Node 的 waitStatus 状态（0 为默认正常状态）
  - 第一个 Node 称为 Dummy（哑元）或哨兵，用来占位并不关联线程，第一次创建两个节点
  - 进入 acquireQueued 逻辑，acquireQueued 会在一个死循环中不断尝试获得锁，失败后进入 park 阻塞
  - 如果线程是紧邻着 head（排第二位），那么会再次 tryAcquire 尝试获取锁，这时 state 仍为 1，失败
  - 进入 shouldParkAfterFailedAcquire 逻辑，将前驱节点（head）的 waitStatus 改为 -1（-1：有责任唤醒后继节点），返回 false，回到acquireQueued继续循环
  - Thread-1 再次 tryAcquire 尝试获取锁，这时state 仍为 1，失败
  - 再次进入 shouldParkAfterFailedAcquire ，这时其前驱节点的 waitStatus 已经是 -1，这次返回true
  - 进入 parkAndCheckInterrupt， park阻塞 Thread-1 （灰色表示）
多个线程竞争失败后
- 解锁：Thread-0 释放锁
  - 进入 tryRelease 流程，成功，设置 exclusiveOwnerThread 为 null，state = 0
  - 当前队列不为 null，并且 head 的 waitStatus = -1
  - 进入 unparkSuccessor 流程，找到队列中离 head 最近的一个 Node（Thread-1），unpark 恢复其运行，
  - 回到 Thread-1 的 acquireQueued 流程
  - Thread-1加锁成功（没有竞争）：
    - 设置 exclusiveOwnerThread 为 Thread-1，state = 1
    - head 指向之前 Thread-1 所在的 Node，该 Node 清空 Thread
    - 原本的 head 从链表断开，被垃圾回收
  - Thread-1加锁失败（有其它线程Thread-4来竞争）：非公平的体现
    - Thread-4 被设置为 exclusiveOwnerThread，state = 1
    - Thread-1 再次进入 acquireQueued 流程，获取锁失败，重新进入 park 阻塞

2. 可重入原理

加锁时：判断 current == getExclusiveOwnerThread() ，为 True 则将 state++
解锁时：将 state–，直到 state为 0，才能释放锁

3. 可打断原理

不可打断（默认）：即使被打断，仍然会留在 AQS 队列中，一直要等到获得锁后才能得知自己被打断了（不抛出异常，只会重置打断标记）
可打断：在 park 过程中如果被 interrupt打断，会抛出异常，而不会再次进入 for (;😉 循环获得锁

4. 公平锁原理

不公平：直接尝试用 cas 获得锁，不检查AQS等待队列
公平：tryAcquire 方法中，在 cas 获得锁之前，先检查 AQS 队列中是否有前驱节点，没有才去竞争

5. 条件变量实现原理

每个条件变量对应着一个等待队列（实现类：ConditionObject）
await 流程：Thread-0 持有锁，调用 await()方法，进入等待队列
- 进入 ConditionObject 的 addConditionWaiter 流程
- 创建新的 Node 状态为 -2（Node.CONDITION），关联 Thread-0，加入等待队列尾部
- 进入 AQS 的 fullyRelease 流程，释放同步器上的锁（state = 0）
- unpark AQS 队列中的下一个节点(Thread-1)，没有其它线程竞争， Thread-1 加锁成功
- park 阻塞 Thread-0（灰色）
signal 流程：Thread-1 调用 signal()方法，唤醒 Thread-0
- 进入 ConditionObject 的 doSignal 流程
- 取得等待队列中第一个 Node（Thread-0）
- 执行 transferForSignal 流程，将该 Node （Thread-0）加入 AQS 队列尾部
- 将 Thread-0 的 waitStatus 改为 0，Thread-3 的waitStatus 改为 -1

五、读写锁（ReentrantReadWriteLock）

ReentrantReadWriteLock：支持重入的读写锁
适用：读操作远远高于写操作时，使用读写锁让读-读可以并发，提高性能
读-读并发，读-写和写-写互斥（阻塞）
注意事项：
- 读锁不支持条件变量，写锁支持
- 重入时，不支持升级（有读锁时，不能再获取写锁）
- 重入时，支持降级（有写锁时，可以获取读锁）

六、信号量（Semaphore）

用途：限制同时访问共享资源的线程上限（上锁：只有1个线程可以访问共享资源）
适用：限制单机线程数量（不是限制资源数），使用 Semaphore 限流，在访问高峰期时，让请求线程阻塞，高峰期过去再释放许可（数据库连接池）
加锁解锁流程：内部维护同步器继承自AQS（state=1：加锁）
- 开始加锁：permits（state）为 3（构造器默认）
- 模拟 5 个线程获取资源
- 假设其中 Thread-1，Thread-2，Thread-4 cas 竞争成功（state减为0），所以Thread-0 和 Thread-3 竞争失败，进入 AQS 队列 park 阻塞
- 开始解锁：Thread-4 释放了 permits，state加1
- Thread-0 竞争成功，permits 再次设置为 0
- Thread-0设置自己为 head 节点，断开原来的 head 节点
- unpark 接下来的 Thread-3 节点(依次唤醒后续所有节点），但由于 permits 是 0，因此 Thread-3 在尝试不成功后再次进入 park 状态

七、倒计时锁（CountdownLatch）

用途：线程同步协作，等待所有线程完成倒计时
构造参数初始化等待计数值：内部维护同步器继承自AQS
- await()：等待计数归零
- countDown() ：让计数减一
join()是等待线程结束，CountDownLatch不会（配合线程池使用，lol游戏加载界面）
不能被重用，不能修改计数值

八、循环栅栏（CyclicBarrier）

用途：线程协作，等待线程满足某个计数
构造时设置计数个数：
- await() ：线程调用后同步等待，计数减一
- 计数减为0后，所有调用await线程恢复执行
- 构造时还可以设置汇总任务：Runnable barrierAction（等待所有线程执行完后，再执行）
与CountDownLatch相比：
- 相同：用于线程协作，线程等待完成计数再执行
- 不同：
  - CountDownLatch不可重用，计数值不能修改
  - CyclicBarrier可以重用，计数可以恢复至初始值

九、线程安全集合类

遗留的安全集合（使用synchronized修饰，并发度低）：Hashtable（map）、Vector（list）
修饰的安全集合（使用Collections修饰，装饰器模式）：SynchronizedMap、SynchronizedList
JUC包下的安全集合：
- Blocking类（阻塞队列）：实现基于锁（reentrantlock），提供阻塞方法
- CopyOnWrite类（读多写少）：在修改（写）时，使用拷贝的方式，避免多线程读写时的并发安全
- Concurrent类：
  - 优点：内部使用 cas 优化，可以提供较高吞吐量（高并发度）
  - 缺点：弱一致性
    - 遍历时弱一致性（例如：当利用迭代器遍历时，如果容器发生修改，迭代器仍然可以继续进行遍历，这时内容是旧的）
    - 求大小时弱一致性（size 操作未必是 100% 准确）
    - 读取时弱一致性
集合的每个方法是线程安全的，方法的组合不是线程安全的
非安全容器：遍历时如果发生了修改，使用 fail-fast 机制（让遍历立刻失败，抛出ConcurrentModifificationException，不再继续遍历）

十、ConcurrentHashMap

computeIfAbsent()：如果缺少一个key，则计算生成一个value，然后将key、value存入map中（保证get()、put()方法组合的原子性）

1. HashMap 扩容问题

JDK7下的 HashMap 在多线程扩容时（元素个数超过容量的3/4）存在并发死链问题
- JDK7下的 HashMap 同一桶下标，新元素存放在链表的头部（头插法）
- 线程1完成扩容，改变了链表结构（翻转），而线程0还没有扩容，它的链表的结点已经因为扩容发生了变化，再扩容的时候就会不一致
JDK 8 虽然将扩容算法做了调整（将元素加入链表尾部：尾插法），但仍不意味着能够在多线程环境下安全扩容，还会出现其它问题（如扩容丢数据）

2. JDK 8 ConcurrentHashMap

重要属性和内部类：

// 默认为 0
// 当初始化时, 为 -1
// 当扩容时, 为 -(1 + 扩容线程数)
// 当初始化或扩容完成后，为 下一次的扩容的阈值大小
private transient volatile int sizeCtl;
 
// 整个 ConcurrentHashMap 就是一个 Node[]
static class Node<K,V> implements Map.Entry<K,V> {}
 
// hash 表    node数组
transient volatile Node<K,V>[] table;
 
// 扩容时的 新 hash 表
private transient volatile Node<K,V>[] nextTable;
 
// 扩容时如果某个 bin 迁移完毕, 用 ForwardingNode（-1） 作为旧 table bin 的头结点
static final class ForwardingNode<K,V> extends Node<K,V> {}
 
// 用在 compute 以及 computeIfAbsent 时, 用来占位, 计算完成后替换为普通 Node
static final class ReservationNode<K,V> extends Node<K,V> {}
 
// 作为 treebin  的头节点, 存储 root 和 first  
static final class TreeBin<K,V> extends Node<K,V> {}
 
// 作为 treebin 的节点, 存储 parent, left, right
static final class TreeNode<K,V> extends Node<K,V> {}
 
// treebin（-2）：在hashmap容量扩容至64后，且链表长度超过8后，会将链表数据结构转换为红黑树

重要方法：

// 获取 Node[] 中第 i 个 Node
static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i)
 
// cas 修改 Node[] 中第 i 个 Node 的值, c 为旧值, v 为新值
static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i, Node<K,V> c, Node<K,V> v)
 
// 直接修改 Node[] 中第 i 个 Node 的值, v 为新值
static final <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v)

构造器分析：懒惰初始化（在构造方法中仅计算了 table 的大小，在第一次使用时才会真正创建）
- initialCapacity：初始大小（大于等于并发度）
- loadFactor：扩容阈值（3/4）
- concurrencyLevel：并发度

public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
    if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
        throw new IllegalArgumentException();
    if (initialCapacity < concurrencyLevel)      // Use at least as many bins
        initialCapacity = concurrencyLevel;      // as estimated threads
    long size = (long)(1.0 + (long)initialCapacity / loadFactor);
    // tableSizeFor 保证计算的大小是 2^n, 即 16,32,64 ...
    int cap = (size >= (long)MAXIMUM_CAPACITY) ?
        MAXIMUM_CAPACITY : tableSizeFor((int)size);
    this.sizeCtl = cap;
}

get 流程：流程中未加锁，并发度高

public V get(Object key) {
    Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
    // spread 方法能确保返回结果是正整数
    int h = spread(key.hashCode());
    if ((tab = table) != null && (n = tab.length) > 0 &&
        (e = tabAt(tab, (n - 1) & h)) != null) {
        // 如果头结点已经是要查找的 key
        if ((eh = e.hash) == h) {
            if ((ek = e.key) == key || (ek != null && key.equals(ek)))
                return e.val;
        }
        // hash 为负数表示该 bin 在扩容中（-1）或是 treebin（-2）, 这时调用 find 方法来查找
        else if (eh < 0)
            return (p = e.find(h, key)) != null ? p.val : null;
        // 正常遍历链表, 用 equals 比较
        while ((e = e.next) != null) {
            if (e.hash == h &&
                ((ek = e.key) == key || (ek != null && key.equals(ek))))
                return e.val;
        }
    }
    return null;
}

put 流程：新值覆盖旧值，不允许有空的键值，检查ForwardingNode帮忙扩容
size计算流程：发生在 put，remove 改变集合元素的操作之中
- 没有竞争发生，向 baseCount 累加计数
- 有竞争发生，新建 counterCells，向其中的一个 cell 累加计数（类似 longadder）
  - counterCells 初始有两个 cell
  - 计数竞争比较激烈，会创建新的 cell 来累加计数
Java 8 总结：数组 +（链表 Node | 红黑树TreeNode），数组简称（table）、链表简称（bin）
- 初始化（initTable）：使用 cas 来保证并发安全，懒惰初始化 table
- 树化：当 table.length < 64 时，先尝试扩容，超过 64，并且 bin.length > 8 时，会将链表树化，树化过程会用 synchronized 锁住链表头
- put：
  - bin 尚未创建：使用 cas 创建
  - bin 已经创建：锁住链表头进行 put 操作（元素添加至链表尾部）
- get：无锁操作，仅需要保证可见性，扩容过程中遇到 ForwardingNode，会在新 table 进行搜索
- 扩容（transfer）：以 bin 为单位（对 bin 进行 synchronized），其它竞争线程会帮助把其它 bin 进行扩容，扩容时平均只有 1/6 的节点会被复制到新 table 中
- size：元素个数保存在 baseCount 中，并发时的个数变动保存在 CounterCell[] 中，最后统计数量时累加

3. JDK 7 ConcurrentHashMap

内部维护了一个 segment（分段）数组，每个 segment 对应一把锁（继承自reentrantlock）
- 优点：多个线程访问不同的 segment时，锁住的是不同对象，没有冲突（与 jdk8 类似，锁住链表头）
- 缺点：
  - Segments 数组默认大小为16，容量初始化后不能改变
  - 不是懒惰初始化
构造器分析：
- 初始化时，创建Segments数组（16）和第一个元素（segments[0]）
- 每个segment数组元素都是一个 HashEntry数组（HashTable）
- this.segmentShift 和 this.segmentMask：决定将 key 的 hash 结果匹配到哪个segment

  // segmentShift 默认是 32 - 4 = 28
    this.segmentShift = 32 - sshift;
    // segmentMask 默认是 15 即 0000 0000 0000 1111
    this.segmentMask = ssize - 1;
    // 创建 segments and segments[0]
    Segment<K,V> s0 =
        new Segment<K,V>(loadFactor, (int)(cap * loadFactor),
                         (HashEntry<K,V>[])new HashEntry[cap]);
    Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
    UNSAFE.putOrderedObject(ss, SBASE, s0);      // ordered write of segments[0]
    this.segments = ss;
}

put流程：最终进入segment的put流程

  // 获得 segment 对象, 判断是否为 null, 是则创建该 segment
    if ((s = (Segment<K,V>)UNSAFE.getObject
         (segments, (j << SSHIFT) + SBASE)) == null) {
        // 这时不能确定是否真的为 null, 因为其它线程也发现该 segment 为 null,
        // 因此在 ensureSegment 里用 cas 方式保证该 segment 安全性
        s = ensureSegment(j);
    }
    // 进入 segment 的put 流程
    return s.put(key, hash, value, false);
}

segment 的 put方法（segment继承了可重入锁 ReentrantLock）

final V put(K key, int hash, V value, boolean onlyIfAbsent) {
    // 尝试加锁
    HashEntry<K,V> node = tryLock() ? null :
    // 如果不成功, 进入 scanAndLockForPut 流程
    // 如果是多核 cpu 最多 tryLock 64 次, 进入 lock 流程
    // 在尝试期间, 还可以顺便看该节点在链表中有没有, 如果没有顺便创建出来
    scanAndLockForPut(key, hash, value);
   
    // 执行到这里 segment 已经被成功加锁, 可以安全执行
    V oldValue;
    try {
 
    } finally {
        unlock();
    }
    return oldValue;
}

扩容 rehash 流程：发生在 put 中，此时已经获得了锁，因此 rehash 时不需要考虑线程安全
get 流程：
- 未加锁，用了 UNSAFE 方法保证可见性
- 扩容过程中，get 先发生从旧表取内容，get 后发生从新表取内容
size 流程（弱一致性）：计算元素个数前，先不加锁计算两次
- 前后两次结果一样，认为个数正确返回
- 前后不一样，进行重试，重试次数超过 3，将所有 segment 锁住，重新计算个数返回

十一、LinkedBlockingQueue

数据结构：Node（item，next）

public class LinkedBlockingQueue<E> extends AbstractQueue<E>
    implements BlockingQueue<E>, java.io.Serializable {
    static class Node<E> {
        E item;
        /**
        * next是下列三种情况之一
        * - 真正的后继节点
        * - 自己, 发生在出队时
        * - null, 表示是没有后继节点, 是最后了
        */
        Node<E> next;
        Node(E x) { item = x; }
    }
}

入队：
- 初始化链表：last = head = new Node(null)，Dummy 节点用来占位，item 为 null
- 当一个节点入队：last = last.next = node
- 再来一个节点入队：last = last.next = node
出队：

Node<E> h = head;
Node<E> first = h.next;
h.next = h; // help GC
head = first;
E x = first.item;
first.item = null;
return x;

h = head
first = h.next
h.next = h（帮助垃圾回收Dummy节点）
head = first

E x = first.item;
first.item = null;
return x;

加锁分析：用了两把锁（队列头尾上锁）和 Dummy节点
- 用一把锁，同一时刻，最多只允许有一个线程（生产者或消费者，二选一）执行
- 用两把锁，同一时刻，可以允许两个线程同时（一个生产者与一个消费者）执行
  - 消费者与消费者线程仍然串行
  - 生产者与生产者线程仍然串行
- 当节点总数大于 2 时（包括 dummy）：putLock 保证 last 节点的线程安全，takeLock 保证 head 节点的线程安全（两把锁保证了入队和出队没有竞争）
- 当节点总数等于 2 时（一个 dummy，一个正常节点）：两把锁锁着两个对象，不会竞争
- 当节点总数等于 1 时（只有dummy ）： take 线程会被 notEmpty 条件阻塞，有竞争，会阻塞

// 用于 put(入队阻塞) offer(非阻塞)
private final ReentrantLock putLock = new ReentrantLock();
// 用户 take(出队阻塞) poll(非阻塞)
private final ReentrantLock takeLock = new ReentrantLock();

put操作：（take类似）

public void put(E e) throws InterruptedException {
    if (e == null) throw new NullPointerException();   //不允许有空元素
    int c = -1;
    Node<E> node = new Node<E>(e);
    final ReentrantLock putLock = this.putLock;
    // count 用来维护元素计数
    final AtomicInteger count = this.count;
    putLock.lockInterruptibly();
    try {
        // 满了等待
        while (count.get() == capacity) {
            // 倒过来读就好: 等待 notFull
            notFull.await();
        }
        // 有空位, 入队且计数加一
        enqueue(node);
        c = count.getAndIncrement();
        // 除了自己 put 以外, 队列还有空位, 由自己叫醒其他 put 线程
        if (c + 1 < capacity)
            notFull.signal();
    } finally {
        putLock.unlock();
    }
    // 如果队列中有一个元素, 叫醒 take 线程
    if (c == 0)
        // 这里调用的是 notEmpty.signal() 而不是 notEmpty.signalAll() 是为了减少竞争
        signalNotEmpty();
}

LinkedBlockingQueue 与 ArrayBlockingQueue 的性能比较：
- Linked 支持有界，Array 强制有界
- Linked 实现是链表，Array 实现是数组
- Linked 是懒惰的，而 Array 需要提前初始化 Node 数组
- Linked 每次入队会生成新 Node，而 Array 的 Node 是提前创建好的
- Linked 两把锁，Array 一把锁

十二、ConcurrentLinkedQueue

与 LinkedBlockingQueue 设计非常像：
- 两把锁，同一时刻，可以允许两个线程同时（一个生产者与一个消费者）执行
- 加入dummy 节点：让两把锁锁住的是不同对象，避免竞争
不同点：锁使用 cas 来实现（无阻塞），不是真正的锁

十三、CopyOnWriteArrayList

CopyOnWriteArraySet内部用的都是CopyOnWriteArrayList方法，除了add()方法（调用addIfAbsent保证set的元素唯一性）
CopyOnWrite：
- 写入时拷贝：增删改操作会将底层数组拷贝一份，更改操作在新数组上执行，不影响其它线程的并发读，将读写分离
- 读-读和读-写并发，写-写互斥（阻塞）（读写锁 ReentrantReadWriteLock 只能读-读并发）
- 写操作加锁，读操作不加锁（适合读多写少）
增操作：JDK 8 中使用的是可重入锁（不是 synchronized）

public boolean add(E e) {
    synchronized (lock) {
        // 获取旧的数组
        Object[] es = getArray();
        int len = es.length;
        // 拷贝新的数组（这里是比较耗时的操作，但不影响其它读线程）
        es = Arrays.copyOf(es, len + 1);
        // 添加新元素
        es[len] = e;
        // 替换旧的数组
        setArray(es);
        return true;
    }
}