BlockQueue，PriorityQueue, DelayQueue 解析及其golang实现

前言

　　在日常开发中，队列是常用到的数据结构，BlockQueue、PriorityQueue、DelayQueue更是其中的重点。BlockQueue即阻塞队列，当队列满时，继续发送会阻塞；当队列为空时，继续接收会阻塞，是典型的生产-消费类型。PriorityQueue基于MaxHeap/MinHeap，保证队头的元素始终是最大值/最小值，在求max(n)（在m个数中找到最大/小的n个元素，其中m>>n）问题中具有良好的性能。DelayQueue则是延时队列，在定时任务中有重要的场景。此篇博客的契机是笔者在看kafka相关资料时，其定时/延时任务都基于TimeWheel算法（定时/延时调度常用的算法）。在kafka的TimeWheel中，将DelayQueue和TimeWheel结合起来，解决了DelayQueue插入/删除复杂度高和TimeWheel大量无效推进的问题。于是想深入了解一下此实现方式。刚好对DelayQueue不是很熟，因此重新温习了一下相关的重要数据结构。结合笔者目前的主语言golang，实现了golang实验版本的对应数据结构。

1. BlockQueue

1.1 BlockQueue实现原理

　　BlockQueue即带有阻塞性质的队列。当队列为空时，读取会阻塞；当队列满时，写入会阻塞。底层存储可以基于数组或链表实现。对此java有对应的ArrayBlockingQueue和LinkedBlockingQueue实现。该队列的关键是阻塞的实现方式，以ArrayBlockingQueue为例，在java中，通过条件Condition实现，核心的实现如下：

class ArrayBlockingQueue    {
    final Object[] items; // 数组，保存队列的元素
    // 读取数据数组下标
    int takeIndex;   
    // 插入数据数组下标
    int putIndex;
    // 队列中数组元素个数
    int count;
    // 并发访问控制锁
    final ReentrantLock lock;
    // 条件队列
    private final Condition notEmpty; // 用于实现阻塞和同志
    private final Condition notFull;
    
   // 阻塞入队put 
   public void put(E e) throws InterruptedException {
        checkNotNull(e);
        final ReentrantLock lock = this.lock;
        // 加锁
        lock.lockInterruptibly();
        try {
            while (count == items.length)
                notFull.await(); // 当队列满时，通过await挂起线程
            enqueue(e); // 入队，内部会通过notEmpty.signal()通知take()阻塞的线程
        } finally {
            lock.unlock();
        }
   }
   
   // 阻塞出队take
   public E take() throws InterruptedException {
        final ReentrantLock lock = this.lock;
        lock.lockInterruptibly();
        try {
            // 当前队列空，让出资源等待
            while (count == 0)
                notEmpty.await(); // 当队列为空时，通过await挂起线程
            return dequeue();  // 出队时，通过notFull.signal()通知put()阻塞的线程
        } finally {
            lock.unlock();
        }
    }
    
}

 

可见，实现阻塞队列的核心要点如下：

• 队列是共享资源，为了线程安全，访问时需要加锁；
• 当满足阻塞条件时，挂起线程；通过两个条件notFull和notEmpty唤醒挂起的线程
• 有数据入队时(线程调用put)，notEmpty.signal()->唤醒take阻塞的线程
• 有数据出队时（线程调用take），notFull.signal()->唤醒put阻塞的线程

1.2 golang实现ArrayBlockingQueue

　　golang中与线程对应的是协程（goroutine）。但是协程的启停通常不由用户代码控制（阻塞调用gopark ，启用可以通过schedule()让golang重新开启一次调度，以上函数均不能被外部包调用），协程阻塞通常分为以下几种场景：

• 原子操作，互斥量，锁，读写channel导致goroutine阻塞；
• 网络请求和IO操作导致goroutine阻塞;
• 系统调用导致goroutine阻塞；
• 调用sleep操作，goroutine阻塞。

