Есть ли какая-то причина, по которой объектный пул не следует рассматривать как одноэлементный?

Question

Я не обязательно имею в виду реализацию с использованием шаблона синглтона, а только использование и использование одного экземпляра пула. Мне не нравится идея иметь только один пул (или по одному на пул типа). Тем не менее, я не могу придумать какие-либо конкретные ситуации, когда есть преимущество для нескольких пулов для изменяемых типов , по крайней мере, не для тех, где отдельный пул может работать так же хорошо.

Какие преимущества дает наличие нескольких пулов над одним пулом?

Answer 1

Да, безусловно, существуют потенциальные причины наличия нескольких пулов объектов - в частности, вы можете позволить одному пулу получить право на сборку мусора (или вручную освободить его и т. Д.) При сохранении других.

Например, рассмотрим пул объектов для строк. Это может быть очень удобно в контексте XML - если вы анализируете несколько XML-документов одной и той же схемы, вы, возможно, захотите объединить строки, используемые для имен элементов и атрибутов. Однако, как только вы закончите эту часть обработки этих имен, вы больше никогда не сможете их использовать - так что при переходе к другому набору документов вы можете захотеть использовать другой пул. Вы можете выполнить обе задачи одновременно, и в этом случае будет полезно иметь оба пула одновременно.

Или рассмотрим пулы потоков - я считаю недостатком реализации пула потоков .NET, что в основном есть только один системный пул потоков. Мне нравится идея иметь возможность иметь несколько пулов потоков на сервере - некоторые потоки для пакетных заданий с низким приоритетом, некоторые для «обычных» запросов и несколько потоков с высоким приоритетом для таких задач, как мониторинг работоспособности.

Answer 2

Какие преимущества имеют несколько пулов над одним пулом?

Я предположил, что большинство пулов объектов, которые мы используем, например ThreadPool, для простоты реализованы как синглтоны: в этом дизайнеры этих пулов также не видели цели в пулах с несколькими экземплярами.

Однако есть несколько мест, где у нас действительно есть несколько пулов: пулы приложений IIS и пулы соединений с базами данных.

Пулы приложений

В IIS вы можете настроить несколько пулов приложений, чтобы все связанные веб-приложения работали в своем собственном пуле. У этой конструкции есть несколько преимуществ, и эти преимущества можно обобщить для реализации пула вне IIS:

• Несколько пулов объектов допускают некоторую степень изоляции, поэтому ошибка в одном пуле не должна влиять на объекты в других пулах.

• Каждый пул может работать под своим пользователем, что обеспечивает разные уровни безопасности в зависимости от пула приложений.

• В каждом пуле может быть свой обработчик ошибок.

• Каждый пул может работать с другой версией .NET Framework.

• Каждый пул может иметь собственный тайм-аут HTTP.

Пулы соединений

В SQL Server несколько вызовов к базе данных используют пул соединений, чтобы избежать затрат на создание нового соединения с базой данных при каждом запросе, однако SQL Server создает новый пул для каждой строки соединения . Я полагаю, что обоснование этого дизайна заключается в следующем:

• Каждый пул содержит соединение с конкретным экземпляром базы данных. Если бы был только один пул, содержащий все соединения, то ему потребовался бы поиск по всем соединениям, пока он не найдет соединение, соответствующее запрашиваемой строке соединения. Поскольку в строке подключения имеется несколько пулов, проще извлечь первое доступное соединение из этого конкретного пула без поиска других соединений.

• Другими словами, я подозреваю, что SQL Server использует несколько пулов соединений в качестве оптимизации для быстрого захвата соединения с базой данных.

• Я также могу представить, что все эти соединения, вероятно, совместно используют некоторые ресурсы, специфичные для их пула соединений, что может быть невозможно для одного пула. Например, вы можете указать максимальный размер пула соединений для каждой строки соединения; Возможно, вы не сможете контролировать количество одновременных подключений к конкретной базе данных, используя схему с одним пулом.

Как спроектировать бассейн

Вы не можете выбрать, использовать ли несколько пулов или один пул, не взглянув на то, что вам действительно нужно из вашего дизайна.

Если у вас очень простой пул объектов, вам, возможно, удастся сойтись с одноэлементным дизайном. Если вам действительно нужна дополнительная гибкость, настройка или, возможно, у вас есть действительно уникальная настройка, например, пул объектов, распределенный по нескольким процессам или машинам, вам определенно будет полезен дизайн n-gleton.

Answer 3

Если вы тщательно реализуете шаблон синглтона, вы можете передумать позже. Просто заключите в единый элемент вашего класса метод фабрики. Если все используют это, то вы можете позволить этому иметь несколько экземпляров позже, когда у вас есть веская причина.

public class MyClass
{
    public static MyClass GetInstance()
    {
          return singleton_ ?? (singleton = new MyClass());
    }
}