问题标签 [pooling]

我已经开发了一个“对象池”，如果不使用 Thread.Sleep() 似乎无法做到这一点，我认为这是“不好的做法”。

这与我的另一个问题“是否有在.net 中实现专有连接池的标准方法？ ”有关。对象池背后的想法类似于用于数据库连接的连接池背后的想法。但是，就我而言，我使用它来共享标准 ASP.NET Web 服务（在 IIS6 中运行）中的有限资源。这意味着许多线程将请求访问此有限资源。池将抛出这些对象（“获取”），一旦所有可用的池对象都被使用，下一个请求的线程将简单地等待一段时间，以使这些对象中的一个再次可用（线程会这样做一次“放置”对象）。如果对象在此设定时间内不可用，则会发生超时错误。

这是代码：

要使用它，可以执行以下操作：

现在我的问题是：我该如何写才能摆脱 Thread.Sleep()？

（我为什么要这样做是因为我怀疑它是导致我在测试中遇到的“错误”超时的原因。我的测试应用程序有一个对象池，其中包含 3 个对象。它启动 12 个线程，每个线程得到从池中获取对象 100 次。如果线程从池中获取对象，它将保持 if 2,000 毫秒，如果没有，则进入下一次迭代。现在逻辑表明 9 个线程将等待对象在任何时间点。9 x 2,000 毫秒是 18,000 毫秒，这是任何线程应该等待对象的最长时间。我的获取超时设置为 60,000 毫秒，因此任何线程都不应该超时。但是有些这样做是错了，我怀疑它是 Thread.Sleep）

我正在使用 Hibernate 3，我遇到了与关闭连接相关的问题。

我正在使用 c3p0-0.9.1.2.jar 并检查了 Hibernate 打开的与数据库服务器的连接，我发现已经建立了 5 个连接；在服务器的一些 TCP 端口（见下面的日志）。

但是这些已建立的连接会不断更改它们建立的 TCP 端口，从而释放它们使用的较早端口，使这些端口处于 TIME_WAIT 状态（而不是关闭它们）。

这继续进行，数以百计；对于 TIME_WAIT 条件下的连接。

我不确定发生了什么以及为什么端口从已建立切换到 TIME_WAIT 并且之前的端口都没有关闭。

下面是通过运行 NETSTAT -ano|find "x.9" 获取的示例，其中 x.9 是数据库服务器 IP。

我使用的 Hibernate.properties 文件。

感谢帮助。

Tomcat 6 下的 Servlet 101：

有人可以向我指出一个很好的解释，例如最好的方法。在 servlet 启动时创建一个昂贵的 Foo 对象的集合，并将它们存储在我可以在处理每个请求时访问它们的地方？

据我所知，至少有三种方法可以做到这一点，我对区别有点模糊。我不关心集群或算法来驱逐过时的条目或类似的东西，只是基础知识。

干杯和感谢。

我一直在寻找在我的应用程序的一部分中实现池化。我想使用 Commons Pool 库，但有点担心这种close()行为是如何工作的。从查看 javadocs 和源代码来看，似乎并不清楚在close()调用该方法时是否会销毁池中创建的对象。据我所知，只有池中空闲的对象才会被销毁——任何正在使用但尚未返回的对象都不会被触及。

我在这里错过了什么吗？我想确保在池关闭时所有对象都被正确销毁。

有人以前用过这个并且知道它是如何工作的吗？

使用 EJB 的实例池如何提高性能？难道您不能仅使用 java servlet 之类的线程来实现相同的性能吗？

或者可能是出于其他原因使用 EJB 进行实例池？

我们开发了一个通过 IBM Websphere MQ 进行通信的自定义 WCF 通道。

我们创建了一个通道工厂：

它返回我们频道的实例：

连接到 IBM MQ 队列管理器是一项昂贵的操作。目前，我们在 Channel.OnOpen() 中执行此操作。

遵循正确使用通道的指南，我们每次需要通道时调用 ChannelFactory.CreateChannel()，发送消息，然后调用 Channel.Close()。

我们的假设是，ChannelFactory 执行了通道池，因此当 Channel.Close() 被调用时，通道实际上并没有关闭，而是返回到池中。但是，每次我们调用 ChannelFactory.CreateChannel 时，都会实例化一个新的通道，并且在发送请求时，会执行昂贵的通道打开。

所以，问题是：防止在每个请求上打开通道的最佳方法是什么？

我们正在研究的一些选项：

• 无论如何通过配置来指定应该进行通道池吗？我们是否应该在 ChannelFactory 中实现自己的通道池？

• 我们是否应该在应用程序的整个生命周期内保持通道打开，通过它发送所有请求？

• 我们是否应该在通道工厂中执行昂贵的操作（连接到队列管理器），我们在应用程序的生命周期中缓存这些操作？