当goroutine阻塞时，golang的调度器就会将此goroutine切出当前运行的线程，换一个可执行的goroutine继续在当前线程中运行。由于阻塞和启用操作比较底层，所以想利用java 的方式实现BlockQueue，操作会比较复杂。

 

 　　golang的channel，本身就具有队列的属性，同时其具有读写阻塞，并发安全的特性，是天然的BlockQueue。唯一的不足就是java的ArrayBlockingQueue中包含两个方法：element和peek，其作用是返回队头的元素，但是不取出来。想要实现这两个函数，用golang的channel就有点捉襟见肘，必须先遍历读取channel所有元素，然后再写回去，实现复杂度为O(n)（n为队列大小）。因此如果想要实现这两个函数的功能，就必须抛弃channel，按照java的方式去实现，底层仍然采用数组存储，那么如何阻塞并唤醒goroutine呢？答案还是channel（可以发现，想要实现goroutine之间的交互，channel是一个绕不过去的坎）。之前谈到goroutine阻塞时，有一种情况：读写channel阻塞。当读写cahnnel造成goroutine阻塞时，调度器会将阻塞的goroutine换出线程；而读写channel阻塞条件解除时，阻塞的goroutine又会重新唤醒。因此，只需要将java中ArrayBlockingQueue.Condition换成channel，就能实现goroutine之间的同步。

 

　　还有一个比较大的问题是，对于线程级别切换的语言，比如C++，java，在线程阻塞处于等待并切出CPU时，锁会自动释放；当线程重新获取到CPU使用权进入运行态时，会重新获取锁。但是goroutine的切换，锁不会自动释放。如果在goroutine阻塞之前不手动释放锁，那么阻塞的goroutine就会一直持有锁；导致其他goroutine没法向队列里添加或获取元素，持有锁等待channel消息而阻塞的goroutine就会死锁。

 

　　注意到了以上两个问题，实现代码就比较容易了，以下是相关代码的实现。

// Queue接口
type Queue interface {
    Add(e interface{}) error
    Offer(e interface{}) bool
    Remove() (e interface{}, err error)
    Poll() (e interface{}, getE bool)
    Element() (e interface{}, err error)
    Peek() (e interface{}, getE bool)
}

// BlockingQueue接口
type BlockingQueue interface {
    Queue
    Put(e interface{}) (closed bool) // closed状态可以标记队列是否关闭，用于当队列不可用时，能从阻塞中返回
    Take() (e interface{}, closed bool) // closed状态可以标记队列是否关闭，用于当队列不可用时，能从阻塞中返回
    OfferWithTimeout(e interface{}, timeout time.Duration) (offerd bool, closed bool) 
    PollWithTimeout(timeout time.Duration) (e interface{}, err error, closed bool)
}

// ArrayBlockingQueue及其实现
type ArrayBlockingQueue struct {
    objects  []interface{}  // 存储元素
    takIdx   int 
    putIdx   int
    count    int
    mutex    *sync.Mutex  // 保护临界区资源objects
    notEmpty chan bool    // 通知队列不为空的channel
    notFull  chan bool    // 通知队列没满的channel
}

// ArrayBlockingQueue初始化
func NewArrayBlockingQueue(cap int32) (*ArrayBlockingQueue, error) {
    if cap <= 0 {
        return nil, fmt.Errorf("cap of a queue should be greater than 0, got: %d", cap)
    }
    q := new(ArrayBlockingQueue)
    q.objects = make([]interface{}, cap)
    q.notEmpty = make(chan bool, 1)
    q.notFull = make(chan bool, 1)
    q.mutex = new(sync.Mutex)
    return q, nil
}

// 解除阻塞，由发送方调用，调用Put函数的一方
func (q *ArrayBlockingQueue) DestroyFromSender() {
    close(q.notEmpty)
}

// 解除阻塞，由接收方调用，调用Take函数的一方
func (q *ArrayBlockingQueue) DestroyFromReceiver() {
    close(q.notFull)
}

// 入队，仅供ArrayBlockingQueue其他函数调用，在调用此函数前，已经加锁保证了临界区资源访问的安全性
func (q *ArrayBlockingQueue) enqueue(e interface{}) {
    q.objects[q.putIdx] = e
    q.putIdx += 1
    if q.putIdx == len(q.objects) {
        q.putIdx = 0
    }
    q.count++
    select {
    case q.notEmpty <- true:  // 此处一定是非阻塞式发送非空的信号
    default:
        return
    }
}

