阻塞队列--线程安全问题

阻塞队列--线程安全问题
之前的队列在很多场景下都不能很好地工作，例如
1. 大部分场景要求分离向队列放入（生产者：主要调用offer方法）、从队列拿出（消费者：主要调用poll方法）两个角色、它们得由不同的线程来担当，而之前的实现根本没有考虑线程安全问题
2. 队列为空，那么在之前的实现里会返回 null，如果就是硬要拿到一个元素呢？只能不断循环尝试
3. 队列为满，那么再之前的实现里会返回 false，如果就是硬要塞入一个元素呢？只能不断循环尝试
因此我们需要解决的问题有
1. 用锁保证线程安全
2. 用条件变量让等待非空线程与等待不满线程进入等待状态，而不是不断循环尝试，让 CPU 空转
有同学对线程安全还没有足够的认识，下面举一个反例，两个线程都要执行入队操作（几乎在同一时刻）
```
public class TestThreadUnsafe {
    private final String[] array = new String[10];
    private int tail = 0;
 
    public void offer(String e) {
        array[tail] = e;
        tail++;
    }
 
    @Override
    public String toString() {
        return Arrays.toString(array);
    }
 
    public static void main(String[] args) {
        TestThreadUnsafe queue = new TestThreadUnsafe();
        new Thread(()-> queue.offer("e1"), "t1").start();
        new Thread(()-> queue.offer("e2"), "t2").start();
    }
}
```
注意IDEA调试设置：

执行的时间序列如下，假设初始状态 tail = 0，在执行过程中由于 CPU 在两个线程之间切换，造成了指令交错

糟糕的是，由于指令交错的顺序不同，得到的结果不止以上一种，宏观上造成混乱的效果

单锁实现

Java 中要防止代码段交错执行，需要使用锁，有两种选择
- synchronized 代码块，属于关键字级别提供锁保护，功能少
- ReentrantLock（可重入锁）类，功能丰富
以 ReentrantLock 为例
```
ReentrantLock lock = new ReentrantLock();//锁对象
 
public void offer(String e) {
    //lock.lock();  //加锁
    lock.lockInterruptibly();//加锁 记得要抛异常
    try {
        array[tail] = e;
        tail++;
    } finally {  
        //利用try-finally:为了防止当我们try{}内有异常，那么我们的lock.unlock()解锁操作就没办法执行，所以我们要保证即使出现异常也要执行解锁操作
        lock.unlock();//解锁
    }
}
```
lock()与lockInterruptibly()的区别：

使用lock():当t1加锁状态，未解锁时，t2必须等待

使用lockInterruptibly()：当t1加锁状态，未解锁时，但t1处于异常导致无法解锁的时候，t2可以在阻塞状态下随时打断t1的锁

只要两个线程执行上段代码时，锁对象是同一个，就能保证 try 块内的代码的执行不会出现指令交错现象，即执行顺序只可能是下面两种情况之一
- 另一种情况是线程2 先获得锁，线程1 被挡在外面
- 要明白保护的本质，本例中是保护的是 tail 位置读写的安全
事情还没有完，上面的例子是队列还没有放满的情况，考虑下面的代码（这回锁同时保护了 tail 和 size 的读写安全）
```
ReentrantLock lock = new ReentrantLock();
int size = 0;//判断队列是否满了
 
public void offer(String e) {
    lock.lockInterruptibly();
    try {
        if(isFull()) {
            // 满了怎么办?
        }
        array[tail] = e;
        //tail++;
        //防止tail长度溢出
        if (++tail == array.length) {
                tail = 0;
        }
        size++;
    } finally {
        lock.unlock();
    }
}
 
private boolean isFull() {
    return size == array.length;
}
```
之前是返回 false 表示添加失败，前面分析过想达到这么一种效果：
- 在队列满时，不是立刻返回，而是当前线程进入等待
- 什么时候队列不满了，再唤醒这个等待的线程，从上次的代码处继续向下运行
ReentrantLock 可以配合条件变量来实现，代码进化为
```
ReentrantLock lock = new ReentrantLock();
Condition tailWaits = lock.newCondition(); // 条件变量
int size = 0;
 
public void offer(String e) {
    lock.lockInterruptibly();
    try {
        while (isFull()) {
            tailWaits.await();	// 当队列满时, 当前线程进入 tailWaits 等待,当前线程加入tailWaits,并且让此线程阻塞
        }
        array[tail] = e;
        //tail++;
        //防止tail长度溢出
        if (++tail == array.length) {
                tail = 0;
        }
        size++;
    } finally {
         //利用try-finally:为了防止当我们try{}内有异常，那么我们的lock.unlock()解锁操作就没办法执行，所以我们要保证即使出现异常也要执行解锁操作
        lock.unlock();
    }
}
 
private boolean isFull() {
    return size == array.length;
}
```
- 条件变量底层也是个队列，用来存储这些需要等待的线程，当队列满了，就会将 offer 线程加入条件队列，并暂时释放锁
- 将来我们的队列如果不满了（由 poll 线程那边得知）可以调用 tailWaits.signal() 来唤醒 tailWaits 中首个等待的线程，被唤醒的线程会再次抢到锁，从上次 await 处继续向下运行
思考为何要用 while 而不是 if，设队列容量是 3

关键点：
- 从 tailWaits 中唤醒的线程，会与新来的 offer 的线程争抢锁，谁能抢到是不一定的，如果后者先抢到，就会导致条件又发生变化
- 这种情况称之为虚假唤醒，唤醒后应该重新检查条件，看是不是得重新进入等待
最后的实现代码：

接口：
```
/**
 目前队列存在的问题
 
    
很多场景要求分离生产者、消费者两个角色、它们得由不同的线程来担当，而之前的实现根本没有考虑线程安全问题
```
队列为空，那么在之前的实现里会返回 null，如果就是硬要拿到一个元素呢？只能不断循环尝试

单锁实现

双锁实现