Этот вопрос немного сложнее, чем можно было бы ожидать из-за нескольких неизвестных: поведение пулируемого ресурса, ожидаемое / требуемое время жизни объектов, реальная причина, по которой требуется пул, и т. Д. Обычно пулы являются особыми цель - пулы потоков, пулы соединений и т. д. - потому что легче оптимизировать один, когда вы точно знаете, что ресурс делает, и, что более важно, имеете контроль над тем, как этот ресурс реализован.
Поскольку это не так просто, я попытался предложить довольно гибкий подход, с которым вы можете поэкспериментировать и посмотреть, что работает лучше всего. Заранее извиняюсь за длинный пост, но есть много возможностей для реализации, когда дело доходит до реализации достойного пула ресурсов общего назначения. и я действительно только царапаю поверхность.
Пул общего назначения должен иметь несколько основных «настроек», в том числе:
- Стратегия загрузки ресурсов - нетерпеливый или ленивый;
- Загрузка ресурсов механизм - как его создать;
- Стратегия доступа - вы упоминаете «круговой прием», который не так прост, как кажется; эта реализация может использовать циклический буфер, который аналогичен , но не идеален, поскольку пул не контролирует, когда ресурсы фактически возвращаются. Другие варианты - FIFO и LIFO; У FIFO будет больше шаблонов произвольного доступа, но LIFO значительно упрощает реализацию стратегии освобождения с наименьшим количеством использований (о которой вы говорили, что она выходит за рамки, но все же стоит упомянуть).
Для механизма загрузки ресурсов .NET уже дает нам чистую абстракцию - делегаты.
private Func<Pool<T>, T> factory;
Пропустите это через конструктор пула, и мы закончили с этим. Использование универсального типа с ограничением new() также работает, но это более гибко.
Из двух других параметров стратегия доступа является более сложным, поэтому мой подход заключался в использовании подхода на основе наследования (интерфейса):
public class Pool<T> : IDisposable
{
// Other code - we'll come back to this
interface IItemStore
{
T Fetch();
void Store(T item);
int Count { get; }
}
}
Концепция здесь проста - мы позволим общедоступному классу Pool обрабатывать общие проблемы, такие как безопасность потоков, но будем использовать разные «хранилища элементов» для каждого шаблона доступа. LIFO легко представляется стеком, FIFO является очередью, и я использовал не очень оптимизированную, но, вероятно, адекватную реализацию циклического буфера, используя List<T> и указатель индекса, чтобы приблизить схему циклического доступа.
Все перечисленные ниже классы являются внутренними классами Pool<T> - это был выбор стиля, но поскольку они действительно не предназначены для использования вне Pool, это имеет смысл.
class QueueStore : Queue<T>, IItemStore
{
public QueueStore(int capacity) : base(capacity)
{
}
public T Fetch()
{
return Dequeue();
}
public void Store(T item)
{
Enqueue(item);
}
}
class StackStore : Stack<T>, IItemStore
{
public StackStore(int capacity) : base(capacity)
{
}
public T Fetch()
{
return Pop();
}
public void Store(T item)
{
Push(item);
}
}
Это очевидные из них - стек и очередь. Я не думаю, что они действительно заслуживают большого объяснения. Круговой буфер немного сложнее:
class CircularStore : IItemStore
{
private List<Slot> slots;
private int freeSlotCount;
private int position = -1;
public CircularStore(int capacity)
{
slots = new List<Slot>(capacity);
}
public T Fetch()
{
if (Count == 0)
throw new InvalidOperationException("The buffer is empty.");
int startPosition = position;
do
{
Advance();
Slot slot = slots[position];
if (!slot.IsInUse)
{
slot.IsInUse = true;
--freeSlotCount;
return slot.Item;
}
} while (startPosition != position);
throw new InvalidOperationException("No free slots.");
}
public void Store(T item)
{
Slot slot = slots.Find(s => object.Equals(s.Item, item));
if (slot == null)
{
slot = new Slot(item);
slots.Add(slot);
}
slot.IsInUse = false;
++freeSlotCount;
}
public int Count
{
get { return freeSlotCount; }
}
private void Advance()
{
position = (position + 1) % slots.Count;
}
class Slot
{
public Slot(T item)
{
this.Item = item;
}
public T Item { get; private set; }
public bool IsInUse { get; set; }
}
}
Я мог бы выбрать несколько разных подходов, но суть в том, что ресурсы должны быть доступны в том же порядке, в котором они были созданы, что означает, что мы должны поддерживать ссылки на них, но помечать их как «используемые» (или нет). В худшем случае доступен только один слот, и для каждой выборки требуется полная итерация буфера. Это плохо, если у вас есть сотни объединенных ресурсов и вы получаете и выпускаете их несколько раз в секунду; на самом деле не проблема для пула из 5-10 предметов, а в типичном случае , когда ресурсы используются слабо, нужно продвинуть только один или два слота.
Помните, что эти классы являются частными внутренними классами - поэтому им не нужно много проверять ошибки, сам пул ограничивает доступ к ним.
Добавьте перечисление и фабричный метод, и мы закончили с этой частью:
// Outside the pool
public enum AccessMode { FIFO, LIFO, Circular };
private IItemStore itemStore;
// Inside the Pool
private IItemStore CreateItemStore(AccessMode mode, int capacity)
{
switch (mode)
{
case AccessMode.FIFO:
return new QueueStore(capacity);
case AccessMode.LIFO:
return new StackStore(capacity);
default:
Debug.Assert(mode == AccessMode.Circular,
"Invalid AccessMode in CreateItemStore");
return new CircularStore(capacity);
}
}
Следующая проблема, которую нужно решить, это загрузка стратегии. Я определил три типа:
public enum LoadingMode { Eager, Lazy, LazyExpanding };
Первые два должны быть самоочевидными; третье - это своего рода гибрид, оно лениво загружает ресурсы, но фактически не начинает повторно использовать какие-либо ресурсы, пока пул не заполнится. Это было бы хорошим компромиссом, если вы хотите, чтобы пул был заполнен (что звучит так, как вы), но хотите отложить расходы на их фактическое создание до первого доступа (т. Е. Для улучшения времени запуска).
Методы загрузки на самом деле не слишком сложны, теперь у нас есть абстракция хранилища предметов:
private int size;
private int count;
private T AcquireEager()
{
lock (itemStore)
{
return itemStore.Fetch();
}
}
private T AcquireLazy()
{
lock (itemStore)
{
if (itemStore.Count > 0)
{
return itemStore.Fetch();
}
}
Interlocked.Increment(ref count);
return factory(this);
}
private T AcquireLazyExpanding()
{
bool shouldExpand = false;
if (count < size)
{
int newCount = Interlocked.Increment(ref count);
if (newCount <= size)
{
shouldExpand = true;
}
else
{
// Another thread took the last spot - use the store instead
Interlocked.Decrement(ref count);
}
}
if (shouldExpand)
{
return factory(this);
}
else
{
lock (itemStore)
{
return itemStore.Fetch();
}
}
}
private void PreloadItems()
{
for (int i = 0; i < size; i++)
{
T item = factory(this);
itemStore.Store(item);
}
count = size;
}
Приведенные выше поля size и count относятся к максимальному размеру пула и общему количеству ресурсов, которыми владеет пул (но не обязательно доступно ), соответственно. AcquireEager является самым простым, предполагается, что элемент уже находится в магазине - эти элементы будут предварительно загружены при создании, то есть в методе PreloadItems, показанном последним.
AcquireLazy проверяет наличие свободных элементов в пуле, а если нет, то создает новый. AcquireLazyExpanding создаст новый ресурс, если пул еще не достиг целевого размера. Я пытался оптимизировать это, чтобы минимизировать блокировку, и я надеюсь, что не допустил ошибок (я проверил это в многопоточных условиях, но, очевидно, не исчерпывающе).
Вам может быть интересно, почему ни один из этих методов не удосуживается проверить, достиг ли магазин максимального размера. Я вернусь к этому через мгновение.
Теперь для самого бассейна. Вот полный набор личных данных, некоторые из которых уже были показаны:
private bool isDisposed;
private Func<Pool<T>, T> factory;
private LoadingMode loadingMode;
private IItemStore itemStore;
private int size;
private int count;
private Semaphore sync;
Отвечая на вопрос, который я затмил в последнем абзаце - как обеспечить ограничение общего количества созданных ресурсов - оказывается, что в .NET уже есть совершенно хороший инструмент для этого, он называется Семафор и он разработан специально для того, чтобы разрешить фиксированному количеству потоков доступ к ресурсу (в этом случае «ресурс» является внутренним хранилищем элементов). Поскольку мы не внедряем полную очередь производителей / потребителей, это вполне соответствует нашим потребностям.
Конструктор выглядит так:
public Pool(int size, Func<Pool<T>, T> factory,
LoadingMode loadingMode, AccessMode accessMode)
{
if (size <= 0)
throw new ArgumentOutOfRangeException("size", size,
"Argument 'size' must be greater than zero.");
if (factory == null)
throw new ArgumentNullException("factory");
this.size = size;
this.factory = factory;
sync = new Semaphore(size, size);
this.loadingMode = loadingMode;
this.itemStore = CreateItemStore(accessMode, size);
if (loadingMode == LoadingMode.Eager)
{
PreloadItems();
}
}
Здесь не должно быть сюрпризов. Единственное, на что следует обратить внимание - это специальный корпус для быстрой загрузки с использованием метода PreloadItems, уже показанного ранее.
Поскольку к настоящему моменту практически все абстрагировано, реальные методы Acquire и Release действительно очень просты:
public T Acquire()
{
sync.WaitOne();
switch (loadingMode)
{
case LoadingMode.Eager:
return AcquireEager();
case LoadingMode.Lazy:
return AcquireLazy();
default:
Debug.Assert(loadingMode == LoadingMode.LazyExpanding,
"Unknown LoadingMode encountered in Acquire method.");
return AcquireLazyExpanding();
}
}
public void Release(T item)
{
lock (itemStore)
{
itemStore.Store(item);
}
sync.Release();
}
Как объяснено ранее, мы используем Semaphore для управления параллелизмом вместо религиозной проверки состояния хранилища элементов. Пока приобретенные предметы правильно выпущены, беспокоиться не о чем.
Не в последнюю очередь, есть очистка:
public void Dispose()
{
if (isDisposed)
{
return;
}
isDisposed = true;
if (typeof(IDisposable).IsAssignableFrom(typeof(T)))
{
lock (itemStore)
{
while (itemStore.Count > 0)
{
IDisposable disposable = (IDisposable)itemStore.Fetch();
disposable.Dispose();
}
}
}
sync.Close();
}
public bool IsDisposed
{
get { return isDisposed; }
}
Цель этого свойства IsDisposed станет ясна через мгновение. Все, что на самом деле делает основной метод Dispose, - это удаляет фактически объединенные элементы, если они реализуют IDisposable.
Теперь вы можете в основном использовать это как есть, с блоком try-finally, но мне не нравится этот синтаксис, потому что если вы начнете передавать объединенные ресурсы между классами и методами, это будет очень запутанным. Возможно, что у основного класса, который использует ресурс, даже нет ссылки на пул. Это действительно становится довольно грязным, поэтому лучше создать «умный» объект из пула.
Допустим, мы начнем со следующего простого интерфейса / класса:
public interface IFoo : IDisposable
{
void Test();
}
public class Foo : IFoo
{
private static int count = 0;
private int num;
public Foo()
{
num = Interlocked.Increment(ref count);
}
public void Dispose()
{
Console.WriteLine("Goodbye from Foo #{0}", num);
}
public void Test()
{
Console.WriteLine("Hello from Foo #{0}", num);
}
}
Вот наш притворный одноразовый ресурс Foo, который реализует IFoo и имеет некоторый шаблонный код для генерации уникальных идентификаторов. Что мы делаем, так это создаем еще один особый объект из пула:
public class PooledFoo : IFoo
{
private Foo internalFoo;
private Pool<IFoo> pool;
public PooledFoo(Pool<IFoo> pool)
{
if (pool == null)
throw new ArgumentNullException("pool");
this.pool = pool;
this.internalFoo = new Foo();
}
public void Dispose()
{
if (pool.IsDisposed)
{
internalFoo.Dispose();
}
else
{
pool.Release(this);
}
}
public void Test()
{
internalFoo.Test();
}
}
Это просто передает все "настоящие" методы к его внутреннему IFoo (мы могли бы сделать это с помощью библиотеки динамического прокси, такой как Castle, но я не буду вдаваться в подробности). Он также поддерживает ссылку на Pool, которая его создает, поэтому, когда мы Dispose этот объект, он автоматически выпускает себя обратно в пул. За исключением , когда пул уже был удален - это означает, что мы находимся в режиме "очистки", и в этом случае он фактически вместо этого очищает внутренний ресурс .
Используя описанный выше подход, мы получаем код, подобный следующему:
// Create the pool early
Pool<IFoo> pool = new Pool<IFoo>(PoolSize, p => new PooledFoo(p),
LoadingMode.Lazy, AccessMode.Circular);
// Sometime later on...
using (IFoo foo = pool.Acquire())
{
foo.Test();
}
Это очень хорошая вещь, которую можно сделать. Это означает, что код, который использует IFoo (в отличие от кода, который его создает), на самом деле не должен знать о пуле. Вы даже можете внедрять IFoo объекты, используя вашу любимую библиотеку DI и Pool<T> в качестве поставщика / фабрики.
Я поместил полный код в PasteBin для вашего удобства копирования и вставки. Есть также короткая тестовая программа , которую вы можете использовать для работы с различными режимами загрузки / доступа и многопоточными условиями, чтобы убедиться, что она поточно-безопасна и не глючит.
Дайте мне знать, если у вас есть какие-либо вопросы или сомнения по этому поводу.