LinkedBlockingQueue和ArrayBlockingQueue之间的比较

前言


最近在工作中用到了LinkedBlockingQueue,不过随后发现了另一个与此用途十分类似的类ArrayBlockingQueue。于是花了点时间,查阅了相关的文章介绍,本篇就来简单的做个小结,也是为了方便下次查阅。

LinkedBlockingQueue和ArrayBlockingQueue的共性


在讲述LinkedBlockingQueue和ArrayBlockingQueue的区别前,我们还是先了解下这2个队列结构间的一些“共性”。

第一,首先它们都继承了BlockingQueue的接口,也就是说,它们都是阻塞式的队列,这里的阻塞情况无外乎2种:一种是队列满时阻塞等待,另一种就是队列空时阻塞等待,前者等待的生成者,后者则是消费者。所以这种结构用在生产者-消费者的使用场景中是比较适用的。还有一点,因为是队列,所以肯定保证FIFO顺序性的。

第二,既然都继承了BlockingQueue的接口,那么它们所对外提供的方法也是一致的,add/offer/put,take/poll/remove。这里面还能够支持阻塞,非阻塞的调用形式,总体来说还是非常灵活的。

LinkedBlockingQueue和ArrayBlockingQueue的区别


OK,这里是本文的重点了,也就是二者之间的区别了。

首先第一个区别,ArrayBlockingQueue是有界的,而LinkedBlockingQueue默认是无界的(可以通过指定大小来变为有界)。ArrayBlockingQueue有界就意味着我们使用ArrayBlockingQueue必须指定capacity大小。这样的话,内存空间会直接预先分配好,所以在使用LinkedBlockingQueue无界情况下时要考虑到内存实际使用问题,防止内存溢出问题的发生。

第二点,锁使用的比较。ArrayBlockingQueue内部使用1个锁来控制队列项的插入、取出操作,而LinkedBlockingQueue则是使用了2个锁来控制,一个名为putLock,另一个是takeLock,但是锁的本质都是ReentrantLock。因为LinkedBlockingQueue使用了2个锁的情况下,所以在一定程度上LinkedBlockingQueue能更好支持高并发的场景操作,这里指的是并发性上,不是吞吐量。

第三点,吞吐性能上的比较。这里其实会涉及到里面具体的操作差异的问题。在ArrayBlockingQueue内部,因为是直接使用数组空间的,而且都是预先分配好的,所以操作没有那么复杂,而在LinkedBlockingQueue中,是通过链表进行维护的,而且每次插入的对象还要转为Node<>(e)对象,相当于多做了一步操作,但是根据LinkedBlockingQueue的官方描述,它是具有更好吞吐性能的。

Linked queues typically have higher throughput than array-based queues but
less predictable performance in most concurrent applications.

这里还提到了一点“less predictable performance”,这点笔者认为应该是它引入了2个锁来控制插入/取出操作有关,在这点上会比ArrayBlockingQueue要复杂些。但是笔者一直好奇一点,在小规模场景下,是否ArrayBlockingQueue会比LinkedBlockingQueue更适用呢?这个大家可以试试,笔者也还没试过。

评论 3 您还未登录,请先 登录 后发表或查看评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:编程工作室 设计师:CSDN官方博客 返回首页

打赏作者

Android路上的人

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值