🔴 💘 🧓🏽 C＃オブジェクトプールの実装 😢 🐳 🥃

良い一日！

この記事では、「1回限りの」作業用にオブジェクトが作成されることが多いマルチスレッド（およびそれだけではない）C＃アプリケーションのパフォーマンスを改善する方法を説明します。

マルチスレッド、ノンブロッキング同期、VS2012の組み込みプロファイラーの使用、および小さなベンチマークについて少し説明します。

はじめに

オブジェクトプールは、生成的なデザインパターンであり、初期化されてすぐに使用できるオブジェクトのセットです。

なぜ必要なのですか？簡単に言えば、新しいオブジェクトを初期化する際のパフォーマンスを向上させることは大きな費用です。ただし、.NETの組み込みのガベージコレクターは、短命のオブジェクトの破壊に対処するため、プールの適用可能性は次の基準によって制限されることを理解することが重要です。

作成および/または破壊するのに高価なオブジェクト（例：ソケット、フロー、管理されていないリソース）;
再利用のためにオブジェクトをクリーニングする方が、新しいオブジェクトを作成するよりも安価です（または無料です）。
非常に大きなオブジェクト。

最後のポイントについて少し説明します。オブジェクトがメモリで85,000バイト以上を占有している場合、第2世代のガベージコレクションで大きなオブジェクトヒープに分類され、自動的に「長命」オブジェクトになります。この断片化に追加し（このヒープは縮小しません）、メモリの不足という潜在的な問題を得るために、一定の割り当て/破壊を行います。

プールのアイデアは、次のシナリオを使用して「高価な」オブジェクトの再利用を整理することです。

var obj = pool.Take(); //    .        obj.DoSomething(); pool.Release(obj); //  ("")   ,

このアプローチの問題：

オブジェクトの操作後、以前の使用が後続のオブジェクトに影響を与えないように、オブジェクトを初期状態にリセットする必要がある場合があります。
プールは、通常、マルチスレッドシステムで使用されるため、スレッドセーフを提供する必要があります。
プールは、発行可能なオブジェクトがない場合に処理する必要があります。

これらの問題を念頭に置いて、新しいクラスの要件がコンパイルされました。

コンパイル段階でのプールのタイプセーフティ。
プールは、サードパーティを含むすべてのクラスで機能します。
コードでの簡単な使用。
不足がある場合の新しいオブジェクトの自動割り当て、ユーザー初期化。
選択したオブジェクトの総数を制限します。
オブジェクトがプールに戻ったときにオブジェクトを自動クリーニングします。
スレッドセーフティ（できれば、最小限の同期コスト）。
複数のプールインスタンスのサポート（ここから、少なくとも最も単純な制御は、オブジェクトがプールに戻るようにすることです）。

使用上の問題を解決する

