Объяснение сильного и слабого хранения в iOS5

Ответ 1

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

Возможно, пример в порядке.

Представьте, что наш объект - собака, и собака хочет убежать (освобождается).

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

Слабые указатели, с другой стороны, похожи на маленьких детей, указывающих на собаку и говорящих "Смотри! Собака!". Пока собака все еще находится на поводке, маленькие дети все еще могут видеть собаку, и они все равно укажут на нее. Однако, как только все поводки отсоединяются, собака убегает, независимо от того, сколько маленьких детей указывают на нее.

Как только последний сильный указатель (привязка) больше не указывает на объект, объект будет освобожден, и все слабые указатели будут обнулены.

Ответ 2

Не идентичны ли два определения.

Абсолютно нет. Основное различие в двух определениях, которые вы указали, - "до тех пор, пока кто-то еще". Это важно "кому-то еще".

Рассмотрим следующее:

__strong id strongObject = <some_object>;
__weak id weakObject = strongObject;

Теперь у нас есть два указателя на <some_object>, один сильный и слабый. Если мы установим strongObject в nil следующим образом:

strongObject = nil;

Затем, если вы перейдете к правилам, которые вы указали, вы зададите себе следующие вопросы:

• Сильно: "держите это в куче, пока я больше не укажу на него"

  strongObject больше не указывает на <some_object>. Поэтому нам не нужно его хранить.

• Слабо: "держите это, пока кто-то еще указывает на него сильно"

  weakObject все еще указывает на <some_object>. Но поскольку никто не указывает на это, это правило также означает, что нам не нужно его хранить.

В результате <some_object> освобождается, и если ваше время выполнения поддерживает его (Lion и iOS 5 вверх), то weakObject будет автоматически установлено на nil.

Теперь рассмотрим, что произойдет, если мы установим weakObject в nil так:

weakObject = nil;

Затем, если вы перейдете к правилам, которые вы указали, вы зададите себе следующие вопросы:

• Сильно: "держите это в куче, пока я больше не укажу на него"

  strongObject указывает на <some_object>. Поэтому нам нужно его сохранить.

• Слабо: "держите это, пока кто-то еще указывает на него сильно"

  weakObject не указывает на <some_object>.

В результате <some_object> не освобождается, но weakObject будет указателем nil.

[Обратите внимание, что на все, что предполагается <some_object>, не указывается другая сильная ссылка где-то еще/некоторые другие способы "удерживаться" ]

Ответ 3

Сильный

• Создает собственность между свойством и назначенным значением.
• Это свойство по умолчанию для свойства объекта в ARC, поэтому оно не позволяет вам беспокоиться о подсчете ссылок и автоматически отпускать ссылку.
• Это замена для сохранения. Мы используем тогда и только тогда, когда нам нужно использовать как сохранение.

Слабые

• Создает несобственность между свойством и назначенным значением.
• Сильный используется для родительского объекта, а слабый используется для дочернего объекта при выпуске родителя, тогда ссылка на дочерний объект также устанавливается на nil
• Это помогает предотвратить циклические циклы.
• Он не защищает ссылочный объект при сборе сборщиком мусора.
• Слабый по существу назначается, не имеет свойства.

Ответ 4

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

Ответ 5

Другой пример: Студент Object, предположил, что он/она может окончить (deallocate) до тех пор, пока он/он закончит все основные курсы (strong pointers), независимо от того, возьмет ли он/нет дополнительные курсы (weak pointers). Другими словами: сильный указатель является единственным фактором освобождения этого Object.

Ответ 6

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

Для аппаратного обеспечения слабый или сильный указывает, существует ли поддержка последовательной согласованности.

[SC означает, что]... результат любого выполнения такой же, как если бы операции всех процессоры выполнялись в некотором последовательном порядке, а операции каждого отдельного процессора появляются в этой последовательности в порядок, указанный в его программе. - Lamport, 1979

WTF это связано с памятью? Это означает, что записи в переменные с помощью разных процессоров должны рассматриваться в одном порядке всеми процессорами. В аппаратном обеспечении с сильной моделью это гарантировано. На аппаратном обеспечении со слабой моделью это не так.

Существующие ответы интерпретируют этот вопрос только в терминах моделей памяти программного обеспечения. Аппаратное обеспечение не имеет никакого отношения к программированию. Этот вопрос касается iOS, который обычно работает на процессорах Arm7. У Arm7 есть слабая модель памяти. Для программистов, привыкших к процессорам с сильной моделью - это все из нас, потому что у x86 и x64 есть сильная модель - это ужасная ловушка. Использование bool для сигнала другого потока для выхода работает отлично в сильной модели. Тот же код на руке не работает вообще, если вы не отметите флаг волатильности, и даже тогда он будет неустойчивым.

Хотя верно, что Arm8 + полностью меняет эту ситуацию с явной поддержкой для получения/выпуска, устаревшее программное обеспечение не использует эту поддержку. Программное обеспечение Legacy включает в себя все три ОС телефона и все, что работает на них, а также компиляторы и библиотеки до тех пор, пока они не будут обновлены.

Для расширенного изучения этой темы я отсылаю вас к неподражаемому Herb Sutter.