RingBufferは事前に特定のタイプのオブジェクトを割り当てるので、単一のリングバッファーを使用して、さまざまな異なるタイプのメッセージを処理するにはどうすればよいでしょうか。
ringBufferに挿入する新しいオブジェクトインスタンスを作成することはできません。これにより、事前割り当ての目的が損なわれます。
したがって、非同期メッセージングパターンで3つのメッセージを持つことができます。
だから私の質問は、実際のメッセージングシステムにDisruptorパターンをどのように使用するつもりですか？
ありがとう
リンク： http ：//code.google.com/p/disruptor-net/wiki/CodeExamples
1つのアプローチ（最も一般的なパターン）は、メッセージをマーシャリングされた形式で、つまりバイト配列として格納することです。フィックスメッセージ、バイナリメッセージなどの着信要求の場合、ネットワークからすばやくプルされ、リングバッファに配置されます。さまざまなタイプのメッセージのアンマーシャリングとディスパッチは、そのリングバッファー上のEventProcessors（コンシューマー）によって処理されます。アウトバウンド要求の場合、メッセージは、リングバッファのエントリを形成する事前に割り当てられたバイト配列にシリアル化されます。
事前に割り当てられたエントリとして固定サイズのバイト配列を使用している場合、より大きなメッセージのオーバーフローを処理するには、追加のロジックが必要です。つまり、適切なデフォルトサイズを選択し、それを超える場合は、より大きな一時配列を割り当てます。次に、エントリが再利用または消費されたときに破棄し（ユースケースに応じて）、元の事前に割り当てられたバイト配列に戻します。
メッセージタイプごとに異なるコンシューマーがある場合は、タイプ情報を運ぶバイト配列へのオフセットを知るか、エントリに識別子の値を渡すことで、コンシューマーが特定のメッセージに関心があるかどうかをすばやく特定できます。
また、オブジェクトインスタンスの作成と参照の受け渡しを禁止する規則はありません（これはいくつかの場所でも行います）。オブジェクトの事前割り当てのメリットは失われますが、ディスラプターの設計目標の1つは、ユーザーが最も適切な形式のストレージを選択できるようにすることでした。
Javolution（http://javolution.org/）と呼ばれるライブラリがあり、可変サイズのオブジェクトではなく内部でバイトバッファに依存するstring[40]などの固定長フィールドを持つ構造体としてオブジェクトを定義できます...これにより、トークンリングを固定サイズのオブジェクトで初期化できるため、（うまくいけば）キャッシュをより効率的に機能させるための連続したメモリブロックを使用できます。
これをイベント/メッセージの受け渡しに使用し、ビジネスロジックには標準の文字列などを使用しています。
オブジェクトプールに戻ります。
以下は仮説です。
3種類のメッセージ（A、B、C）がある場合は、それらの3つの配列を事前に割り当てることができます。これにより、3つのメモリゾーンA、B、Cが作成されます。
キャッシュラインが1つしかないわけではなく、多くあり、連続している必要はありません。一部のキャッシュラインは、ゾーンA、他のB、および他のCの何かを参照します。
したがって、リングバッファエントリは、A＆B＆Cの共通の祖先またはインターフェイスへの1つの参照を持つことができます。
問題は、プール内のインスタンスを選択することです。最も簡単なのは、リングバッファの長さと同じ配列長にすることです。これは、3つのエントリのうち1つだけがエントリで使用されるため、多くの無駄なプールオブジェクトを意味します。たとえば、リングバッファエントリ1234はメッセージB [1234]を使用している可能性がありますが、A[1234]とC[1234]は使用されておらず、使用できません。誰でも。
3つのA+B + Cインスタンスすべてをインライン化してスーパーエントリを作成し、バイトまたは列挙型でタイプを示すこともできます。メモリサイズについても同様に無駄ですが、エントリが太いため、少し悪く見えます。たとえば、Cメッセージのみを処理するリーダーは、キャッシュの局所性が低くなります。
私はこの仮説にあまり間違っていないことを願っています。