关于DelayQueue
在团队的重试与延迟调度项目中，使用了基于DelayQueue的方式来实现时间调度和触发，此处，对DelayQueue进行一些梳理。
首先是Queue接口，关于队列的含义，不再赘述。如下，Queue接口方法，按抛异常或返回特定值(null)可以分为两类如下图：
接下来是BlockingQueue接口，其继承了Queue接口，方法如下：
注意：BlockingQueue不接受null值，其所有实现类对于add null操作，都会抛出NullPointerException。null只作为poll、peek等操作的失败值。在Java官方文档中，即说明了BlockingQueue及其实现类主要用来适用生产者-消费者模型，将其作为普通的集合使用性能可能会存在问题。同时，其所有实现类都是线程安全的，内部方法通过各种锁变成了原子性操作。以下是官方文档给出的基于BlockingQueue的生产者-消费者示例：
class Producer implements Runnable {
private final BlockingQueue queue;
Producer(BlockingQueue q) { queue = q; }
public void run() {
try {
while (true) { queue.put(produce()); }
} catch (InterruptedException ex) { ... handle ...}
}
Object produce() { ... }
}
class Consumer implements Runnable {
private final BlockingQueue queue;
Consumer(BlockingQueue q) { queue = q; }
public void run() {
try {
while (true) { consume(queue.take()); }
} catch (InterruptedException ex) { ... handle ...}
}
void consume(Object x) { ... }
}
class Setup {
void main() {
BlockingQueue q = new SomeQueueImplementation();
Producer p = new Producer(q);
Consumer c1 = new Consumer(q);
Consumer c2 = new Consumer(q);
new Thread(p).start();
new Thread(c1).start();
new Thread(c2).start();
}
}
接下来，开始聊聊DelayQueue
先说说其指定的队列元素：interface Delayed的实现类
Delayed有两个接口方法：
long getDelay(TimeUnit unit); //返回还剩余的延迟时间 public int compareTo(T o); //Delayed接口继承了Comparable，用来排序
接下来，就是delayQueue的具体实现了，首先值得注意的是其内部持有这么几个东西：
ReentrantLock lock = new ReentrantLock(); // 可重入锁 Condition available = ReentrantLock.newCondition()； // 靠其来发信号唤醒等着拿数据的线程 private Thread leader = null; // leader-follower模式，用来最小化等待队头元素时间的策略 PriorityQueue<E> q = new PriorityQueue<E>(); // 优先队列，可以知道Delayed.compareTo()必然用在此处
然后看看其两个核心方法，put与take：
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 = null;
available.signal();
}
return true;
} finally {
lock.unlock();
}
}
可以看出，在向delayQueue添加元素时，主要调用PriorityQueue.offer()向内部的优先队列添加元素。在优先队列中添加元素时，会按照事先的比较方法，找到元素的合适位置并插入。同时，看到PriorityQueue中是使用Obeject[]来存储数据的，因此可以推测在大量的向delayQueue添加随机而无序的元素时，可能会遇到性能问题。
再一个有点意思的就是在offer到PriorityQueue之后，会检查一下自己是不是队头，要是自己是队头的话，作废老的leader(因为老的leader是目标取走前一个队头的线程)，再让接下来最先来取走队头的线程成为leader(结合take方法看，下一次最先来的线程，才是取走当前队头的线程)。
public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
for (;;) {
E first = q.peek();
if (first == null)
available.await(); // 1
else {
long delay = first.getDelay(TimeUnit.NANOSECONDS);
if (delay <= 0) // 2
return q.poll();
else if (leader != null) // 3
available.await();
else { // 4
Thread thisThread = Thread.currentThread();
leader = thisThread;
try {
available.awaitNanos(delay);
} finally {
if (leader == thisThread)
leader = null;
}
}
}
}
} finally {
if (leader == null && q.peek() != null)
available.signal();
lock.unlock();
}
}
来分析下上面的代码，
1. 当first == null，说明队列为空，当前线程使自己沉睡，并交出ReentrantLock锁，等待Condition.signal()来唤醒自己
2. 当队头元素到达指定的延迟时间了，直接取出返回
3. 当leader != null，说明前面的leader还在等呢，那么当前线程肯定是follower，那当前线程就只能无奈的等着Condition发信号了
4. 当leader = null时，说明当前线程是第一个要取走队头的线程，那它就理所当然成为leader，后边再来拿队头的，都是follower，都得排在后边等着。而这时，当前线程又清楚的知道队头元素的延迟时间啥时候到期，那么它根本就不用等Condition发信号，自己睡到延迟时间到期，再醒来肯定就能直接拿走队头了。可以看出，通过引入leader-follower能够降低线程的等待时间。
5. 再一个稍微注意点的就是无限for循环了，当被condition.singal()唤醒之后，正好进行下一个循环，接着取
