Сохраняемые циклы: Почему это так плохо?

Question

Есть два объекта A и B. A создает B и сохраняет его. B имеет переменную экземпляра, которая указывает на A, сохраняя ее. Так что оба сохраняют друг друга. Некоторые люди говорят, что эта сильная связь больше не может быть нарушена.

Но это действительно так?

Если B освободит A, тогда A может легко освободить B, и поэтому B будет освобожден. A будет освобожден, как только он станет другим владельцем (я думаю, должен быть кто-то) освобождает его.

Или эта проблема применима только в случае, когда A не создает B, а просто содержит сильную ссылку на нее, сохраняя ее в переменной экземпляра? Я до сих пор не понимаю, почему эта связь не может быть снова разорвана.

Answer 1

Циклы не плохие, но их часто избегают, потому что они могут сделать это сложным, чтобы убедиться, что у вас нет утечек памяти. Утечки возникают, особенно когда объекты «подсчет ссылок». На языке или системе, использующей подсчет ссылок, объект отслеживает количество ссылок, указывающих на него. Каждый раз, когда ссылка удаляется, счетчик уменьшается, когда счетчик достигает нуля, ссылок нет и поэтому объект может быть удален.

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

Но ... если у вас есть цикл, этот каскад не работает. У вас может быть группа объектов, и вы не хотите их больше, поэтому вы бросаете единственную ссылку, которую вы имеете на эти объекты, но поскольку есть цикл, объекты ссылаются друг на друга. Это означает, что их счетчики ссылок никогда не обращаются к нулю, и они не удаляются. Это утечка памяти.

Очевидно, что вы можете провести тщательное управление и разбить циклы, прежде чем отказаться от ссылки на группу объектов, которые вы больше не хотите. Но ... как я только что сказал, это требует тщательного управления. Очень легко ошибиться. Это одна из основных причин утечки памяти.

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

Некоторые языки с сборщиками мусора (например, C#) могут удалять группу объектов, которые больше не нужны, даже если группа содержит циклы.

Answer 2

Проблема заключается в следующем: A указывает на B и сохраняет B, а B указывает и сохраняет A. Когда нет других ссылок на A или B, их освободить не будет, поскольку приложение не поддерживает есть ссылки на них в этот момент. Это называется эталонным циклом, и он представляет собой тип утечки памяти, общий в любой системе подсчета ссылок. То, как это решается на большинстве языков высокого уровня, - это использование сборки мусора, а не подсчета ссылок.

Answer 3

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

A* a = [[A alloc] initAndCreateB]; 

Теперь экземпляр без имени B (созданный A) имеет показатель сохранения 1.Поскольку мы считаем ссылку на А и анонимный экземпляр B имеет сильную ссылку на А, сохранить подсчитывать равен 2.

Допустим, мы сделали с помощью A:

[a release]; 
return 12; 

Теперь, сохраняют подсчет 1. Он не будет выпущен, это потеря памяти. Вот почему сохранить циклы плохие.

Answer 4

Способ разрыва цикла удержания состоит в том, чтобы иметь отдельный метод «закрыть».

т.е.

A retains B 
B retains A 

, когда вы закончите, вызовите метод (я буду называть его «close») на А, где А высвобождает B. Вы можете выпустить и весь цикл будет выпускать (предполагая, что в другом месте не сохранилось).