Почему этот класс должен отслеживать слабые ссылки?

Question

Я пытаюсь разобраться в том, что кажется утечкой памяти в приложении VB.NET клиента VB.NET (мы не писали код).

Две вещи выскочить на меня:

1. Они имеют узел доступа к данным с классом доступа одного данных, который, когда экземпляр пробегов этот код в конструкторе:

   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 показывают, что это в сборке доступа к данным сборки выпуска.

2. Копаем о с 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 32bit Standard SP2
• Приложение написано в ASP.NET 2.0 (Веб-формы, а не MVC)
• .NET 2.0 полностью исправлен до SP2 (через обновление .NET 3.5 SP1).
• Файл подкачки будет расти до 4 ГБ (рекомендуется макс я где-то читал)

• приложение не используется набор Infragistics Web управления (v10.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

Признаки исключений из памяти, когда мы видим виртуальные байты для процесса, достигающего ~ 2 ГБ, а частные байты - около 900 МБ.

На сервере <deployment retail="true" /> configured in machine.config`.

Сборка выполнена в сборе и debug="false установлена ​​в разделе <compilation/>.

Любой совет будет полезен.

Answer 1

Чтобы ответить на ваш первый вопрос, слабые ссылки используются для хранения ссылки на объект, не мешая тому, чтобы этот объект не был собран в мусор. В этом случае представляется, что они поддерживают список всех экземпляров класса Server. Такой список должен будет использовать слабые ссылки, поскольку в противном случае экземпляры этого класса никогда не будут удалены после создания, если только они не были удалены из этого списка. То, что они используют этот список экземпляров, я не могу сказать, не видя остальную часть кода, но они могут делать какие-то кэширование или объединение пулов (хотя позже было бы плохо, потому что ado.net уже делает это для вас).

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

Что касается вашего второго вопроса, я не знаю, сколько объектов MethodInfo являются нормальными для этого типа среды. Тем не менее, я помню, как читал во время .Net 2.0, что объекты отражения никогда не выгружаются после того, как они запрашиваются в пределах данного домена приложения. Насколько я знаю, это не изменилось. Но поскольку среда выполнения создаст не более одного такого объекта для каждого уникального метода, это вряд ли будет проблемой, если они не используют какое-то генерирование кода времени исполнения. В противном случае максимальное количество таких объектов, которые могут быть созданы, будет ограничено количеством методов в сборках, используемых приложением.