// 出队，仅供ArrayBlockingQueue其他函数调用
func (q *ArrayBlockingQueue) dequeue() (e interface{}) {
    e = q.objects[q.takIdx]
    q.objects[q.takIdx] = nil
    q.takIdx += 1
    if q.takIdx == len(q.objects) {
        q.takIdx = 0
    }
    q.count -= 1
    select {
    case q.notFull <- true: // 此处一定是非阻塞式发送非空的信号
    default:
        return e
    }
    return e
}

// Queue接口的相关功能都比较容易实现，限于篇幅不在此展示

// 阻塞式接口
//阻塞式Put
func (q *ArrayBlockingQueue) Put(e interface{}) (closed bool) {
    q.mutex.Lock()
    defer q.mutex.Unlock()
    for q.count == len(q.objects) {
        q.mutex.Unlock() // 阻塞之前一定要释放锁，否则就会死锁
        _, ok := <-q.notFull
        if !ok {
            // queue closed
            q.mutex.Lock() // 判断队列是否已经关闭，关闭，则需要重新上锁，以便defer q.mutex.Unlock()解锁时不会报错
            return true // 队列已关闭
        }  
        q.mutex.Lock() // 阻塞解除时，重新上锁，再次判断队列是否已满
    }
    q.enqueue(e)
    return false
}

//阻塞式Take
func (q *ArrayBlockingQueue) Take() (e interface{}, closed bool) {
    q.mutex.Lock()
    defer q.mutex.Unlock()
    for q.count == 0 {
        q.mutex.Unlock() // 阻塞之前先解锁
        if _, ok := <-q.notEmpty; !ok {
            // queue closed
            q.mutex.Lock() // 判断队列是否已经关闭，关闭，则需要重新上锁，以便defer q.mutex.Unlock()解锁时不会报错
            return e, true 
        }
        q.mutex.Lock() // 阻塞解除重新上锁
    }
    return q.dequeue(), false
}

// 对于带timeout的take和put，实现如下
func (q *ArrayBlockingQueue) OfferWithTimeout(e interface{}, timeout time.Duration) (offered bool, closed bool) {
    q.mutex.Lock()
    defer q.mutex.Unlock()
    for q.count == len(q.objects) {
        q.mutex.Unlock()
        select {
        case _, ok := <-q.notFull:
            if !ok {
                // queue closed
                q.mutex.Lock()
                return false, true
            }
        case <-time.After(timeout): // 在阻塞的基础上，增加了超时机制
            q.mutex.Lock()
            return false, false 
        }
        q.mutex.Lock()
    }
    q.enqueue(e)
    return true, false
}

func (q *ArrayBlockingQueue) PollWithTimeout(timeout time.Duration) (e interface{}, err error, closed bool) {
    q.mutex.Lock()
    defer q.mutex.Unlock()
    for q.count == 0 {
        q.mutex.Unlock()
        select {
        case _, ok := <-q.notEmpty:
            if !ok {
                // queue closed
                q.mutex.Lock()
                return e, nil, true
            }
        case <-time.After(timeout):  // 增加了超时机制
            q.mutex.Lock()
            return e, errors.New("queue is empty"), false
        }
        q.mutex.Lock()
    }
    return q.dequeue(), nil, false
}

总结一下ArrayBlockingQueue的实现要点：

• 通过channel代替java的Condition，实现goroutine的阻塞和唤醒
• 在阻塞之前先手动释放锁；阻塞解除重新加锁
• 增加channel是否已关闭的判断，从而在队列关闭时，能退出阻塞

下面是一个简单的示例，演示如何使用ArrayBlockingQueue：

func BlockConsumer(q *ArrayBlockingQueue, wg *sync.WaitGroup) {
    for i := 0; i < 100; i++ {
        val, closed := q.Take()
        if closed {
            break
        }
        time.Sleep(time.Second * 1)
        fmt.Printf("q take succeed, val: %v, serial num: %d\n", val, i)
    }
    wg.Done()
}

