- 在Leader-follower线程模型中每个线程有三种模式，leader,follower, processing。
- 在Leader-follower线程模型一开始会创建一个线程池，并且会选取一个线程作为leader线程，leader线程负责监听网络请求，其它线程为follower处于waiting状态，当leader线程接受到一个请求后，会释放自己作为leader的权利，然后从follower线程中选择一个线程进行激活，然后激活的线程被选择为新的leader线程作为服务监听，然后老的leader则负责处理自己接受到的请求（现在老的leader线程状态变为了processing），处理完成后，状态从processing转换为。follower
可知这种模式下接受请求和进行处理使用的是同一个线程，这避免了线程上下文切换和线程通讯数据拷贝。
接下来看DelayQueue采用的Leader-Follower模式：
饭店不分角色，都是员工，但是改变了经营策略，每个客人必须预约吃饭时间，预约采用APP预约。因为加入了延时，逻辑变得复杂了一些。
- 每次还是只能有一个员工在门口等待，比如A先在门口等待，A看了眼预约登记表，发现离预约最早到店的时间还有30分钟，A就什么都不干了，先休息30分钟。
- 其他员工还是先在屋里歇着，但是因为采用APP预约，客人约几点都有可能，如果此时有客人约的是10分钟后到店，因为A要30分钟后才能醒来干活，所以如果这位客人来了，门口就没有人接待了。
- 对于这个问题，饭店的软件系统在监听到最早到店时间变了的话，会再叫一个员工来门口等待，此员工可能是新员工B，也可能是叫醒了之前在门口休息的员工A。我们叫这位新员工X。
- 如果新员工X发现最早到店时间是现在，或者客人已经来了，就会叫一个员工C来门口接替自己，并立即开始为客人提供全流程服务。
- 如果新员工X发现最早到店时间是10分钟后，新员工X就像A之前一样，什么都不干了，先休息10分钟。
- 如果最早到店时间没有变化，还是30分钟后，软件系统不会叫人，其他员工看到A在门口等待，自己可以安心的在屋里歇着，等着A叫人替换他。
- 员工A在30分钟后醒来，客人也到了，A会叫一个同事比如B接替自己，而A为客人提供全流程服务。
DelayQueue使用
DelayQueue<OrderInfo> queue = new DelayQueue<OrderInfo>();DelayQueue的原理
数据结构
//用于保证队列操作的线程安全
private final transient ReentrantLock lock = new ReentrantLock();
// 优先级队列,存储元素，用于保证延迟低的优先执行
private final PriorityQueue<E> q = new PriorityQueue<E>();
// 用于标记当前是否有线程在排队（仅用于取元素时） leader 指向的是第一个从队列获取元素阻塞的线程
private Thread leader = null;
// 条件，用于表示现在是否有可取的元素 当新元素到达，或新线程可能需要成为leader时被通知
private final Condition available = lock.newCondition();
public DelayQueue() {}
public DelayQueue(Collection<? extends E> c) {
this.addAll(c);入队put方法
public void put(E e) {
offer(e);
}
public boolean offer(E e) {
final ReentrantLock lock = this.lock;
lock.lock();
try {
// 入队
q.offer(e);
if (q.peek() == e) {
// 若入队的元素位于队列头部，说明当前元素延迟最小
//清空leader标识，唤醒一个follower，使其能够成为leader。
leader = null;
// available条件队列转同步队列,准备唤醒阻塞在available上的线程
available.signal();
}
return true;
} finally {
lock.unlock(); // 解锁，真正唤醒阻塞的线程
}
}出队take方法
public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
for (;;) {
E first = q.peek();// 取出堆顶元素( 最早过期的元素，但是不弹出对象)
if (first == null)// 如果堆顶元素为空，说明队列中还没有元素，直接阻塞等待
available.await();//当前线程无限期等待，直到被唤醒，并且释放锁。
else {
long delay = first.getDelay(NANOSECONDS);// 堆顶元素的到期时间
if (delay <= 0)// 如果小于0说明已到期，直接调用poll()方法弹出堆顶元素
return q.poll();
// 如果delay大于0 ，则下面要阻塞了
// 将first置为空方便gc
first = null;
// 如果有线程争抢的Leader线程，则进行无限期等待。
if (leader != null)
available.await();
else {
// 如果leader为null，把当前线程赋值给它
Thread thisThread = Thread.currentThread();
leader = thisThread;
try {
// 等待剩余等待时间
available.awaitNanos(delay);
} finally {
// 如果leader还是当前线程就把它置为空，让其它线程有机会获取元素
if (leader == thisThread)
leader = null;
}
}
}
}
} finally {
// 成功出队后，如果leader为空且堆顶还有元素，就唤醒下一个等待的线程
if (leader == null && q.peek() != null)
// available条件队列转同步队列,准备唤醒阻塞在available上的线程
available.signal();
// 解锁，真正唤醒阻塞的线程
lock.unlock();
}- 当获取元素时，先获取到锁对象。
- 获取最早过期的元素，但是并不从队列中弹出元素。
- 最早过期元素是否为空，如果为空则直接让当前线程无限期等待状态，并且让出当前锁对象。
- 如果最早过期的元素不为空
- 获取最早过期元素的剩余过期时间，如果已经过期则直接返回当前元素
- 如果没有过期，也就是说剩余时间还存在，则先获取Leader对象，如果Leader已经有线程在处理，则当前线程进行无限期等待，如果Leader为空，则首先将Leader设置为当前线程，并且让当前线程等待剩余时间。
- 最后将Leader线程设置为空
- 如果Leader已经为空，并且队列有内容则唤醒一个等待的队列。
如何选择适合的阻塞队列
线程池对于阻塞队列的选择
线程池有很多种，不同种类的线程池会根据自己的特点，来选择适合自己的阻塞队列。
- FixedThreadPool（SingleThreadExecutor 同理）选取的是 LinkedBlockingQueue
- CachedThreadPool 选取的是 SynchronousQueue
- ScheduledThreadPool（SingleThreadScheduledExecutor同理）选取的是延迟队列
选择策略
通常我们可以从以下 5 个角度考虑，来选择合适的阻塞队列：
功能
第 1 个需要考虑的就是功能层面，比如是否需要阻塞队列帮我们排序，如优先级排序、延迟执行等。如果有这个需要，我们就必须选择类似于 PriorityBlockingQueue 之类的有排序能力的阻塞队列。
容量
第 2 个需要考虑的是容量，或者说是否有存储的要求，还是只需要“直接传递”。在考虑这一点的时候，我们知道前面介绍的那几种阻塞队列，有的是容量固定的，如 ArrayBlockingQueue；有的默认是容量无限的，如 LinkedBlockingQueue；而有的里面没有任何容量，如 SynchronousQueue；而对于 DelayQueue 而言，它的容量固定就是 Integer.MAX_VALUE。所以不同阻塞队列的容量是千差万别的，我们需要根据任务数量来推算出合适的容量，从而去选取合适的 BlockingQueue。
能否扩容
第 3 个需要考虑的是能否扩容。因为有时我们并不能在初始的时候很好的准确估计队列的大小，因为业务可能有高峰期、低谷期。如果一开始就固定一个容量，可能无法应对所有的情况，也是不合适的，有可能需要动态扩容。如果我们需要动态扩容的话，那么就不能选择 ArrayBlockingQueue ，因为它的容量在创建时就确定了，无法扩容。相反，PriorityBlockingQueue 即使在指定了初始容量之后，后续如果有需要，也可以自动扩容。所以我们可以根据是否需要扩容来选取合适的队列。
内存结构
第 4 个需要考虑的点就是内存结构。我们分析过 ArrayBlockingQueue 的源码，看到了它的内部结构是“数组”的形式。和它不同的是，LinkedBlockingQueue 的内部是用链表实现的，所以这里就需要我们考虑到，ArrayBlockingQueue 没有链表所需要的“节点”，空间利用率更高。所以如果我们对性能有要求可以从内存的结构角度去考虑这个问题。
性能
第 5 点就是从性能的角度去考虑。比如 LinkedBlockingQueue 由于拥有两把锁，它的操作粒度更细，在并发程度高的时候，相对于只有一把锁的 ArrayBlockingQueue 性能会更好。另外，SynchronousQueue 性能往往优于其他实现，因为它只需要“直接传递”，而不需要存储的过程。如果我们的场景需要直接传递的话，可以优先考虑 SynchronousQueue。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
