NHibernate создает прокси через сессию. Загрузка (), но не через Linq или Criteria API

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

то, Что Вы видите в.NET, не является утечками памяти, но возражает, что никогда не располагаются. Объект не будет расположен, пока сборщик "мусора" может найти его на графе объектов. Таким образом, если какой-либо живущий объект где-нибудь будет иметь ссылку на объект, то он не будет расположен.

регистрация События является хорошим способом заставить это произойти. Если объект регистрируется для события, независимо от того, что он зарегистрировался в, имеет ссылку на него, и даже если Вы устраняете любую ссылку на объект, пока он не не регистрируется (или объект, в котором он зарегистрировался, становится недостижимым), он останется в живых.

, Таким образом, необходимо не упустить объекты, которые регистрируются для статических событий без ведома. Изящная функция эти ToolStrip, например, то, что при изменении темы дисплея она автоматически восстановит изображение в новой теме. Это выполняет эту изящную функцию путем регистрации для помех SystemEvents.UserPreferenceChanged событие. При изменении темы Windows событие генерируется, и весь из ToolStrip, объекты, которые слушают событие, уведомляются, что существует новая тема.

Хорошо, поэтому предположите, что Вы решаете выбросить ToolStrip на Вашей форме:

private void DiscardMyToolstrip()
{
    Controls.Remove("MyToolStrip");
}

Вы теперь имеете ToolStrip, который никогда не будет умирать. Даже при том, что это больше не находится на Вашей форме, каждый раз, когда пользовательский Windows тем изменений покорно скажет иначе несуществующее ToolStrip об этом. Каждый раз выполнения сборщика "мусора", это думает, что "Я не могу выбросить тот объект, UserPreferenceChanged, событие использует его".

Это не утечка памяти. Но это могло бы также быть.

Вещи как это делают профилировщика памяти неоценимым. Выполните профилировщика памяти, и Вы скажете, что "это нечетно, кажется, существует десять тысяч ToolStrip объекты на "куче", даже при том, что существует только один на моей форме. Как это происходило?"

, О, и в случае, если Вы задаетесь вопросом, почему некоторые люди думают, методы set свойства являются злыми: чтобы заставить ToolStrip не регистрироваться от UserPreferenceChanged событие, установите Visible свойство к [1 112].