一部の実装では、オブジェクトプールをサポートするために、オブジェクトはIPoolableインターフェイスなどを実装する必要がありますが、私のタスクは、継承のために閉じられている場合でも、プールがすべてのクラスで動作するようにすることでした。これを行うために、PoolSlot汎用シェルが作成されました。このシェルには、オブジェクト自体とプールへのリンクが含まれています。プール自体は、これらのスロットを格納するための抽象的な汎用クラスであり、新しいオブジェクトを作成して古いオブジェクトをクリーニングするための2つの未実現メソッドがあります。

 public abstract class Pool<T> { public PoolSlot<T> TakeSlot() {...} //  "  " public void Release(PoolSlot<T> slot) {...} //  "  " /* ... */ //   : protected abstract T ObjectConstructor(); //   ,    protected virtual void CleanUp(T item) {} //   ,   }

SocketAsyncEventArgsクラスの使用例

プール定義

 public class SocketClientPool : Pool<SocketAsyncEventArgs> { private readonly int _bufferSize; public SocketClientPool(int bufferSize, int initialCount, int maxCapacity) : base(maxCapacity) { if (initialCount > maxCapacity) throw new IndexOutOfRangeException(); _bufferSize = bufferSize; TryAllocatePush(initialCount); //      protected-;           } protected override SocketAsyncEventArgs ObjectConstructor() { var args = new SocketAsyncEventArgs(); args.SetBuffer(new byte[_bufferSize], 0, _bufferSize); return args; } protected override void CleanUp(SocketAsyncEventArgs @object) { Array.Clear(@object.Buffer, 0, _bufferSize); } }

コードで使用：

 var pool = new SocketClientPool(1024, 5, 10); //   ,  /* ...-  ... */ var slot = pool.TakeSlot(); //     var args = slot.Object; //    -  pool.Release(slot); //

またはこのように：

 using(var slot = pool.TakeSlot()) //  PoolSlot  IDisposable { var args = slot.Object; }

Socket.XxxAsyncメソッドはPoolSlot <SocketAsyncEventArgs>ではなくSocketAsyncEventArgsを正確に受け入れるため、非同期.NETモデルおよび/または同じSocketクラスの非同期メソッドに精通している人は、このような実装の使用が難しいことを知っています。。メソッドを呼び出すためにこれは重要ではありませんが、終了ハンドラーのどこでスロットを取得できますか？

1つのオプションは、オブジェクトの作成時にSocketAsyncEventArgs.UserTokenプロパティにスロットを保存することです。これには、プールにHoldSlotInObjectをオーバーライドするメソッドがあります。

例のオーバーライド

 protected override void HoldSlotInObject(SocketAsyncEventArgs @object, PoolSlot<SocketAsyncEventArgs> slot) { @object.UserToken = slot; } /* ...-  ... */ pool.Release(args.UserToken as PoolSlot<SocketAsyncEventArgs>);

もちろん、すべてのオブジェクトがユーザーにそのようなプロパティを提供するわけではありません。クラスがまだ継承から閉じられていない場合、スロットを格納するための1つのプロパティを持つ特別なIPoolSlotHolderインターフェイスが提供されます。オブジェクトにスロットが含まれることが保証されていることがわかっている場合は、プール自体の子孫で行われたオブジェクト自体を返す/受け取る（およびスロットを取得する）TakeObject / Releaseメソッドを追加するのが論理的です。

改善されたプールの実装の簡素化（IPoolSlotHolderを実装するオブジェクトの場合）

 public abstract class PoolEx<T> : Pool<T> where T : IPoolSlotHolder { public T TakeObject() { ... } public void Release(T @object) { ... } protected sealed void HoldSlotInObject(T @object, PoolSlot<T> slot) { ... } //      }

次に、内部の「キッチン」の開発に精通することを提案します。

保管

ConcurrentStackコレクションは、「プールに」オブジェクトを格納するために使用されます。プールのいくつかのインスタンスを使用するには、このプールによって作成されたオブジェクトの記録を保持する必要がありました。

したがって、ConcurrentDictionaryに基づいて「レジストリ」が導入されました。ConcurrentDictionaryには、プールとオブジェクト可用性フラグによって作成されたスロットのIDが含まれます（true-「プール内」、false-「プール内にない」）。

これにより、1つの石で2羽の鳥を一度に殺すことができました：同じオブジェクトの誤った多重戻りを防ぐため（スタックは、そこに格納されているオブジェクトの一意性を保証しないため）、別のプールで作成されたオブジェクトの戻りを防ぎます。このアプローチは一時的な解決策でしたが、それを取り除きました。

マルチスレッド

プールの古典的な実装では、セマフォ（.NETではSemaphoreおよびSemaphoreSlim）を使用して、オブジェクトの数または他の同期プリミティブをカウンターと組み合わせて追跡しますが、ConcurrentDictionaryのようなConcurrentStackはスレッドセーフなコレクションなので、オブジェクトの入力/出力を調整する必要はありません。 ConcurrentStack.Countプロパティを呼び出すと、すべての要素の完全な列挙が発生することに注意してください。これにはかなりの時間がかかるため、独自の要素カウンターを追加することにしました。その結果、プールでの2つの「アトミック」操作（PushおよびTryPop）が取得されました。これらに基づいて、他のすべてが構築されました。

簡単な操作の実装

 private void Push(PoolSlot<T> item) { _registry[token.Id] = true; // :  " " _storage.Push(item); //     Interlocked.Increment(ref _currentCount); } private bool TryPop(out PoolSlot<T> item) { if (_storage.TryPop(out item)) //      { Interlocked.Decrement(ref _currentCount); _registry[token.Id] = false; // :  "  " return true; } item = default(PoolSlot<T>); return false; }

既存のオブジェクトの入出力に加えて、新しいオブジェクトを指定された上限に同期して割り当てる必要があります。

ここでは、プール内の要素の最大数（上限）で初期化され、新しいオブジェクトが作成されるたびに1を引くセマフォを適用しますが、問題は、ゼロに達するとフローをブロックすることです。この状況から抜け出す方法は、SemaphoreSlim.Wait（0）メソッドを呼び出すことです。このメソッドは、セマフォの現在の値 "0"を使用して、ほぼ遅延なくfalseを返しますが、この機能の軽量アナログを記述することにしました。これがLockFreeSemaphoreクラスの表示方法であり、遅延なしでゼロに達するとfalseを返します。内部同期の場合、高速のCAS操作Interlocked.CompareExchangeを使用します。

セマフォでCAS操作を使用する例

 public bool TryTake() //  true,     ,  false (   ) { int oldValue, newValue; do { oldValue = _currentCount; //    newValue = oldValue - 1; //    if (newValue < 0) return false; //     0 -  false   } while (Interlocked.CompareExchange(ref _currentCount, newValue, oldValue) != oldValue); //        ,         return true; }

したがって、「オブジェクトを取得する」プール操作は、次のアルゴリズムに従って機能します。

ストレージからオブジェクトを取得しようとしています（存在しない場合）。
セマフォがゼロ（上限に達した）の場合、新しいオブジェクトを作成しようとしています-ポイント3。
最悪のシナリオは、オブジェクトが勝利の終わりに戻ることです。

最初の結果、最適化とリファクタリング

オブジェクトプールが本当に必要ですか？それは状況次第です。「典型的なサーバーオブジェクト」であるSocketAsyncEventArgsを使用して、1024バイトのバッファー（秒単位の時間、プーリングが有効）を使用した小さなテストの結果を次に示します。

新しいプロパティのリクエスト	シングルスレッド、プールなし	シングルスレッド、プール付き	25タスク*、プールなし	25タスク*、プールあり
1,000	0.002	0.003	0.027	0.009
10,000	0.010	0.001	0.272	0.039
25,000	0.030	0.003	0.609	0.189
50,000	0.048	0.006	1.285	0.287
1,000,000	0.959	0.125	27.965	8.345

* task-.NET 4.0以降のTPLライブラリのSystem.Threading.Tasks.Taskクラス

プールを使用したマルチスレッドテストでのプロファイラーVS2012の通過の結果：

ご覧のとおり、すべてはConcurrentStack.TryPopメソッドに依存していますが、これは（想定しているように）加速する場所がありません。 2番目は、「レジストリ」への訴えであり、両方の業務で約14％を選択しています。

原則として、プール内の2番目のコレクションのサポートは、とにかく松葉杖のように見えたため、「プール内/プール内ではない」という記号がスロット自体に転送され、レジストリは安全に削除されました。リファクタリング後のテスト結果（予想どおりの成長、30〜40％）：

新しいプロパティのリクエスト	プール付きの25のタスク
25,000	0.098
1,000,000	5.751

ここでやめることができると思います。

おわりに

タスクがどのように解決されたかを簡単に思い出してください。

コンパイル段階での型安全性-ジェネリッククラスの使用。
クラスのあるプールの動作は、継承なしの汎用シェルの使用です。
使いやすさは、usingコンストラクト（IDisposableインターフェイスのシェルによる実装）です。
新しいオブジェクトの自動選択は、抽象的なPool.ObjectConstructorメソッドです。このメソッドでは、オブジェクトが好きなように初期化されます。
オブジェクトの数を制限することは、セマフォの軽量バージョンです。
オブジェクトが返されたときにオブジェクトを自動クリーニングするのは、仮想Pool.CleanUpメソッドです。このメソッドは、プールが返されたときに自動的に呼び出されます。
スレッドセーフティ-ConcurrentStackおよびCAS操作（Interlockedクラスのメソッド）のコレクションを使用します。
複数のプールインスタンスのサポート— Poolクラスは静的ではなく、シングルトンではなく、操作の有効性チェックを提供します。

単体テストとテストアプリケーションを含むソースコード： Github

興味があれば、このプールが書かれたばかりの非同期TCPおよびUDPソケットサーバーを実装することで、記事を続けることができます。

C＃オブジェクトプールの実装