這個班級爲什麼要追蹤弱引用？

我試圖找到什麼似乎是客戶的VB.NET ASP.NET應用程序中的內存泄漏（我們沒有寫代碼）的底部。這個班級爲什麼要追蹤弱引用？

兩件事情在我跳出：

他們與該實例運行時，該代碼在構造一個數據訪問類數據訪問組件：
```
public SqlServer(string connString) 
{ 
    List<WeakReference> list = __ENCList; 
    lock (list) 
    { 
     __ENCList.Add(new WeakReference(this)); 
    } 
    // misc other tasks of no further interest 
} 
```
__ENCList聲明如：private static List<WeakReference> __ENCList;上課。

這背後的意圖是什麼？我確實在某處閱讀過VB.NET將其用於編輯和繼續的目的，但是瞭解它不會在發佈版本中生成。 .NET Reflector和ILDASM都顯示這是在生產版本構建數據訪問程序集中。
使用WinDbg挖約而做一個!dumpheap -stat我看到這一點：

 
66101820 10269  451836 System.Web.UI.Control+OccasionalFields 
7a5eecbc 22936  458720 System.Collections.Specialized.ListDictionary+DictionaryNode 
79331754  2285  470684 System.Char[] 
648c91f4 10438  501024 System.Configuration.ConfigurationValues 
7a5e9eb0 37978  607648 System.Collections.Specialized.NameObjectCollectionBase+NameObjectEntry 
648c9434 32651  653020 System.Configuration.ConfigurationValue 
7a5e27a0  6567  788040 System.ComponentModel.ReflectPropertyDescriptor 
7932ea08 18318  879264 System.Signature 
79332b54 42528  1020672 System.Collections.ArrayList 
79333178 18348  1027488 System.Collections.Hashtable 
79332cc0  7535  1346108 System.Int32[] 
7932dd5c 43220  2420320 System.Reflection.RuntimePropertyInfo 
7932fde0 72902  4082512 System.Reflection.RuntimeMethodInfo 
79333274 19162  4321680 System.Collections.Hashtable+bucket[] 
79333594  3475  4638780 System.Byte[] 
793042f4 134867  6473100 System.Object[] 
000f6f80  394  24556172  Free 
79330b24 174120  26678884 System.String 
Total 1098618 objects 
Fragmented blocks larger than 0.5 MB: 
    Addr  Size  Followed by 
33b7b58c 2.1MB   33d99cf4 System.Data.ProviderBase.DbConnectionClosedBusy 
41635a50 0.6MB   416c873c System.Data.ProviderBase.DbConnectionClosedBusy

那是一個非常高的數字System.Reflection.RuntimeMethodInfo的對象？

服務器有49個站點在單個應用程序池中運行。
所有站點是相同的（每個人都是品牌重塑網站）
在每個站點的/bin文件夾中的二進制文件是相同
服務器運行的是Windows 2003的32位標準SP2
的應用程序是用ASP.NET 2.0（Web窗體，而不是MVC）
.NET 2.0完全修補到SP2（通過.NET 3.5 SP1更新）。
分頁文件設置將增長至4GB（最高推薦我讀的地方）
該應用程序使用Infragistics的Web控件套件（10.2）：

Infragistics35.Web.v10.2。 dll的
Infragistics35.WebUI.Shared.v10.2.dll
Infragistics35.WebUI.UltraWebGrid.v10.2.dll
Infragistics35.WebUI.UltraWebTab.v10.2.dll
Infragistics35.WebUI.WebDataInput.v10。 2.dll

症狀是內存不足異常，當我們看到虛擬字節的進程命中~2GB和私人字節命中900MB左右。

服務器有<deployment retail="true" /> configured in machine.config`。

該版本是發佈版本，並在<compilation/>部分配置了debug="false套件。

任何建議將是有用的。

來源

2010-11-07 Kev

要回答你的第一個問題，弱引用用於保存對對象的引用，而不阻止垃圾收集對象。在這種情況下，看起來他們正在維護一個Server類的所有實例的列表。這樣的列表需要使用弱引用，否則該類的任何實例一旦創建就不會被刪除，除非它們先從列表中刪除。他們使用那些實例列表我不能說沒有看到其餘的代碼，但他們可能正在做某種緩存或連接池（儘管後來會不好，因爲ado.net已經爲你做了這個）。

此外，知道弱引用本身是對象，所以除非不再引用活動對象的引用從列表中刪除，否則它們將導致內存泄漏。但是，它們是小對象，並且除非創建了大量的服務器實例，否則不會導致問題。

至於你的第二個問題，我不知道這種類型的環境有多少個MethodInfo對象是正常的。不過，我確實記得在.Net 2.0的日子裏讀到反射對象在給定的應用程序域內被請求後永遠不會被卸載。據我所知，這並沒有改變。但是，由於運行時每個唯一方法最多隻能創建一個這樣的對象，除非他們使用某種運行時代碼生成，否則這不太可能成爲問題。否則，可以創建的這些對象的最大數量將被限制爲應用程序使用的程序集中的方法數量。

來源

2010-11-07 17:46:49 Nimrand

感謝您的回覆。弱參考跟蹤是一點紅鯡魚。儘管疲弱的參考物體在記憶中懸停，但它們的數量很少。此外，它看起來像代碼是一些舊的VB.NET組件的artefact。我要求開發人員去除皮帶和支架。看起來真正的原因是在同一個應用程序池中有49個應用程序。 infragistics控制沒有幫助，因爲這些往往是真正的記憶豬。我們將這些網站分成四個應用程序池，我們的內存壓力問題自然而然地解決了。 – Kev 2010-11-09 15:09:59

現在我們看到每個應用程序池大約900MB/600MB（大約）的虛擬/專用字節高峯，然後當網站很安靜時，我們看到內存被釋放。無論如何感謝詳細的答案和+1。 – Kev 2010-11-09 15:11:58

這個班級爲什麼要追蹤弱引用？

回答

相關問題