func BlockProducer(q *ArrayBlockingQueue, wg *sync.WaitGroup) {
    for i := 0; i < 100; i++ {
        if closed := q.Put("put_" + strconv.Itoa(i)); closed {
            break
        }
        fmt.Println("q put succeed, serial num: ", i)
    }
    fmt.Println("BlockProducer finished")
    q.DestroyFromSender()
    wg.Done()
}

func main() {
    q, _ := NewArrayBlockingQueue(2)
    wg := new(sync.WaitGroup)
    wg.Add(4)
    // 一个生产者
    go BlockProducer(q, wg)
    /// 三个消费者
    go BlockConsumer(q, wg)
    go BlockConsumer(q, wg)
    go BlockConsumer(q, wg)
    wg.Wait()
}

2. PriorityQueue

　　PriorityQueue底层依赖于一颗完全二叉树构造的最大堆（max_heap）或最小堆（min_heap），最大堆和最小堆有以下属性：

• 堆是一颗完全二叉树;
• 根节点的值大于子节点（最大堆）或小于子节点（最小堆）;
• 左右子树同样是一颗最大堆数/最小堆树。

由于PriorityQueue底层是完全二叉树，因此对于一个序号为i的节点，左孩子节点的序号为2i，右孩子节点的序号为2i+1，因此一般用数组来存储（数组序号为0的位置不存储任何元素）。同时根节点的元素始终是最大值（max_heap）或最小值（min_heap），这样每次从PriorityQueue取数时，都是取根节点的元素，取出来的值始终有序，这也是PriorityQueue如此命名的原因。

 

　　在我之前的文章里，有详细介绍max_heap和min_heap的性质和相关函数实现：max_heap与min_heap ，在此不再赘述。由于PriorityQueue的实现不涉及到编程语言的特性，在此也不再附上go代码实现，感兴趣的读者可以自行依照原理去实现。

 

　　PriorityQueue在Top K问题上有广泛的运用，感兴趣的同学，可以练习一下Leetcode上PriorityQueue相关的题目，如下：

• Leetcode 215：第K个最大元素
• Leetcode 347：前K个高频元素
• Leetcode 239：滑动窗口的最大值
• 剑指offer 41：数据流中的中位数

3. DelayQueue

3.1 DelayQueue实现原理

　　DelayQueue是一个延时队列，队头的元素始终是到期时间最早的。获取元素时，首先判断队头元素的delay是否小于等于0；当小于等于0时，才能取出；否则阻塞直到delay小于等于0。DelayQueue的特性如下：

• 需要按延期时间有序出队，这个就是利用PriorityQueue实现的（按照延时时间delay存到优先队列里）；
• 当延时没到时，获取队列元素会造成阻塞，这部分的性质又跟BlockQueue相似，其底层也是延时未到时，阻塞线程；然后在延时完成时唤醒线程。

 因此，DelayQueue是PriorityQueue+BlockQueue的组合，广泛用于延时任务中。

 

 　　我们首先来看一下java的实现方式。由于DelayQueue是根据元素延时时间确定出队顺序的，因此要求每个元素实现了Delayed接口，包含getDelay(TimeUnit.NANOSECONDS)方法，用于获取剩余的延时时间。DelayQueue的核心数据结构如下：

class DelayQueue {
    private final transient ReentrantLock lock; 
    private final PriorityQueue<E> q； // 优先队列，用于底层存储
    private Thread leader = null; // 最先消费的等待线程
    private final Condition available； // 可用条件
    ...
}

 DelayQueue的内部数据跟BlockQueue整体差不多，也比较好理解。然后是DelayQueue的两个核心方法：

// 存入元素
public boolean offer(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock(); 
    try {
        q.offer(e); // 优先队列入队,非阻塞的
        if (q.peek() == e) {
            // 说明入队的元素delay时间最小，应当唤醒线程
            leader = null; // important
            available.signal(); // 唤醒其他等待的线程
        }
        return true
    } finally {
        lock.unlock();
    }
}

