それは本当にメモリフットプリントを減らすつもりですか? いずれにせよ、各 JVM プロセスはいくつかのドメイン オブジェクトを作成するためです。
はい、そうです。まず、flyweight パターンを使用して、実際のシリアライゼーション/デシリアライゼーションを回避し、オフヒープ メモリに直接アクセスできます。Chronicle Map チュートリアルとChronicle Valuesの例を参照してください。
ただし、これが不可能または実装が複雑すぎる場合でも、オブジェクトをデシリアライズして JVM 内でオブジェクトにアクセスするときにオブジェクトを再map.getUsing()利用できます。
しかし、たとえば のように不変であるなどの理由で値オブジェクトを再利用できない場合でも、Stringオフヒープ メモリをデシリアライズするときに作成されたオブジェクトは寿命が短く、若い世代から昇格されない可能性が高く、GC はそれらを効率的に収集し、メモリを効果的に再利用します。一方、JVM ごとのマップがある場合、各コピーは再利用されないメモリに永続的に常駐します。
したがって、いずれにしても、JVM 間で Chronicle Map を共有することは、マシンの全体的なメモリ使用量、ひいてはパフォーマンスにとって良いことです。
エントリがデータストアに追加または削除されるたびに、各 JVM プロセスで通知を受け取ることはできますか?
オープンソース版ではそのままでは使えません。このような機能を注文することが可能です。あなたが言及したremoteOperationsについても同じことが言えます。この機能はオープンソースのサポートではなくなりました。ただし、 remoteOperations は、あなたのケースに必要なものではありません。
編集スループット要件と更新頻度に応じて、Chronicle Map に作成した更新をChronicle QueueやAeron IPC
などのマルチキャスト IPC にコピーし、他の JVM でそれらを読み取ることで、これを比較的簡単に自分で実装できることに注意してください。値なしで、更新されたキーのみをコピーできます。
マップの更新頻度が非常に高く (1 秒あたり数十万回以上の更新)、実際にはすべての更新を処理できず、同じキーへの新しい更新が既に行われている場合、いくつかのキーへの古い更新を忘れることで、イベントを自然に抑制します。しかし、あなたの場合、これはまったく必要ないかもしれません。
MapMethods と remoteOperations がそれに最も近づきました。意図した機能を実現するための正しい方法を知りたいのですか、それとも間違っていますか。
MapMethods は、MapChroncile Map のコンテキストと下位レベルの操作を使用して、 のメソッドのデフォルトの実装をオーバーライドするという狭いことを目指しています。リモート通信、イベント、リスニングとは何の共通点もありません。たとえば、ロギングまたはイベント通知を追加するためにオーバーライドできますMapMethods.put()が、呼び出しのたびにロギングまたは通知を行うことchronicleMap.put()で、ほぼ同じ結果を得ることができます。
RemoteOperations を使用すると、あるノードでエントリが配置/削除/更新され、このイベントが別のノードに到着したときに発生するアクションを再定義できます。デフォルトでは、イベントのタイムスタンプがレシーバーノードでイベントのキーを持つエントリの最終更新のタイムスタンプよりも遅い場合、つまり「最後の書き込みが勝つ」場合、イベントはレシーバーノードで再生されます。しかし、異なる戦略を定義するために上書きすることができます。つまり、値にカウントが含まれている場合、カウントが最大の値が書き込まれます。