4

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

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

我的疑问是，如果我们使用Twhich has Objectreferences 作为其成员变量，我们需要new那些将位于堆上的成员变量。这将再次导致缓存未命中，因为成员变量可能位于堆的完全独立的部分。

那么我的想法是否正确，Disruptor<T>应该只用于T属于一组普通旧数据类型（POD）？

问候， 维马尔

更新：其他人可以看看这个问题吗？

更新2：

回复@Trisha

嗨特丽莎，

问候。

我看到了你提到的链接。

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

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

这也是我的观点，我们应该使用我们可以控制内存布局并且没有任何动态内存的元素。这样做是为了最大限度地减少缓存未命中。

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

我对吗？

4

2 回答 2

3

您可以使用任何类型的对象作为事件，例如，请参阅https://github.com/mikeb01/ticketing上的代码（例如 com.lmax.ticketing.web.RequestServlet） - 这使用 aMessage作为对象RingBuffer.

调用构造函数时使用提供的这些RingBuffer事件预先填充这些事件。因此，您只需在创建 时创建它们的新实例，并且在. 同样，您可以在上述项目中看到一个示例。EventFactoryDisruptorRingBufferDisruptor

于 2012-02-17T13:41:16.893 回答
1

我会说不，因为您编写的代码中没有任何限制。如果作者打算这样做，则代码应强制执行。

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

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

于 2012-02-17T12:01:38.360 回答