Java: Disruptor: Disruptor是否应该仅用于POD数据类型？

Question

Disruptor是否应该仅用于POD数据类型？

我的意思是，Disruptor<T>应该只用于像byte[], int[], etc这样的T取值吗？

我怀疑的是，如果我们使用具有Object引用的T作为其成员变量，我们需要new那些将位于堆上的成员变量。这将再次导致高速缓存未命中，因为成员变量可能位于堆的完全独立的部分上。

那么，我的想法是否正确，即Disruptor<T>应该仅用于属于普通旧数据类型(PODs)集的T？

致敬，VImal

更新:其他人可以看一下这个问题吗？

UPDATE2：

回复@Trisha

嗨，特里莎，

欢迎光临。

我看到了你提到的链接。

com.lmax.ticketing.api.Message是从javolution.io.Struct继承的，由来自javolution.io.Struct和javolution.io.Union的元素组成，这使得Message可以在C/C++之间互操作，对于从javolution.io.Struct/Union继承的任何类，内存布局由Struct/Union成员的初始化顺序定义，并遵循与C/C++结构相同的wordSize规则。

因此，从本质上讲，您可以控制放入Disruptor中的元素的内存布局。并且Message的所有成员和子成员都是固定大小的，即没有任何动态内存(java.lang.Object)

这也正是我的观点，我们应该使用这样的元素，它们的内存布局是我们可以控制的，而不是任何动态内存。并且这样做是为了最小化高速缓存未命中。

假设，如果消息的一部分是java.lang.String，我们不知道JIT编译器会将该字符串放在哪里。如果我访问EventHandler中的Message.String，这可能会导致缓存未命中，因为字符串可能存在于完全不同的内存块中。

我说的对吗？

Answer 1

您可以使用任何类型的对象作为事件，例如，请参阅https://github.com/mikeb01/ticketing中的代码(例如com.lmax.ticketing.web.RequestServlet) -它使用Message作为RingBuffer中的对象。

使用在调用Disruptor构造函数时提供的EventFactory，RingBuffer中预先填充了这些事件。因此，您只需在创建RingBuffer时创建它们的一个新实例，并在Disruptor的整个生命周期中重用它们。同样，你可以在上面的项目中看到一个这样的例子。

Answer 2

我会说没有，因为在你写的代码中没有指明的限制。如果作者有意这样做，代码应该强制执行它。

更新:你得到了一个答案：“不”。如果你得到100多个“不”的答案，你还需要等待，以防黑天鹅出现吗？您是否有任何数据表明这是一个问题？

您认为所有缓存解决方案都会遭受同样的命运吗？据我所知，其他任何缓存解决方案都没有这样的限制。有更多的证据值得考虑吗？