// 阻塞获取元素
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) 
                    return q.poll() // 元素到期，直接返回
                else {
                    // 需要等待
                    first = null; // 释放队头元素引用，方便其他线程获取元素并释放内存
                    // 以下部分是DelayQueue的精髓部分
                    if (leader != null) 
                        // 说明已经有定时等待线程，只需要阻塞即可 
                        available.await() 
                    else {
                        // 说明没有定时等待线程，那么当前线程设置为定时等待线程，等待的时间为delay，保证延时结束能第一时间消费
                        Thread thisThread = Thread.currentThread(); 
                        leader = thisThread; 
                        try {
                             available.awaitNanos(delay); // 定时等待
                        } finally {
                            if (leader == thisThread)
                                leader = null  // 重置定时等待线程
                        }
                    }                    
                }
            }
        }
    } finally {
        // 如果 leader 为空，且队列不为空，唤醒一个消费线程
        if (leader == null && q.peek() != null) 
            available.signal(); 
        lock.unlock();
    }
}

 

整个流程比较复杂，在此引用【Java多线程】DelayQueue源码分析 (二十六) - H__D - 博客园总结的一张图，对整个过程进行总结：

 

 

DelayQueue最难理解的部分是其leader成员变量的设置。假设以下场景：

consumer1调用take()时，队列没有元素。这个时候consumer1线程直接阻塞，leader=null --> producer1调用offer()，放入元素element1，delay=d1, 通过available.signal()唤醒consumer1 --> consumer1被唤醒，发现队列队头有元素element1且其dealy=d1>0，此时leader=consumer1, consumer1定时等待d1时长 --> 此时，又增加了若干消费者consumer_i(i=2,3,4..)，依照源码，leader != null, 其他若干consumer都会无限时长阻塞 --> 然后又进来了一个元素element2，该元素的delay=d2比当前队头元素小(d1>d2>0)，因此会调用available.signal()，那么可能唤醒：

（1）leader线程，leader线程重置leader=null，然后查看队头元素的delay，重置该delay；

（2）非leader线程，此时 队头元素delay>0，同时由于入队时在available.signal()之前，重置了leader=null；所以此时被唤醒的线程会被设置成定时线程，定时时长为d1。保证了队头元素能按时唤醒。

 综上，可以看出leader变量的重要性，保证队头元素的一定是定时等待，能按时唤醒消费线程。

3.2 golang实现DelayQueue

3.2.1 实现PriorityQueue

DelayQueue依赖PriorityQueue，因此需要先实现一个PriorityQueue。基于golang的heap实现PriorityQueue，其中的元素需要有getDelay()方法：

// 优先队列中的元素
type PqItem struct {
    Item     interface{} // 存放元素
    Priority int64  // 优先级，在此以秒为单位的timestamp
}

func (i *PqItem) getDelay() int64 {
    return i.Priority - time.Now().Unix()
}

// 优先队列，需要实现Len, Less, Swap, Push, Pop接口。同时为了方便获取队头元素，新增Peek方法
type PriorityQueue []*PqItem 

func (pq *PriorityQueue) Len() int {
    return len(*pq)
}

func (pq *PriorityQueue) Less(i, j int) bool {
    return (*pq)[i].Priority < (*pq)[j].Priority
}

func (pq *PriorityQueue) Swap(i, j int) {
    (*pq)[i], (*pq)[j] = (*pq)[j], (*pq)[i]
}

func (pq *PriorityQueue) Push(e interface{}) {
    item, ok := e.(*PqItem)
    if !ok {
        return
    }
    *pq = append(*pq, item)
}

func (pq *PriorityQueue) Pop() interface{} {
    n := len(*pq)
    e := (*pq)[n-1]
    *pq = (*pq)[0 : n-1]
    return e
}

// 新增Peek和Clear方法
func (pq *PriorityQueue) Peek() *PqItem {
    return (*pq)[0]
}

// Clear方法主要用在关闭队列时，清空队列元素，保证收发能收到队列关闭的信号
func (pq *PriorityQueue) Clear() {
    *pq = (*pq)[0:0]
}

 以上就是基于golang heap包实现的PriorityQueue，使用时：

// 初始化：
pq := PriorityQueue{
    // 填充好元素
}
heap.Init(&pq) 

// 入队
heap.Push(&pq, &pqItem)

// 出队
heap.Pop(&pq)

3.2.2 获取goroutine ID

