Java: Disruptor: Должен ли Disruptor использоваться только для типов данных POD?

Question

Следует ли использовать Disruptor только для типов данных POD?

я имею в виду, следует ли Disruptor<T> использовать только для T значений, таких как byte[], int[], etc?

, я сомневаюсь, что если мы используем T, в котором в качестве его ссылки используется Objectпеременные-члены, нам нужно new те переменные-члены, которые будут лежать в куче.что снова приведет к пропаданию кэша, так как переменная-член может лежать на совершенно отдельной части кучи.

Так что я считаю правильным, что Disruptor<T> следует использовать только для T, принадлежащих множеству PlainСтарые типы данных (POD)?

С уважением, VImal

ОБНОВЛЕНИЕ: Может ли кто-нибудь еще взглянуть на этот вопрос?

ОБНОВЛЕНИЕ2:

Ответить на@ Триша

Привет Триша,

Привет.

Я видел ссылку, которую вы упомянули.

com.lmax.ticketing.api.Message наследуется от javolution.io.Struct и состоит изэлементы из javolution.io.Struct и javolution.io.Union, что делает взаимодействие Message между C/C++ Для любого класса, наследуемого от javolution.io.Struct/Union, структура памяти определяется порядком инициализации членов Struct/Union и следует тем жеwordSize правил как C/C++ структуры.

Таким образом, по сути, вы можете контролировать расположение в памяти элементов, которые вы помещаете в Disruptor.И все члены и подчиненные элементы Message имеют фиксированный размер, то есть не имеют никакой динамической памяти (java.lang.Object)

Это также моя точка зрения, что мы должны использовать такие элементы, чья структура памяти мы можемконтролировать и не иметь динамической памяти.И это сделано, чтобы минимизировать потери в кеше.

Предположим, если бы часть сообщения была, скажем, java.lang.String, мы не знаем, где компилятор JIT разместил бы эту строку.и если я получаю доступ к Message.String в an EventHandler, это могло бы привести к пропаданию кэша, поскольку строка может присутствовать в совершенно другом фрагменте памяти ..

Я прав?

Answer 1

Вы можете использовать любой тип объекта в качестве события, например, см. Код в https://github.com/mikeb01/ticketing (например, com.lmax.ticketing.web.RequestServlet) - здесь используется Message в качестве объекта в RingBuffer.

RingBuffer предварительно заполняется этими событиями, используя EventFactory, предоставляемый при вызове конструктора Disruptor. Таким образом, вы создаете их новый экземпляр только при создании RingBuffer и повторно используете их в течение жизни вашего Disruptor. Опять же, вы можете увидеть пример этого в приведенном выше проекте.

Answer 2

Я бы сказал нет, потому что в написанном вами коде нет ограничений.Если автор задумал такую ​​вещь, код должен обеспечить ее выполнение.

ОБНОВЛЕНИЕ: У вас есть ответ: «нет».Если вы получите еще сто ответов «нет», вам все равно придется подождать, если появится черный лебедь?У вас есть какие-либо данные, чтобы указать, что это проблема?

Предполагаете ли вы, что все решения для кэширования постигнет та же участь?Я не знаю таких ограничений ни по одному из других решений для кэширования.Стоит ли рассматривать эти дополнительные доказательства?