二、并发框架disruptor-性能分析之锁的问题

最新推荐文章于 2024-08-08 07:45:55 发布

七夜琉璃

最新推荐文章于 2024-08-08 07:45:55 发布

阅读量509

点赞数

分类专栏： Java-Disruptor

本文链接：https://blog.csdn.net/qiyeliuli/article/details/102454284

版权

本文探讨了Disruptor在并发框架中的性能优势，分析了加锁导致的性能延迟原因，并对比了悲观锁与乐观锁的优缺点。通过对锁问题的深入剖析，展示了Disruptor如何通过CAS操作避免锁竞争，实现高效无锁通信。

摘要由CSDN通过智能技术生成

1、说明

第一篇主要介绍了什么是disruptor，以及和AQS的性能对比，这一篇主要分析下系统性能，影响性能的瓶颈，以及disruptor是如何处理的。

2、性能延迟的原因

我们经常说的队列，指的是系统内部的内存队列。而我们常用的线程安全的Java的内置队列如下表所示
在这里插入图片描述
队列的底层一般分成三种：数组、链表和堆。其中，堆一般情况下是为了实现带有优先级特性的队列，暂且不考虑。

我们就从数组和链表两种数据结构来看，基于数组线程安全的队列，比较典型的是ArrayBlockingQueue，它主要通过加锁的方式来保证线程安全；基于链表的线程安全队列分成LinkedBlockingQueue和ConcurrentLinkedQueue两大类，前者也通过锁的方式来实现线程安全，而后者以及上面表格中的LinkedTransferQueue都是通过原子变量compare and swap（以下简称“CAS”）这种不加锁的方式来实现的。

通过不加锁的方式实现的队列都是无界的（无法保证队列的长度在确定的范围内）；而加锁的方式，可以实现有界队列。在稳定性要求特别高的系统中，为了防止生产者速度过快，导致内存溢出，只能选择有界队列；同时，为了减少Java的垃圾回收对系统性能的影响，会尽量选择array/heap格式的数据结构。这样筛选下来，符合条件的队列就只有ArrayBlockingQueue。

ArrayBlocki