　　golang中，没有与java Thread.currentThread()等价的函数，因此需要自己封装，用goroutine ID来唯一标记一个goroutine。网上有大量的goroutine ID获取方法，也可以参考3.8 例子:Goroutine ID · Go语言高级编程。本博客选取了实现较简单，性能较差的版本，如下：

func GetGId() int {
    var buf [64]byte
    n := runtime.Stack(buf[:], false)
    idField := strings.Fields(strings.TrimPrefix(string(buf[:n]), "goroutine "))[0]
    id, err := strconv.Atoi(idField)
    if err != nil {
        panic(fmt.Sprintf("cannot get goroutine id: %v", err))
    }
    return id
}

3.2.3 实现DelayQueue

　　在此主要演示DelayQueue的Take和Offer方法。

type DelayQueue struct {
    pq        PriorityQueue
    mutex     *sync.Mutex
    available chan bool
    leader    int // 存放goroutine ID
    closed    bool // 标记available是否关闭
}

/* 带初始元素的DelayQueue初始化
* mems: 数据; delays: mems中的数据对应的延时，单位ms
*/
func NewDelayQueue(mems []interface{}, delays []int64) (*DelayQueue, error) {
    if len(delays) != len(mems) {
        return nil, errors.New("len of delays isn't equal to len of mems")
    }
    pq := make(PriorityQueue, len(mems))
    for idx, mem := range mems {
        pq[idx] = &PqItem{
            Priority: time.Now().Unix() + delays[idx],
            Item:     mem,
        }
    }
    heap.Init(&pq) // PriorityQueue初始化

    dq := &DelayQueue{
        pq:        pq,
        mutex:     new(sync.Mutex),
        available: make(chan bool, 1),
        leader:    -1,
        closed:    false,
    }
    return dq, nil
}

// 入队, 本质上就是调用优先队列的入队操作
func (dq *DelayQueue) Offer(e interface{}, delay int64) (closed bool) {
    dq.mutex.Lock()
    defer func() {
        // 用来捕获chanel close的异常，对于发送端来说，往一个close的channel发送数据会panic，只有通过recover才能知道available已经关闭
        if err := recover(); err != nil {
            dq.closed = true
            closed = true
        }
        dq.mutex.Unlock() 
    }()
    // 先判断queue是否关闭，关闭直接返回
    if dq.closed {
        return dq.closed
    }
    item := &PqItem{
        Item:     e,
        Priority: time.Now().Unix() + delay,
    }
    heap.Push(&(dq.pq), item) // 放入优先队列
    if dq.pq.Peek() == item {
        // 注：由于不是每次入队都发送available，导致如果available关闭，发送端也不能及时检测到队列关闭；在close之前必须先清空available队列的元素。
        dq.leader = -1 // very important
        select {
        case dq.available <- true:
            return closed
        default:
            return closed
        }
    }
    return closed
}

// 出队
func (dq *DelayQueue) Take() (e interface{}, err error, closed bool) {
    dq.mutex.Lock()
    defer func() {
        if dq.leader == -1 && dq.pq.Len() > 0 && !closed {
            // 一定要判断队列是否关闭，关闭了剩余的历史数据无法获取
            select {
            case dq.available <- true:
            default:
            }
        }
        dq.mutex.Unlock()
    }()
    if dq.closed {
        return nil, nil, dq.closed
    }
    for {
        for dq.pq.Len() == 0 {
            // 无数据
            dq.mutex.Unlock()
            _, ok := <-dq.available
            dq.mutex.Lock() // 先上锁，再判断是不是关闭
            if !ok {
                // 队列已经关闭
                return nil, nil, true
            }
        }
        first := dq.pq.Peek()
        delay := first.getDelay()
        if delay <= 0 {
            PqItem := heap.Pop(&(dq.pq)).(*PqItem)
            return PqItem.Item, nil, false
        } else {
            // 没到到期时间，需要等待
            first = nil // 释放引用
            gId := GetGId()
            if dq.leader != -1 {
                // 前面有等待的goroutine，此goroutine休眠,
                dq.mutex.Unlock()
                _, ok := <-dq.available
                dq.mutex.Lock()
                if !ok {
                    return nil, nil, true
                }
            } else {
                // 前面没有等待的goroutine, 设置当前的goroutine进入定时等待
                dq.leader = gId
                dq.mutex.Unlock()
                select {
                case <-dq.available:
                case <-time.After(time.Second * time.Duration(delay)):
                }
                dq.mutex.Lock()
                if dq.leader == gId {
                    dq.leader = -1
                }
            }
        }
    }
    return nil, nil, false
}

