Chr*_*ruk 8 architecture singleton design-patterns object-pooling
我不一定意味着使用单例模式实现,而是仅使用和使用一个池实例.我不喜欢只有一个池(或每个池类型一个)的想法.但是,我无法真正想出任何具有可变类型的多个池的优点的具体情况,至少不是单个池可以正常运行的任何地方.
单个池上有多个池有什么优点？
与单个池相比，拥有多个池有什么优势？
我认为我们使用的大多数对象池（例如 ThreadPool）为了简单起见都被实现为单例：在这种情况下，这些池的设计者也没有看到多实例池的用途。
然而，有一些地方我们确实拥有多个池：IIS 应用程序池和数据库连接池。
应用程序池
在IIS中，您可以配置多个应用程序池，以便相关的Web应用程序都在自己的池中运行。这种设计有几个优点，并且这些优点可以推广到 IIS 之外的池实现：
多个对象池允许某种程度的隔离，因此一个池中的错误不应影响其他池中的对象。
每个池可以在不同的用户下运行，这根据您的应用程序池为您提供不同级别的安全性。
每个池可以有不同的错误处理程序。
每个池都可以使用不同版本的 .NET 框架运行。
每个池都可以有自己的 HTTP 超时。
连接池
在 SQL Server 中，对数据库的多次调用使用连接池来避免在每个查询上创建新数据库连接的开销，但是 SQL Server会为每个连接字符串创建一个新池。我想这个设计背后的基本原理如下：
每个池都拥有与特定数据库实例的连接。如果只有一个池包含所有连接，那么它将需要搜索所有连接，直到找到与您请求的连接字符串匹配的连接。由于每个连接字符串有多个池，因此更容易从该特定池中提取第一个可用连接，而无需搜索其他连接。
换句话说，我怀疑SQL Server使用多个连接池作为优化来快速获取数据库连接。
我还可以想象，所有这些连接可能共享一些特定于其连接池的资源，这对于单个池来说可能是不可能的。例如，您可以指定每个连接字符串的最大连接池大小；您可能无法使用单池设计来控制与特定数据库的同时连接数。
如何设计一个水池
如果不考虑设计中的真正需求，您就无法真正选择是拥有多个池还是单个池。
如果您有一个非常简单的对象池，您可能可以摆脱单例设计。如果您确实需要额外的灵活性、自定义，或者您可能有一个真正独特的设置，例如分布在多个进程或机器上的对象池，那么您肯定会从 n-gleton 设计中受益。