高性能キャッシュの作成

Question

ConcurrentHashMapをキャッシュとして使用する株式市場シミュレータを作成しました。

キャッシュは約75個の要素を保持しますが、キャッシュは非常に高速に更新され（約500回/秒）更新されます。ここで

は私がやったことです：

スレッド1：

与えられた銘柄記号のためのストリーミング引用符で私を提供外部のシステムに接続されています。

スレッド2（コールバックスレッド）：

待機データは、外部システムによってそこに配信されるまで。データを取得すると、それを解析し、不変のDataEntryオブジェクトを作成し、キャッシュし、thread3に信号を送信します。

スレッド3（消費者スレッド）： 信号を受信すると、キャッシュからDataEntryを取り出して使用します。 （これは、スレッド2がスレッド3に直接データをプッシュしないようにするタスクの一部です）。

public final class DataEntry{ 

     private final String field1; 
     private final String field2; 
     //... 
     private final String field25; 

     // Corresponding setters and getters 

} 

public final class Cache{ 

     private final Map<String, DataEntry> cache; 

     public Cache(){ 
      this.cache = new ConcurrentHashMap<String, DataEntry> (65, 0.75, 32); 
     } 

     // Methods to update and retrieve DataEntry from the cache. 
} 

プロファイラを通してそれを実行した後、私は私がたくさんDataEntryオブジェクトのを作成していていることに気づきました。したがって、エデンは非常に迅速に満ちています。 A）がDataEntryクラスが変更可能な作り

：

だから、私はしてデザインを少し微調整を考えています。

b）キャッシュを空のDataEntryオブジェクトに事前に移入します。

c）更新が到着したら、DataEntryオブジェクトをマップから取得し、フィールドに入力します。

このようにして、DataEntryオブジェクトの数は一定で、要素数に等しくなります。

私の質問は以下のとおりです。

A）が、このデザインは、私がDataEntryが可変することによって導入されている可能性のある並行性の問題を持っています。

b）キャッシュを最適化するために何かできることはありますか？

ありがとうございました。

Answer 1

私はConcurrentHashMapの

Map<Integer, Integer> map = new ConcurrentHashMap<>(); 
long start = System.nanoTime(); 
int runs = 200*1000*1000; 
for (int r = 0; r < runs; r++) { 
    map.put(r & 127, r & 127); 
    map.get((~r) & 127); 
} 
long time = System.nanoTime() - start; 
System.out.printf("Throughput of %.1f million accesses per second%n", 
     2 * runs/1e6/(time/1e9)); 

の速さを心配しないでしょうプリント

Throughput of 72.6 million accesses per second 

これは、はるかにあなたが使用しているように思われるアクセス速度を超えています。

ガベージを減らしたい場合は、変更可能なオブジェクトとプリミティブを使用できます。この理由から、Stringを使用することは避けてください（データエントリよりもはるかに文字列が多いようです）

Answer 2

が本当にになる必要があるときは、ConcurrentHashMapを使用しているようですが、これは並行キューのようなものです - たとえば、LinkedBlockingQueue？

Answer 3

• a。はい、そうです。Mutable DataEntryオブジェクトは、読者が気づかずに更新される可能性があり、不整合な状態につながります。
• b。はい、可能です：変更可能なDataEntryを要求に応じて返す変更可能なDataEntryCacheを作成します。この方法では、書き込み時ではなく、読み取り時に新しいDataEntryオブジェクトを作成します。 DataEntryCacheは、それが構成して返す不変のDataEntryを内部的にキャッシュし、突然変異する呼び出しでその「キャッシュ」を無効にできます。

編集：キャッシュする理由（スレッド2とスレッド3の間にキューを作成するのとは対照的に）は、コンシューマスレッドがスレッド2が他のエントリを読み取る可能性があることを前提としています。お知らせ。この仮定が間違っていると、キャッシュがまったく必要ない場合があります。私のコードオブジェクトの作成で

Answer 4

A）は、多くの場合、ボトルネックとして現れたので、私はDataEntryオブジェクトを再利用する独自のアイデアがあまりにも実装する価値があると思います。しかし、kdgregoryがコメントしたように、現在の要素を上書きするだけでは、一貫性のないエントリが読み取られることになります。したがって、エントリを更新するときには、新しいエントリまたは使用可能な場合は、再利用されたアイドル（数分間のアイドル）エントリを書き込んで、マップに書き込んでください。新しいエントリをマップに入れたら、古いエントリを何らかの種類のアイドルリストに置きます。完全に安全であるためには、読み取りスレッドは、キャッシュによって配信されたDataEntryにアクセスできないようにする必要があります。 1分。スレッドがブロックする可能性がある場合は、DataEntryオブジェクトをコピーする必要があります。おそらく、このために独自のオブジェクトを再利用してください。

b）現在のデザインはモジュール式ですが、スレッドにはモジュールが反映されているため、多くのコンテキストスイッチが必要です。私は、単一の要求が単一のスレッドによって最初から最後まで提供される設計を試みるだろう。要求は新しいDataEntryオブジェクトの完全な処理である可能性があります。これを実現する並行処理設計パターンはLeader/FollowerとHalf-Sync/Half-Asynchです。