// 最后再实现一个Exit
func (dq *DelayQueue) Exit() {
    dq.mutex.Lock()
    dq.pq.Clear() // 清空队列
    close(dq.available) // 关闭channel
    dq.mutex.Unlock()
}

3.2.4 测试

　　编写一个consumer和producer：

func DQProducer(dq *DelayQueue) {
    time.Sleep(time.Second * 14)
    num := []int{87, 59, 18, 40, 0, 11, 89, 74}
    delay := []int{1, 7, 3, 5, 6, 4, 2, 8}
    for i := 0; i < len(num); i++ {
        if closed := dq.Offer(num[i], int64(delay[i])); closed {
            break
        }
        //fmt.Printf("add num: %d, delay: %d\n", val, delay)
        time.Sleep(time.Second)
    }
}

func DQConsumer(dq *DelayQueue) {
    gId := GetGId()
    for {
        item, err, closed := dq.Take()
        if err != nil || closed {
            return
        }
        fmt.Printf("consumer %d get value: %v, timestamp: %d\n", gId, item, time.Now().Unix())
    }
}

func main() {
    mems := []interface{}{4, 3, 7, 3, 43, 13, 23, 53}
    delays := []int64{1, 3, 4, 7, 10, 8, 13, 12}
    dq, _ := NewDelayQueue(mems, delays)
    for i := 0; i < 50; i++ {
        go DQConsumer(dq, i+1)
    }
    go DQProducer(dq)
    //go DQProducer(dq)
    //go DQProducer(dq)
    time.Sleep(time.Second * 30)
    dq.Exit()
    fmt.Println("queue has been closed")
    time.Sleep(time.Second * 30)
}

 

首先DQProducer先sleep 14s，保证初始化的元素先消费完，顺便演示一下正常情况下的consumer情况。然后Producer每隔1s生产一个元素。执行结果如下：

// 正常消费
consumer 18 get value: 4, timestamp: 1653828071
consumer 23 get value: 3, timestamp: 1653828073
consumer 21 get value: 7, timestamp: 1653828074
consumer 22 get value: 3, timestamp: 1653828078
consumer 19 get value: 13, timestamp: 1653828078
consumer 39 get value: 43, timestamp: 1653828080
consumer 24 get value: 53, timestamp: 1653828082
consumer 25 get value: 23, timestamp: 1653828083
consumer 26 get value: 87, timestamp: 1653828085
consumer 28 get value: 18, timestamp: 1653828089
consumer 27 get value: 59, timestamp: 1653828092
consumer 27 get value: 40, timestamp: 1653828092
consumer 29 get value: 89, timestamp: 1653828094 // 89在11之后入队，虽然delay一样，理论上应该是11 在前, 可能原因是终端打印顺序问题
consumer 20 get value: 11, timestamp: 1653828094
consumer 20 get value: 0, timestamp: 1653828094
consumer 35 get value: 74, timestamp: 1653828100
queue has been closed

3.3 DelayQueue总结

　　上面的分析与实现，基本覆盖了DelayQueue的所有要点，在此总结一下：

• golang不存在goroutine休眠自动释放锁，所以在进入休眠之前一定要手动释放锁；重启之后再手动加锁；
• golang的channel阻塞读写和非阻塞读写一定要分开（某些场景下是阻塞的，某些是非阻塞的）；
• leader的设置尤其重要（分析见3.1）

以上实现非常简单粗暴，基本参考java的实现方式，存在频繁的加锁解锁，以及获取goroutine ID的函数性能较差，仅能学习使用。goroutine之间的同步，既要考虑channel的关闭，阻塞和非阻塞，也要频繁的在阻塞前后释放锁和加锁，实现起来非常容易出错。想要实现一个应用级的DelayQueue，还有很多优化。由于golang和java的很多特性也不一样，可能也有完全不一样的golang实现版本。