后面有补充这门课的内容吗？我看到老师回复说会补充，为何没有在评论区中反馈呢？对后面学习这门课的学生很困惑啊

“生产者申请连续空间后，后续往队列添加元素就不需要加锁了，因为这个存储单元是这个线程独享的”

这个不好理解，添加元素的不是有可能多个线程吗？那不是会产生竞争资源吗？

希望得到解惑

课后思考。
如果不是分布式应用：
1.用JDK自带的AtomicLong
2.用Oracle数据库中的Sequence
如果是分布式应用：
1.用zookeeper生成全局ID
2.用Redis中的Redlock 生产全局ID

Disruptor是一种内存消息队列，功能上类似 Kafka， 不同的是Disruptor 是线程之间用于消息传递的队列。在 Apache Storm、Camel、Log4j 2 等很多知名项目中都有广泛应用。

它的性能表现非常优秀，比 Java 中另一个非常常用的内存消息队列 ArrayBlockingQueue（ABS）的性能，要高一个数量级，可以算得上是最快的内存消息队列。

Disruptor 是如何做到如此高性能的？其底层依赖了哪些数据结构和算法？

基于循环队列的“生产者 - 消费者模型”
“生产者 - 消费者模型”，“生产者”生产数据，并且将数据放到一个中心存储容器中。“消费者”从中心存储容器中，取出数据消费。

实现中心存储容器的数据结构是队列。队列支持数据的先进先出，使得数据被消费的顺序性可以得到保证

队列有两种实现思路。一种是基于链表实现的链式队列，另一种是基于数组实现的顺序队列

如果实现一个无界队列，适合选用链表来实现队列，因为链表支持快速地动态扩容

相较于无界队列，有界队列的应用场景更加广泛。机器内存是有限的，无界队列占用的内存数量是不可控的，有可能因为内存持续增长，而导致 OOM（Out of Memory）错误。

循环队列是一种特殊的顺序队列。非循环的顺序队列在添加、删除数据时涉及数据的搬移操作，导致性能变差。而循环队列可以解决数据搬移问题，所以性能更加好。所以大部分用顺序队列中的循环队列。

循环队列这种数据结构，就是内存消息队列的雏形

基于加锁的并发“生产者 - 消费者模型”
在多个生产者或者多个消费者并发操作队列的情况下，主要会有下面两个问题：

多个生产者写入的数据可能会互相覆盖；
多个消费者可能会读取重复的数据。

如何解决这种线程并发往队列中添加数据时，导致的数据覆盖、运行不正确问题？

最简单的处理方法就是给代码加锁，同一时间只允许一个线程执行 add() 函数，由并行改成了串行



Disruptor 的基本思想是换了一种队列和“生产者 - 消费者模型”的实现思路。
    * 生产者：往队列中添加数据之前，先批量地申请连续的 n 个（n≥1）可用空闲存储单元。这组存储单元是这个线程独享的，后续往队列中添加元素可以不用加锁了。申请存储单元的过程是需要加锁的

    * 消费者：处理的过程跟生产者是类似的。先申请一批连续可读的存储单元（申请的过程也是要加锁），当申请到这批存储单元之后，后续的读取操作就不加锁

    * Disruptor 实现思路的一个弊端：如果生产者 A 申请到了一组连续的存储单元，假设是下标为 3 到 6 的存储单元，生产者 B 紧跟着申请到了下标是 7 到 9 的存储单元，在 3 到 6 没有完全写入数据之前，7 到 9 的数据是无法读取的

    * Disruptor 采用的是 RingBuffer 和 AvailableBuffer 这两个结构，来实现功能

总结引申

    * 多个生产者同时往队列中写入数据时，存在数据覆盖的问题。多个消费者同时消费数据，会存在消费重复数据的问题
    * 为了保证逻辑正确，尽可能地提高队列在并发情况下的性能，Disruptor 采用了“两阶段写入”的方法。
    * 在写入数据之前，先加锁申请批量的空闲存储单元，之后往队列中写入数据的操作就不需要加锁了，写入的性能因此就提高了
    * Disruptor 对消费过程的改造，跟对生产过程的改造是类似的。它先加锁申请批量的可读取的存储单元，之后从队列中读取数据的操作也就不需要加锁了，读取的性能因此也就提高了