什麼時候進行對象池化？

Question

何時使用C＃進行對象池？任何好的前...

什麼是pro和con的維護一個經常使用的對象池，從池中取一個而不是創建一個新的？

Answer 1

只有兩種類型的資源我能想到，通常是合併的：線程和連接（即數據庫）。

這兩個都有一個首要問題：缺乏。

• 如果創建了太多的線程，上下文切換會浪費掉所有的CPU時間。
• 如果創建了太多的網絡連接，維護這些連接的開銷比任何連接所要做的都要多。
• 另外，對於數據庫，由於授權原因，連接數可能會受到限制。

因此，您希望創建資源池的主要原因是，如果您只能負擔在任何時候都有限的數量。

Answer 2

1. 當對象的創建是昂貴
2. 當你可能會遇到內存壓力 - 太多的對象（例如 - 享元模式）

Answer 3

我想補充內存碎片到列表中。在使用封裝本地資源的對象時，可能會發生這種情況，這些資源在分配之後無法由垃圾收集器移動並可能將堆碎片化。

一個現實生活中的例子是當你創建並銷燬大量的套接字時。他們用來讀/寫數據的緩衝區必須被固定，才能被傳送到本地WinSock API，這意味着當發生垃圾收集時，即使某些內存被銷燬的套接字回收 - 它可能會使內存處於碎片狀態，因爲GC無法在收集後壓縮堆。因此，讀/寫緩衝區是池的主要候選者。另外，如果你使用SocketEventArgs對象，那些對象也是很好的選擇。

這是一個good article，它討論垃圾收集過程，內存壓縮以及爲什麼對象池有幫助。

Answer 4

有一篇很棒的MSDN雜誌文章，名爲Erik Brown http://msdn.microsoft.com/en-us/magazine/cc163856.aspx，在您的託管代碼中重新發現內存優化的失落藝術。它包含一個帶有測試程序的通用對象池。該對象池確實支持最小和最大尺寸。我找不到任何對使用此功能的人的引用。有沒有人這樣做？另外，在處理ASP.NET應用程序中的內存碎片之後，我可以證明Miky Dinescu的答案中的值。另外，對Vitaly的答案稍作闡述，考慮大型對象（即> 85K）的情況，這些對象的創建成本很高。大對象只參與第2代垃圾收集。這意味着它們不會像完全參與第0代和第1代垃圾收集的對象一樣快速收集。本文Maoni Stephens發現的大對象堆 （http://msdn.microsoft.com/en-us/magazine/cc534993.aspx）詳細解釋了大型對象堆。

Answer 5

對於遊戲GC可能在某些情況下引入不必要的延遲。如果是這種情況，重複使用對象可能是一個好主意。關於this thread中的主題有一些有用的考慮。