2

頻繁に読み取られるが、ほとんど書き込まれないマップがあります。一部の操作 (読み取りまたは書き込み) には、アトミックに操作する必要がある複数のオブジェクトが含まれるため、パフォーマンスを向上させるために ReadWriteLock を使用しました。

現在、並行マップを通常のハッシュ マップにダウングレードするオプションがありますが、一部の遅い反復コードが懸念されます。

マップをダウングレードすると、同時アクセス例外を回避するために、長い反復子が読み取りロックを保持する必要があります。これにより、書き込みスレッドが長時間ブロックされると思います。

一部の反復子は一貫性のないデータに影響されないため、反復子を並行書き込みで使用できるように並行マップを保持できます。ただし、これにより、ロックを適切に使用している操作に (並行マップからの) 不必要なオーバーヘッドが追加されます。

または、Read-on-write マップのようなものを実装することもできます。このマップでは、(非同時実行の) マップ全体が書き込み操作用に複製されるため、既存のイテレーターは読み取りロックの外でも動作し続けます。

明らかに、これらのメソッドはすべて有効であり、パフォーマンスは実際のコードとセットアップに依存します。しかし、これに関する研究はあるのでしょうか (自分で実験を行う必要はありません)。

4

1 に答える 1

5

頻繁に読み取られるが、ほとんど書き込まれないマップがあります。

その場合、書き込みマップのコピーを実装することを検討します。例えば

private final Map<Key, Value> map = ?* thread safe map */
private volatile Map<Key, Value> mapCopy = emptyMap();

// when you write
get lock
modify map
take a copy and store it in mapCopy
release lock

// when you read
Map<Key, Value> map = this.mapCopy;
use map

ご覧のとおり、読み取りではロックを取得する必要はなく、書き込みでのみ取得する必要があります。

マップをダウングレードすると、同時アクセス例外を回避するために、長い反復子が読み取りロックを保持する必要があります。これにより、書き込みスレッドが長時間ブロックされると思います。

推測するのではなく、測定することをお勧めします。

これに関する研究はあるのだろうか

もしそうなら、私はそのような研究をあまり真剣に受け止めません。あなたが示唆するように、結果は状況によって異なります。

于 2012-08-10T10:49:58.580 に答える