我需要实现一个由外部系统返回的会话池，以便在需要时可以快速重用它们（创建会话需要一段时间）。我使用数据源创建了一个数据库连接池（来自 Apache 的 DBCP），这是一个已实现的解决方案。

在一般情况下，我们使用什么来池化任意对象，是否有已实现的解决方案（即对象，而不是接口）来痛苦地处理任务？

第二个问题是，我们如何测试 Session 是否存在？是否有我们在对象池中覆盖的特定方法来查询 Session 自己的方法？

第三个非常重要的问题是，对象池对象应该是静态的吗？我从系统中提取的一组对象必须在不同的 Web 应用程序之间共享。所以，比如说，我们提取 5 个会话。App A 查询 POOL 并获取第一个可用的 Session。现在还剩下 4 个会话。另一个 App B 启动并查询 THE SAME POOL。等 游泳池是共享的。在同一台机器上运行的同一 Web 应用程序的不同实例中。

阅读 s 的SendAsync方法BeginAsync说明Socket，我意识到有人建议将SocketAsyncEventArgs实例池化，说它比 BeginXX、EndXX 异步方法更好，因为每个调用都会创建一个IAsyncResult实例。

我认为汇集可以轻松实例化的对象（例如SocketAsyncEventArgs）并不是一个好习惯。对象分配非常快，并且 GC 被优化以有效地处理短期对象。我尝试实现一个池化机制来看看它是如何执行的，实际上在简单对象上分配更快，这些对象除了将一些数据封装在 ctor 中之外什么都不做。（嗯，这就像通过发送数十亿条SELECT 1语句来分析 DBMS，这就是我在这里的原因。）

我不是在问哪个更好，我相信分析实际应用程序会产生答案，但只是对汇集简单的短期对象的好处感到好奇。更好的 GC 性能？内存碎片少？在设计时是否值得考虑？

来自MSDN

这些增强的主要特点是避免在大容量异步套接字 I/O 期间重复分配和同步对象。目前由 System.Net.Sockets.Socket 类实现的 Begin/End 设计模式要求为每个异步套接字操作分配一个 System.IAsyncResult 对象。

在新的 System.Net.Sockets.Socket 类增强中，异步套接字操作由应用程序分配和维护的可重用 SocketAsyncEventArgs 对象描述。高性能套接字应用程序最清楚必须维持的重叠套接字操作的数量。应用程序可以创建所需的任意数量的 SocketAsyncEventArgs 对象。例如，如果服务器应用程序需要始终有 15 个未完成的套接字接受操作以支持传入的客户端连接速率，则它可以为此目的分配 15 个可重用的 SocketAsyncEventArgs 对象。

谢谢。

有没有人有很好的资源来为 Sql 连接池的有限资源实施共享对象池策略？（即完全实现它是线程安全的）。

为了跟进@Aaronaught 澄清请求，池的使用将用于对外部服务的负载平衡请求。把它放在一个可能比我直接的情况更容易立即理解的场景中。我有一个会话对象，其功能类似于ISessionNHibernate 中的对象。每个唯一会话都管理它与数据库的连接。目前我有 1 个长时间运行的会话对象，并且遇到了我的服务提供商限制我对这个单独会话的使用率的问题。

由于他们不期望单个会话将被视为长期运行的服务帐户，因此他们显然将其视为正在打击其服务的客户。这让我想到了这里的问题，我将创建一个不同会话池，并将请求拆分到多个会话中的服务，而不是像以前那样创建一个焦点，而不是创建一个单独的会话。

希望背景提供一些价值，但直接回答您的一些问题：

问：创建对象是否昂贵？
答：没有对象是有限资源池

问：它们会被非常频繁地收购/发布吗？
A:是的，他们可以再次被认为是 NHibernate ISessions，其中 1 通常在每个单个页面请求的持续时间内被获取和释放。

问：简单的先到先得就足够了，还是您需要更智能的东西，即可以防止饥饿？
答：一个简单的循环类型分发就足够了，我假设你的意思是如果没有可用的会话，调用者会被阻塞等待发布。这实际上并不适用，因为会话可以由不同的呼叫者共享。我的目标是在多个会话中分配使用，而不是 1 个会话。

我相信这可能与对象池的正常使用有所不同，这就是为什么我最初忽略了这部分并计划只是调整模式以允许共享对象，而不是让饥饿情况发生。

问：优先级、延迟加载与急切加载等问题呢？
答：不涉及优先级，为了简单起见，假设我将在创建池本身时创建可用对象池。

何时使用 C# 进行对象池？任何好的前...

维护一个经常使用的对象池并从池中获取一个而不是创建一个新对象的优点和缺点是什么？