Утечка памяти причины циклических ссылок?
Слишком поздно, чтобы ответить, но я столкнулся с такой же ситуацией, чтобы оценить выражение в java, это может помочь кому-то
MVEL выполнять вычисления времени выполнения, мы можем написать java-код в String чтобы получить его в этом.
String expressionStr = "x+y";
Map<String, Object> vars = new HashMap<String, Object>();
vars.put("x", 10);
vars.put("y", 20);
ExecutableStatement statement = (ExecutableStatement) MVEL.compileExpression(expressionStr);
Object result = MVEL.executeExpression(statement, vars);
5 ответов
Большой вопрос!
нет, Обе формы будут (может быть), GC'd, потому что GC непосредственно не ищет ссылки в других ссылках. Это только ищет то, что называют "Корневыми" ссылками... Это включает ссылочные переменные в стек, (Переменная находится на стеке, фактический объект находится, конечно, на "куче"), ссылочные переменные в регистрах ЦП и ссылочные переменные, которые являются статическими полями в классах...
ко Всем другим ссылочным переменным только получают доступ (и GC'd), если на них сошлются в свойстве одного из "корневых" ссылочных объектов, найденных вышеупомянутым процессом... (или в объекте, на который ссылается ссылка в корневом объекте, и т.д....)
Поэтому, только если на одну из форм ссылаются где-то в другом месте в "корневой" ссылке - Тогда, то обе формы будут безопасны от GC.
только способ, которым я могу думать для "доказывания" его, (не используя утилиты трассировки памяти) состоял бы в том, чтобы создать пару сто тысяч из этих форм, в цикле в методе, тогда, в то время как в методе, посмотрите на объем потребляемой памяти приложения, затем выйдите из метода, назовите GC и посмотрите на место снова.
Сборка "мусора" работает путем отслеживания корневых каталогов приложения. Корневые каталоги приложения являются местами хранения, которые содержат ссылки на объекты на управляемой "куче" (или на пустой указатель). В.NET корни
- Ссылки на глобальные объекты
- Ссылки на статические объекты
- Ссылки на статические поля
- Ссылки на стеке к локальным объектам
- , Ссылки на стеке к параметрам объекта передали методам
- Ссылки на объекты, ожидающие, чтобы быть завершенными
- Ссылки в регистрах ЦП к объектам на управляемой "куче"
, список активных корней ведется CLR. Сборщик "мусора" работает путем рассмотрения объектов на управляемой "куче" и наблюдения, которые все еще доступны приложением, то есть, доступны через корневой каталог приложения. Такой объект считается внедренным.
Теперь предполагают, что у Вас есть родительская форма, которая содержит ссылки на дочерние формы, и эти дочерние формы содержат ссылки на родительскую форму. Далее, предположите, что приложение больше не содержит ссылки на родителя для или любую из дочерних форм. Затем в целях сборщика "мусора" эти управляемые объекты больше не базируются и будут собраны "мусор" в следующий раз, когда сборка "мусора" происходит.
Если на и родителя и ребенка не ссылаются, но они только ссылка друг друга, они действительно получают GCed.
Заставляют профилировщика памяти действительно проверять Ваше приложение и отвечать на все Ваши вопросы. Я могу рекомендовать http://memprofiler.com/
Как другие уже сказали, GC не имеет никаких проблем с циклическими ссылками. Я был бы точно так же, как для добавления, что общее место для утечки памяти в.NET является обработчиками событий. Если одна из Ваших форм имеет приложенный обработчик событий к другому объекту, который "жив", то существует ссылка на Вашу форму, и форма не получит GC'd.
GC может иметь дело правильно с циклическими ссылками и если бы эти ссылки были единственными вещами, поддерживающими форму тогда, то они были бы собраны.
я испытал много затруднений с .net, не исправляющим память от форм. В 1,1 были некоторые ошибки aroung пункт меню (я думаю), который означал, что они не стали склонными и могли пропустить память. В этом случае добавление явного вызова для расположения и очистка членской переменной в форме Располагают метод, отсортировал проблему. Мы нашли, что это также помогло исправить память для некоторых из других типов управления.
я также провел долгое время с профилировщиком CLR, смотрящим на то, почему формы не собирались. Насколько я мог сказать, ссылки сохранялись платформой. Один на тип формы. Таким образом, если бы Вы создаете 100 экземпляров Form1, затем закрываете их всех, только 99 были бы исправлены правильно. Я не нашел способа исправить это.
Наше приложение с тех пор переместилось в .net 2, и это, кажется, намного лучше. Наша память приложения все еще увеличивается, когда мы открываем первую форму, и не возвращается вниз, когда это закрывается, но я полагаю, что это - becuase кода JIT'ed и дополнительных библиотек программ управления, которые загружаются.
я также нашел, что, хотя GC может иметь дело с циклическими ссылками, это, кажется, (иногда) имеет проблемы с круговыми ссылками обработчика событий. Ссылки IE object1 object2 и object1 имеют метод, который обрабатывает и событие от object2. Я нашел обстоятельства, где это не выпускало объекты, когда я ожидал, но я так и не смог воспроизвести его в тестовом сценарии.