3

プロファイリングを行った後、アプリケーション内の特定のオブジェクトは、オブジェクト プールを作成する代わりに使用することで大きなメリットがあることがわかりました。このアプリケーションは、複数のスレッドを持つプロデューサー/コンシューマー キューに基づいています。

ConcurrentBag コレクションは基本的に ObjectPool であり、アプリケーションのオブジェクト プールのバッキング ストアとして最適なようです。私が正しく理解していれば、ConcurrentBag は概念的に次のように機能します。

  1. バギングされたオブジェクトの ThreadLocal コレクションを保持します。挿入する場合はこのコレクションに追加し、削除する場合はこのコレクションから削除します。
  2. ローカル コレクションに要素がなく、オブジェクトを削除する必要がある場合は、別のスレッドのローカル コレクションから 1 つ盗みます。

問題は、アプリケーションが常にスレッド 'A' でオブジェクトを要求し、常にスレッド 'B' でそれを返すことを既に知っていることです。したがって、常にスチール ケースがデフォルトになります。

このアクセス パターンを知っている場合、フレームワークによって提供される別のコレクションを使用してオブジェクト プールをバックアップする方がよいでしょうか?

4

1 に答える 1

4

あなたのユースケースでは、 ConcurrentQueue を使用する方が良い構造です。ConcurrentBag は、主に同じスレッドから挿入およびプルする場合にのみ実際に使用する必要があると推測したため、 ConcurrentQueue にはスレッド アフィニティがありません。

ほとんどの Producer Consumer モデルは、書き込みと読み取りに別のスレッドを持ちます。そのため、デフォルトのバッキング ストアとしてBlockingCollection<T>a を使用します。ConcurrentQueue<T>

于 2015-02-18T22:06:17.920 に答える