因为一篇微信上关于时间轮的文章引起了我的兴趣，在网上看了很多关于时间轮的文章，看到了Kafka中的时间轮定时器是基于DelayQueue实现的，于是先来把DelayQueue相关的知识梳理清楚
概述
DelayQueue 是一个支持延时获取元素的无界阻塞队列。队列使用 PriorityQueue 来实现。队列中的元素必须实现 Delayed 接口，在创建元素时可以指定多久才能从队列中获取当前元素。只有在延迟期满时才能从队列中提取元素。我们可以将 DelayQueue 运用在以下应用场景：
缓存系统的设计：可以用 DelayQueue 保存缓存元素的有效期，使用一个线程循环查询 DelayQueue，一旦能从 DelayQueue 中获取元素时，表示缓存有效期到了。
定时任务调度。使用 DelayQueue 保存当天将会执行的任务和执行时间，一旦从 DelayQueue 中获取到任务就开始执行，从比如 TimerQueue 就是使用 DelayQueue 实现的
继承关系：
public class DelayQueue<E extends Delayed> extends AbstractQueue<E>
implements BlockingQueue<E> {
private final transient ReentrantLock lock = new ReentrantLock();
private final PriorityQueue<E> q = new PriorityQueue<E>();
...
}
DelayQueue实际是由优先队列（PriorityQueue）实现的BlockingQueue，优先队列比较的基准是时间
相关知识
BlockingQueue
BlockingQueue是一个阻塞队列，支持两个附加操作：在队列为空时，获取元素的线程会等待队列变为非空。当队列满时，存储元素的线程会等待队列可用。阻塞队列常用于生产者和消费者的场景，生产者是往队列里添加元素的线程，消费者是从队列里拿元素的线程。阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。
PriorityQueue
优先级队列，根据比较器来比较集合中元素的权重，每次出队都弹出优先级最小或最大的元素
java中的优先级队列是由一个可扩容的数组（堆）实现的，初始化时需要传入一个实现了comparator接口的比较器，如果未传入，则使用元素自身的comparable接口进行元素比较，最后得出一个根据比较权重排序的队列
Delayed
Delayed接口继承了Comparable接口，自身需要有一个getDelay的实现，比较的基准是延时的时间值
public interface Delayed extends Comparable<Delayed> {
//该元素距离失效还剩余的时间，当<=0时元素就失效了
long getDelay(TimeUnit unit);
DelayedQueue中的元素必须实现Delayed接口
DelayedQueue源码
DelayedQueue中的重要属性
private final transient ReentrantLock lock = new ReentrantLock();
private final PriorityQueue<E> q = new PriorityQueue<E>();
private Thread leader = null;
private final Condition available = lock.newCondition();
DelayedQueue中的add()及put()方法都调用了offer()，因为使用了条件队列作为实现，条件队列是会扩容且无界的，所以对于生产者来说，可以无限向队列中生产任务从而不需要阻塞
public boolean offer(E e) {
final ReentrantLock lock = this.lock;
//获取锁
lock.lock();
try {
//加入条件队列q
q.offer(e);
//如果刚刚放入的元素是队列的第一个元素，唤醒线程，并更换leader
if (q.peek() == e) {
leader = null;
available.signal();
}
return true;
} finally {
lock.unlock();
}
}
DelayedQueue中poll()和take()方法的实现不同，poll方法并不会阻塞并等待队列中有元素才返回
public E poll() {
final ReentrantLock lock = this.lock;
//获取锁
lock.lock();
try {
//获取条件队列中首个元素，未删除
E first = q.peek();
//如果首个元素为空或者时延还未达到，则说明队列里没有任务需要执行，返回空
if (first == null || first.getDelay(NANOSECONDS) > 0)
return null;
//如果都不为空且时延已到，则删除条件队列中首位并返回
else
return q.poll();
} finally {
lock.unlock();
}
}
take方法会阻塞到直到队列中有元素才会被唤醒
public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
//获取的是可中断的锁，如果已经被中断了就会抛出InterruptedException异常，而不需要等到调用await方法才抛异常了
lock.lockInterruptibly();
try {
for (;;) {
E first = q.peek();
//如果当前队列为空，则进入available的条件等待队列
if (first == null)
available.await();
else {
long delay = first.getDelay(NANOSECONDS);
if (delay <= 0)
return q.poll();
first = null; // don't retain ref while waiting
//如果leader线程不为空，说明当前线程为等待线程，加入availabe中等待
if (leader != null)
available.await();
else {
//如果leader线程为空，将当前线程设为leader，调用await方法休息delay时延，等待队首元素过期，然后更换leader
Thread thisThread = Thread.currentThread();
leader = thisThread;
try {
available.awaitNanos(delay);
} finally {
if (leader == thisThread)
leader = null;
}
}
}
}
} finally {
//如果当前没有leader线程在工作且条件队列不为空，唤醒available中线程
if (leader == null && q.peek() != null)
available.signal();
lock.unlock();
}
}
步骤：
（1）获取锁；
（2）若队列为空，则阻塞等待；
（3）否则，获取队首元素delay时间；
（4）若delay时间已过期，则释放锁，将队首元素出队（注意：take返回前，如果leader为null且队列不为空，则发送available信号）；
（5）若delay时间未到期且已设置leader，则阻塞等待；
（6）若delay时间未到期且未设置leader，则设置当前线程为leader，等待队首元素过期；
（7）循环（2）——（6），返回前，释放锁。
leader-follower模式
在DelayQueue中使用到了leader-follower模式
在多线程环境下，我们理所当然会考虑使用线程池，而任何池的使用，都会带来一个管理和切换的问题。
这个模式的作用其实是解决线程频繁切换带来的开销的，大家都知道，线程切换是有代价的，虽然进程内数据共享，
但不断的将cpu的寄存器，二级缓存的东西进进出出和指令来回折腾，现场复原，这些代价都很大，
所以这也就是，线程不是越多就性能越高，当在一定的机器的环境下，线程到了一定程度性能就上不去，反而下降，其罪魁祸首就是频繁的线程切换
leader-follower一定程度上能解决一些线程切换带来的问题，这种模式的基本思想是所有线程会有三种身份中的一种：leader和follower，以及一个干活中的状态：proccesser。它的基本原则就是，永远最多只有一个leader。而所有follower都在等待成为leader。线程池启动时会自动产生一个Leader负责等待事件，当有一个事件产生时，Leader线程首先通知一个Follower线程将其提拔为新的Leader，然后自己就去干活了，去处理这个事件，处理完毕后加入Follower线程等待队列，等待下次成为Leader。这种方法可以增强CPU高速缓存相似性，及消除动态内存分配和线程间的数据交换。
参考文献：
