数据结构与算法——队列
我们知道,CPU资源是有限的,任务的处理速度与线程个数并不是线性正相关。相反,过多的线程反而会导致CPU频繁切换,处理性能下降。所以,线程池的大小一般都是综合考虑要处理任务的特点和硬件环境,来事先设置的。
当我们向固定大小的线程池中请求一个线程时,如果线程池中没有空闲资源了,这个时候线程池如何处理这个请求?是拒绝请求还是排队请求?各种处理策略又是怎么实现的呢?
1.如何理解“队列”
队列这个概念可以把它想象成排队买票,先来的先买,后来的人只能站末尾,不允许插队。先进者先出,这就是典型的“队列”。
队列跟栈相似,支持的操作也有限,最基本的操作也是两个:入队enqueue(),放一个数据到队列尾部;出队dequeue(),从队列头部取一个元素。
队列和栈一样,也是一种操作受限的线性表数据结构。
作为一种非常基础的数据结构,队列的应用也非常广泛,特别是一些具有某些额外特性的队列,比如循环队列、阻塞队列、并发队列。它们在很多偏底层系统、框架、中间件的开发中,起着关键性的作用。比如高性能队列Disruptor、Linux环形缓存,都用到了循环并发队列;java concurrent并发包利用ArrayBlockingQueue来实现公平锁等。
2.顺序队列和链式队列
用数组实现的队列叫做顺序队列,用链表实现的队列叫做链式队列。
1 | //用数组实现的队列 |
对于栈来说,只需要一个栈顶指针就可以了。但是队列需要两个指针:一个是head指针,指向队头;一个是tail指针,指向队尾。
随着不停的入队、出队操作,head和tail都会持续往后移动。当tail移动到最右边,即使数组中还有空闲空间,也无法继续往队列中添加数据了。这个问题如何解决?
在数组中,数组的删除操作会导致数组中的数据不连续,解决方法是用数据搬移。但是,每次进行出队操作删除队列头的元素(相当于删除数组下标为0的数据),要搬移整个队列中的数据,这样出队操作的时间复杂度就会从原来的O(1)变为O(n)。如何优化呢?
实际上,在出队时可以不用搬移数据。如果没有空闲空间了,只需要在入队时,集中触发一次数据的搬移操作。借助这个思想,出队函数dequeue()保持不变,改动一下入队函数enqueue():
1 | //入队操作,将item放入队尾 |
基于链表的实现,同样需要两个指针:head指针和tail指针。它们分别指向链表的第一个结点和最后一个结点。入队时,tail->next=new_node,tail=tail->next;出队时,head=head->next。
1 | //基于链表的实现 |
3.循环队列
循环队列,顾名思义,它长得像一个环。原本队列是有首有尾的,是一条直线,现在把它首尾相连,扳成了一个环。
图中这个队列的大小为8,当前head=4,tail=7.当有一个新的元素a入队时,放入下标为7的位置。但这个时候,并不把tail更新为8,而是将其在环中后移一位,到下标为0的位置。当再有一个元素b入队时,将b放入下标为0的位置,然后tail+1更新为1。所以,a、b依次入队之后:
循环队列的代码实现难度要比非循环队列难一些,关键在于,确定好队空和队满的判定条件。
用数组实现的非循环队列中,队满的判定条件是tail==n,队空的判定条件是head==tail。
循环队列为空的判断条件仍然是head==tail。队满的判断条件稍有不同:
当队满时,(tail+1)%n=head。
当队列满时,图中tail指向的位置实际上是没有存储数据的,这种方法是少用一个元素空间,约定以“队列头指针在队列尾指针的下一位置上”作为队列“满”的标志。
另一种方法是另设一个标志位以区别队列是“空”还是“满”。另外占用一个内存空间。
1 | public class CircularQueue { |
4.阻塞队列和并发队列
队列这种数据结构很基础,平时的业务开发不大可能从0实现一个队列,甚至不会用到。而一些具有特殊特性的队列应用却比较广泛,比如阻塞队列和并发队列。
阻塞队列是在队列基础上增加了阻塞操作。简单来说,就是在队列为空的时候,从队头取数据会被阻塞,因为此时还没有数据可取,直到队列中有了数据才能返回;如果队列已经满了,那么插入数据的操作就会被阻塞,直到队列中有空闲位置后再插入数据,然后再返回。
上述的定义就是一个“生产者—消费者模型”。使用阻塞队列可以轻松实现一个“生产者—消费者模型”。
那,在多线程情况下,会有多个线程同时操作队列,这个时候就会存在线程安全问题,如何实现一个线程安全的队列呢?
线程安全的队列叫做并发队列。最简单直接的实现方式是直接在enqueue()、dequeue()方法上加锁,但是锁粒度大并发度会比较低,同一时刻仅允许一个存或者取操作。实际上,基于数组的循环队列,利用CAS原子操作,可以实现非常高效的并发操作,这也是循环队列比链式队列应用更加广泛的原因,
5.线程池没有空闲线程时,新的任务请求线程资源时,线程池该如何处理?各种处理策略是如何实现的?
一般有两种处理策略。第一种是非阻塞的处理方式,直接拒绝任务请求;另一种是阻塞的处理方式,将请求排队,等到有空闲线程时,取出排队的请求继续处理。
对于如何存储排队的请求,我们希望公平地处理每个排队的请求,先进者先服务,所以队列这种数据结构很适合来存储排队请求。基于链表和基于数组实现的队列对于排队请求有何区别?
基于链表的实现方式,可以实现一个支持无限排队的无界队列(unbounded queue),但是可能会导致过多的请求排队等待,请求处理的响应时间过长。所以,针对响应时间比较敏感的系统,基于链表实现的无限排队的线程池是不合适的。
基于数组实现的有界队列(bounded queue),队列的大小有限,所以线程池中排队的请求超过队列大小时,接下来的请求就会被拒绝,这种方式对响应时间敏感的系统来说,就相对更加合理。不过,设置一个合理的队列大小,是很有讲究的。队列太大导致等待的请求太多,队列太小会导致无法充分利用系统资源、发挥最大性能。
除了队列应用在线程池请求排队的场景之外,队列可以应用在任何有限资源池中,用于排队请求,比如数据库连接池等。实际上,对于大部分资源有限的场景,当没有空闲资源时,基本上都可以通过“队列”这种数据结构来实现请求排队。