В чем разница между атомарными и неатомарными атрибутами?
Что atomic а также nonatomic имеется ввиду в объявлениях о недвижимости?
@property(nonatomic, retain) UITextField *userName;
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName;
В чем заключается оперативная разница между этими тремя?
29 ответов
Последние два идентичны; "Атомное" является поведением по умолчанию (обратите внимание, что это на самом деле не ключевое слово; оно определяется только отсутствиемnonatomic - atomic был добавлен в качестве ключевого слова в последних версиях llvm / clang).
Предполагая, что вы @synthesizing реализации метода, атомарный против неатомарного изменения сгенерированного кода. Если вы пишете свой собственный установщик / получатель, атомарный / неатомный / сохранить / назначить / копировать просто рекомендации. (Примечание: @synthesize теперь является поведением по умолчанию в последних версиях LLVM. Также нет необходимости объявлять переменные экземпляра; они также будут автоматически синтезироваться и иметь _ добавлено к их имени, чтобы предотвратить случайный прямой доступ).
С "атомарным", синтезированный установщик / получатель будет гарантировать, что целое значение всегда возвращается из получателя или устанавливается установщиком, независимо от активности установщика в любом другом потоке. То есть, если поток A находится в середине получателя, а поток B вызывает его, то фактическое жизнеспособное значение - объект с автоматически освобожденным кодом, скорее всего, - будет возвращено вызывающей стороне в A.
В nonatomicтакие гарантии не предоставляются. Таким образом, nonatomic значительно быстрее, чем "атомный".
То, что "атомарный" не делает, - это делает какие-либо гарантии безопасности потоков. Если поток A вызывает геттер одновременно, а поток B и C вызывают метод установки с разными значениями, поток A может получить любое из трех возвращенных значений - одно перед вызовом любого метода установки или любое из значений, переданных в методы установки. в B и C. Аналогично, объект может в конечном итоге получить значение из B или C, что никак нельзя сказать.
Обеспечение целостности данных - одна из основных задач многопоточного программирования - достигается другими средствами.
Добавление к этому:
atomicity одного свойства также не может гарантировать безопасность потоков, когда в игре находятся несколько зависимых свойств.
Рассматривать:
@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;
В этом случае поток A может переименовывать объект, вызывая setFirstName: а потом звонит setLastName:, Тем временем поток B может вызвать fullName между двумя вызовами потока А и получит новое имя в сочетании со старой фамилией.
Чтобы решить эту проблему, вам нужна транзакционная модель. Т.е. какой-то другой вид синхронизации и / или исключения, позволяющий исключить доступ к fullName в то время как зависимые свойства обновляются.
Это объясняется в документации Apple, но ниже приведены некоторые примеры того, что на самом деле происходит. Обратите внимание, что ключевое слово "atomic" отсутствует, если вы не укажете "nonatomic", тогда свойство является атомарным, но явное указание "atomic" приведет к ошибке.
//@property(nonatomic, retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
return userName;
}
- (void) setUserName:(UITextField *)userName_ {
[userName_ retain];
[userName release];
userName = userName_;
}
Теперь атомный вариант немного сложнее:
//@property(retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
UITextField *retval = nil;
@synchronized(self) {
retval = [[userName retain] autorelease];
}
return retval;
}
- (void) setUserName:(UITextField *)userName_ {
@synchronized(self) {
[userName_ retain];
[userName release];
userName = userName_;
}
}
По сути, атомарная версия должна блокироваться, чтобы гарантировать безопасность потока, а также увеличивает счетчик ссылок на объект (и счет автоматического выпуска, чтобы сбалансировать его), так что объект гарантированно существует для вызывающей стороны, в противном случае является потенциальным условием гонки, если другой поток устанавливает значение, в результате чего счетчик ссылок падает до 0.
На самом деле существует большое количество различных вариантов того, как эти вещи работают, в зависимости от того, являются ли свойства скалярными значениями или объектами, и как взаимодействуют операции сохранения, копирования, чтения, неатома и т. Д. В общем, синтезаторы свойств просто знают, как сделать "правильную вещь" для всех комбинаций.
атомное
- поведение по умолчанию
- обеспечит завершение текущего процесса процессором, прежде чем другой процесс получит доступ к переменной
- не быстрый, так как он гарантирует, что процесс завершен полностью
Неатомарный
- НЕ по умолчанию
- быстрее (для синтезированного кода, то есть для переменных, созданных с использованием @property и @synthesize)
- не потокобезопасный
- может привести к непредвиденному поведению, когда два разных процесса одновременно обращаются к одной и той же переменной
Лучший способ понять разницу - использовать следующий пример.
Предположим, есть свойство атомарной строки с именем "name", и если вы вызываете [self setName:@"A"] из потока А, позвоните [self setName:@"B"] из потока B, и позвоните [self name] из потока C все операции в разных потоках будут выполняться последовательно, что означает, что если один поток выполняет установщик или получатель, то другие потоки будут ожидать.
Это делает свойство "name" доступным для чтения / записи, но если другой поток, D, вызывает [name release] одновременно эта операция может привести к сбою, потому что здесь нет вызова setter/getter. Это означает, что объект является безопасным для чтения / записи (ATOMIC), но не потокобезопасным, поскольку другие потоки могут одновременно отправлять объекту сообщения любого типа. Разработчик должен обеспечить безопасность потоков для таких объектов.
Если свойство "name" было неатомичным, то все потоки в приведенном выше примере - A,B, C и D будут выполняться одновременно, что приведет к непредсказуемому результату. В случае атомарного, один из A, B или C будет выполняться первым, но D все еще может выполняться параллельно.
Синтаксис и семантика уже хорошо определены другими превосходными ответами на этот вопрос. Поскольку исполнение и производительность не детализированы, я добавлю свой ответ.
В чем функциональная разница между этими 3?
Я всегда считал атомную по умолчанию довольно любопытной. На уровне абстракции, над которым мы работаем, использование атомарных свойств для класса в качестве транспортного средства для достижения 100% -ной безопасности потока является ключевым случаем. Для действительно правильных многопоточных программ вмешательство программиста почти наверняка является требованием. Между тем, характеристики производительности и исполнения еще не были подробно описаны. Написав несколько многопоточных программ за эти годы, я объявил свои свойства как nonatomic все время, потому что атомное не было разумно для какой-либо цели. Во время обсуждения деталей атомных и неатомных свойств этого вопроса я при профилировании столкнулся с некоторыми любопытными результатами.
выполнение
Хорошо. Первое, что я хотел бы прояснить, это то, что реализация блокировки определяется реализацией и абстрагируется. Луи использует @synchronized(self) в его примере - я видел это как общий источник путаницы. Реализация на самом деле не использует @synchronized(self); он использует спин-блокировки на уровне объекта. Иллюстрация Луи хороша для иллюстрации высокого уровня с использованием конструкций, с которыми мы все знакомы, но важно знать, что она не использует @synchronized(self),
Другое отличие состоит в том, что атомарные свойства будут сохранять / освобождать цикл ваших объектов в геттере.
Спектакль
Вот интересная часть: производительность, использующая доступ к атомарным свойствам в неоспоримых (например, однопоточных) случаях, в некоторых случаях может быть действительно очень высокой. В далеко не идеальных случаях использование атомарного доступа может стоить в 20 раз дороже nonatomic, В то время как оспариваемый случай с использованием 7 потоков был в 44 раза медленнее для трехбайтовой структуры (2,2 ГГц Core i7 Quad Core, x86_64). Трехбайтовая структура является примером очень медленного свойства.
Интересное примечание: определяемые пользователем средства доступа трехбайтовой структуры были в 52 раза быстрее, чем синтезированные атомарные средства доступа; или 84% скорости синтезированных неатомных акцессоров.
Объекты в оспариваемых случаях также могут превышать 50 раз.
Из-за большого количества оптимизаций и вариаций в реализации очень сложно измерить реальные воздействия в этих контекстах. Вы можете часто слышать что-то вроде "Доверяйте этому, если вы не профилируете и не обнаружите, что это проблема". Из-за уровня абстракции на самом деле довольно сложно измерить фактическое влияние. Сбор фактических затрат из профилей может занять очень много времени, а из-за абстракций довольно неточен. Кроме того, ARC против MRC может иметь большое значение.
Итак, давайте вернемся назад, не сосредотачиваясь на реализации доступа к свойствам, мы включим обычных подозреваемых, таких как objc_msgSendи проанализировать некоторые реальные результаты высокого уровня для многих обращений к NSString геттер в неоспоримых случаях (значения в секундах):
- MRC | неатомный | Внедренные вручную геттеры: 2
- MRC | неатомный | синтезированный геттер: 7
- MRC | атомный | синтезированный геттер: 47
- ARC | неатомный | Синтезированный геттер: 38 (примечание: здесь ARC добавляет счетчик циклов)
- ARC | атомный | синтезированный геттер: 47
Как вы, наверное, догадались, активность / циклический подсчет ссылок вносит существенный вклад в атомарность и в ARC. Вы также увидите большие различия в спорных случаях.
Хотя я уделяю пристальное внимание производительности, я по-прежнему говорю Semantics First!, Между тем, производительность является низким приоритетом для многих проектов. Однако знание деталей исполнения и стоимости используемых вами технологий, безусловно, не повредит. Вы должны использовать правильную технологию для ваших потребностей, целей и способностей. Надеюсь, это сэкономит вам несколько часов сравнений и поможет вам принять более обоснованное решение при разработке ваших программ.
Атомная = потокобезопасность
Не атомарный = нет безопасности потока
Поток безопасности:
Переменные экземпляра являются поточно-ориентированными, если они ведут себя правильно при обращении из нескольких потоков, независимо от планирования или чередования выполнения этих потоков средой выполнения, и без дополнительной синхронизации или другой координации со стороны вызывающего кода.
В нашем контексте:
Если поток изменяет значение экземпляра, измененное значение доступно для всех потоков, и только один поток может изменить значение за раз.
Где использовать atomic:
если переменная экземпляра будет доступна в многопоточной среде.
Смысл atomic:
Не так быстро, как nonatomic так как nonatomic не требует никакой сторожевой работы над этим из среды выполнения.
Где использовать nonatomic:
Если переменная экземпляра не будет изменена несколькими потоками, вы можете использовать ее. Это улучшает производительность.
После прочтения очень многих статей, публикаций Stack Overflow и создания демонстрационных приложений для проверки атрибутов переменных свойств, я решил собрать всю информацию об атрибутах:
atomic// По умолчаниюnonatomicstrong = retain// По умолчаниюweak = unsafe_unretainedretainassign// По умолчаниюunsafe_unretainedcopyreadonlyreadwrite// По умолчанию
В статье Атрибуты свойств переменных или модификаторы в iOS вы можете найти все вышеупомянутые атрибуты, и это определенно вам поможет.
atomicatomicозначает, что только один поток обращается к переменной (статический тип).atomicПоток безопасен.- Но это медленно в производительности
atomicповедение по умолчанию- Атомарные методы доступа в среде без сборки мусора (то есть при использовании retain / release / autorelease) будут использовать блокировку, чтобы гарантировать, что другой поток не будет мешать правильной установке / получению значения.
- На самом деле это не ключевое слово.
Пример:
@property (retain) NSString *name; @synthesize name;nonatomicnonatomicозначает многопоточный доступ к переменной (динамический тип).nonatomicнебезопасно.- Но это быстро в производительности
nonatomicНЕ по умолчанию. Нам нужно добавитьnonatomicключевое слово в атрибуте свойства.- Это может привести к неожиданному поведению, когда два разных процесса (потока) одновременно обращаются к одной и той же переменной.
Пример:
@property (nonatomic, retain) NSString *name; @synthesize name;
Я нашел довольно удачное объяснение атомных и неатомных свойств здесь. Вот некоторые соответствующие тексты из того же:
"атомный" означает, что его нельзя сломать. В терминах OS/ программирования вызов атомарной функции - это вызов, который не может быть прерван - вся функция должна быть выполнена, а не выгружена из ЦПУ обычным переключением контекста ОС, пока оно не завершится. Просто на тот случай, если вы не знали: поскольку ЦП может делать только одну вещь за один раз, ОС вращает доступ к ЦП всем запущенным процессам за небольшие промежутки времени, создавая иллюзию многозадачности. Планировщик ЦП может (и делает) прерывать процесс в любой момент его выполнения - даже в середине вызова функции. Таким образом, для таких действий, как обновление переменных общего счетчика, когда два процесса могут попытаться обновить переменную одновременно, они должны выполняться "атомарно", т. Е. Каждое действие обновления должно завершиться полностью, прежде чем любой другой процесс может быть перенесен на ЦПУ.
Таким образом, я бы предположил, что атомарный в этом случае означает, что методы чтения атрибутов не могут быть прерваны - в действительности это означает, что переменная (переменные), читаемая методом, не может изменить свое значение на полпути, потому что какой-то другой поток / вызов / функция получает поменял местами процессор.
Поскольку atomic Переменные не могут быть прерваны, значение, содержащееся в них в любой момент (поточная блокировка), гарантированно не будет повреждено, хотя, гарантируя, что эта блокировка потока делает доступ к ним более медленным. non-atomic Переменные, с другой стороны, не дают такой гарантии, но предлагают роскошь быстрого доступа. Подводя итог, пойти с non-atomic когда вы знаете, что ваши переменные не будут доступны нескольким потокам одновременно и это ускорит процесс.
Атомный:
Атомные гарантии, что доступ к собственности будет осуществляться на атомном уровне. Например, он всегда возвращает полностью инициализированные объекты, любое получение / установка свойства в одном потоке должно завершиться, прежде чем другой сможет получить к нему доступ.
Если вы представите следующую функцию, выполняющуюся в двух потоках одновременно, вы поймете, почему результаты не будут хорошими.
-(void) setName:(NSString*)string
{
if (name)
{
[name release];
// what happens if the second thread jumps in now !?
// name may be deleted, but our 'name' variable is still set!
name = nil;
}
...
}
Плюсы: возврат полностью инициализированных объектов каждый раз делает его лучшим выбором в случае многопоточности.
Минусы: производительность падает, делает выполнение немного медленнее
Неатомный:
В отличие от Atomic, он не гарантирует, что каждый раз полностью инициализированный объект возвращается.
Плюсы: чрезвычайно быстрое исполнение.
Минусы: вероятность получения мусора в случае многопоточности.
Самый простой ответ: нет разницы между вашими вторыми примерами. По умолчанию средства доступа к свойствам являются атомарными.
Атомарные методы доступа в среде без сборки мусора (то есть при использовании retain/release/autorelease) будут использовать блокировку, чтобы гарантировать, что другой поток не будет мешать правильной установке / получению значения.
См. Раздел " Производительность и многопоточность" документации Apple Objective-C 2.0 для получения дополнительной информации и других соображений при создании многопоточных приложений.
Атомный означает, что только один поток обращается к переменной (статический тип). Атомный потокобезопасный, но он медленный.
Неатомарный означает, что несколько потоков обращаются к переменной (динамический тип). Неатомный поток-небезопасный, но это быстро.
Атомный потокобезопасный, он медленный, и он уверяет (не гарантирует), что предоставляется только заблокированное значение независимо от того, сколько потоков пытается получить доступ через одну и ту же зону. При использовании atomic часть кода, написанная внутри этой функции, становится частью критической секции, в которую одновременно может работать только один поток.
Это только обеспечивает безопасность потока; это не гарантирует этого. Я имею в виду, что вы нанимаете опытного водителя для своей машины, но это не гарантирует, что автомобиль не попадет в аварию. Однако вероятность остается малейшей.
Атомное - его нельзя сломать, поэтому результат ожидаем. С неатомарным - когда другой поток обращается к зоне памяти, он может изменить ее, поэтому результат будет неожиданным.
Code Talk:
Атомный make getter и setter свойства thread безопасны. например, если вы написали:
self.myProperty = value;
Поток безопасен.
[myArray addObject:@"Abc"]
НЕ является потокобезопасным.
Там нет такого ключевого слова "атомная"
@property(atomic, retain) UITextField *userName;
Мы можем использовать выше, как
@property(retain) UITextField *userName;
См. Вопрос переполнения стека. У меня возникают проблемы, если я использую @property (atomic, retain) NSString * myString.
атомарный (по умолчанию)
По умолчанию используется атомарный: если вы ничего не печатаете, ваше свойство атомарное. Атомарное свойство гарантировано, что если вы попытаетесь прочитать из него, вы получите верное значение. Это не дает никаких гарантий относительно того, каким может быть это значение, но вы получите хорошие данные, а не только ненужную память. Это позволяет вам делать, если у вас есть несколько потоков или несколько процессов, указывающих на одну переменную, один поток может читать, а другой поток может писать. Если они попадают в одно и то же время, поток чтения гарантированно получит одно из двух значений: либо до изменения, либо после изменения. То, что не дает вам атомарность, это какая-то гарантия того, какие из этих ценностей вы можете получить. Atomic обычно путают с поточностью потоков, и это не правильно. Вы должны гарантировать безопасность вашей нити другими способами. Тем не менее, Atomic гарантирует, что если вы попытаетесь читать, вы получите какое-то значение.
неатомической
С другой стороны, неатомарное, как вы, вероятно, можете догадаться, просто означает "не делайте этого атомарного материала". То, что вы теряете, - это гарантия того, что вы всегда что-то получите. Если вы попытаетесь прочитать в середине записи, вы можете получить обратно данные мусора. Но, с другой стороны, вы идете немного быстрее. Поскольку атомарные свойства должны творить чудеса, чтобы гарантировать возвращение значения, они немного медленнее. Если это свойство, к которому вы часто обращаетесь, вы можете перейти к неатомному, чтобы убедиться, что вы не понесете этот штраф за скорость.
Смотрите больше здесь: https://realm.io/news/tmi-objective-c-property-attributes/
По умолчанию atomic это означает, что при использовании свойства оно будет стоить вам производительности, но оно безопасно для потоков. Что делает Objective-C, так это устанавливает блокировку, поэтому только фактический поток может получить доступ к переменной, пока выполняется установщик / получатель.
Пример с MRC свойства с ivar _internal:
[_internal lock]; //lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;
Итак, последние два одинаковы:
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName; // defaults to atomic
С другой стороны делает nonatomic ничего не добавляйте к своему коду. Так что это только потокобезопасно, если вы сами создадите механизм безопасности
@property(nonatomic, retain) UITextField *userName;
Ключевые слова вообще не должны записываться как первый атрибут свойства.
Не забывайте, это не означает, что свойство в целом является потокобезопасным. Только вызов метода метода установки / получения. Но если вы используете установщик, а затем одновременно получатель с двумя разными потоками, он тоже может быть поврежден!
- -Атомный означает, что только один поток имеет доступ к переменной (статический тип).
- -Атомный потокобезопасный.
- - но это медленно в производительности
Как объявить:
Как атомная по умолчанию так,
@property (retain) NSString *name;
И в файле реализации
self.name = @"sourov";
Предположим, что задача, связанная с тремя свойствами
@property (retain) NSString *name;
@property (retain) NSString *A;
@property (retain) NSString *B;
self.name = @"sourov";
Все свойства работают параллельно (как асинхронно).
Если вы называете "имя" из потока А,
А также
В то же время, если вы звоните
[self setName:@"Datta"]
из нити B,
Если свойство *name неатомично, тогда
- Вернет значение "Датта" для А
- Он вернет значение "Датта" для B
Вот почему non atomic называется потоком небезопасным, но он быстрый по производительности из-за параллельного выполнения
Теперь, если *name свойство является атомарным
- Это обеспечит значение "Sourov" для A
- Тогда он вернет значение "Датта" для B
Вот почему Atomic называется потокобезопасным, и поэтому он называется безопасным для чтения и записи.
Такая ситуация операция будет выполнять поочередно. И медленно в исполнении
- Неатомный означает, что многопоточный доступ к переменной (динамический тип).
- Неатомный поток небезопасен.
- но это быстро в производительности
- Nonatomic НЕ является поведением по умолчанию, нам нужно добавить ключевое слово nonatomic в атрибуте свойства.
Для In Swift Подтверждение того, что свойства Swift неатомичны в смысле ObjC. Одна из причин заключается в том, что вы думаете о том, достаточна ли атомарность для каждого объекта для ваших нужд.
Ссылка: https://forums.developer.apple.com/thread/25642
Для получения дополнительной информации, пожалуйста, посетите сайт http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html
Если вы используете свое свойство в многопоточном коде, вы сможете увидеть разницу между неатомарными и атомарными атрибутами. Неатомарное быстрее, чем атомарное, а атомарное - потокобезопасное, а не неатомарное.
Виджаендра Трипати уже привел пример многопоточной среды.
Атомарность атомная (по умолчанию)
По умолчанию используется атомарный: если вы ничего не печатаете, ваше свойство атомарное. Атомарное свойство гарантировано, что если вы попытаетесь прочитать из него, вы получите верное значение. Это не дает никаких гарантий относительно того, каким может быть это значение, но вы получите хорошие данные, а не только ненужную память. Это позволяет вам делать, если у вас есть несколько потоков или несколько процессов, указывающих на одну переменную, один поток может читать, а другой поток может писать. Если они попадают в одно и то же время, поток чтения гарантированно получит одно из двух значений: либо до изменения, либо после изменения. То, что не дает вам атомарность, это какая-то гарантия того, какие из этих ценностей вы можете получить. Atomic обычно путают с поточностью потоков, и это не правильно. Вы должны гарантировать безопасность вашей нити другими способами. Тем не менее, Atomic гарантирует, что если вы попытаетесь читать, вы получите какое-то значение.
неатомической
С другой стороны, неатомарное, как вы, вероятно, можете догадаться, просто означает "не делайте этого атомарного материала". То, что вы теряете, - это гарантия того, что вы всегда что-то получите. Если вы попытаетесь прочитать во время записи, вы можете получить данные с мусором. Но, с другой стороны, вы идете немного быстрее. Поскольку атомарные свойства должны творить чудеса, чтобы гарантировать возвращение значения, они немного медленнее. Если это свойство, к которому вы часто обращаетесь, вы можете перейти к неатомному, чтобы убедиться, что вы не понесете этот штраф за скорость. Доступ
Вежливость https://academy.realm.io/posts/tmi-objective-c-property-attributes/
Атрибуты свойств атомарности (атомарные и неатомарные) не отражены в соответствующем объявлении свойства Swift, но гарантии атомарности реализации Objective-C все еще сохраняются, когда к импортированному свойству обращаются из Swift.
Итак, если вы определите атомарное свойство в Objective-C, оно останется атомарным при использовании Swift.
вежливость https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c
Прежде чем начать: Вы должны знать, что каждый объект в памяти должен быть освобожден из памяти, чтобы произошла новая запись. Вы не можете просто написать поверх чего-либо, как на бумаге. Вы должны сначала стереть (dealloc) это, а затем вы можете написать на него. Если в тот момент, когда стирание выполнено (или наполовину сделано) и ничего еще не написано (или наполовину написано), и вы попытаетесь прочитать, это может быть очень проблематично! Атомные и неатомные помогают вам по-разному относиться к этой проблеме.
Сначала прочитайте этот вопрос, а затем прочитайте ответ Bbum. Кроме того, прочитайте мое резюме.
atomic ВСЕГДА гарантируем
- Если два разных человека хотят читать и писать одновременно, ваша газета не просто сгорит! -> Ваше приложение никогда не рухнет, даже в состоянии гонки.
- Если один человек пытается написать и написал только 4 из 8 написанных писем, то не может читать в середине, чтение может быть выполнено только тогда, когда написаны все 8 букв -> Не будет прочитано (получено) "поток, который все еще пишет", т. е. если в байтах записано 8 байтов, а записано только 4 байта, - до этого момента вы не можете читать из него. Но так как я сказал, что он не будет аварийно завершать работу, он будет считывать значение из автоматически выпущенного объекта.
- Если перед написанием вы удалили то, что ранее было написано на бумаге, а затем кто-то хочет прочитать, вы все равно можете прочитать. Как? Вы будете читать что-то похожее на мусорное ведро Mac OS (так как мусорное ведро еще не удалено на 100%... оно находится в подвешенном состоянии) ---> Если ThreadA должен читать, а ThreadB уже отменил запись, вы могли бы либо получите значение из окончательного полностью записанного значения ThreadB, либо получите что-нибудь из пула автоматического выпуска.
Сохранять счетчики - это способ управления памятью в Objective-C. Когда вы создаете объект, он имеет счет сохранения 1. Когда вы отправляете объекту сообщение сохранения, его счет хранения увеличивается на 1. Когда вы отправляете объекту сообщение об освобождении, его счет хранения уменьшается на 1. Когда вы отправьте объекту сообщение об автоматическом высвобождении, его счетчик хранения будет уменьшен на 1 на каком-то этапе в будущем. Если количество сохраняемых объектов уменьшается до 0, оно освобождается.
- Atomic не гарантирует безопасность потоков, хотя и полезна для достижения безопасности потоков. Безопасность потоков зависит от того, как вы пишете свой код / из какой очереди потоков вы читаете / пишете. Это гарантирует только неразрушаемую многопоточность.
Чего ждать?! Отличаются ли многопоточность и безопасность потоков?
Да. Многопоточность означает: несколько потоков могут одновременно читать общий фрагмент данных, и мы не будем аварийно завершать работу, но это не гарантирует, что вы не читаете из неавторизованного значения. С безопасностью потока гарантируется, что то, что вы читаете, не высвобождается автоматически. Причина, по которой мы не делаем все атомарным по умолчанию, заключается в том, что производительность снижается, а для большинства вещей не требуется безопасность потоков. Несколько частей нашего кода нуждаются в этом, и для этих нескольких частей нам нужно написать наш код потокобезопасным способом, используя блокировки, мьютекс или синхронизацию.
nonatomic
- Поскольку не существует такой вещи, как мусорное ведро Mac OS, то никого не волнует, всегда ли вы получаете значение (<- это может привести к сбою), и никому нет дела, если кто-то пытается прочитать на полпути вашу запись (хотя наполовину запись в памяти сильно отличается от написания наполовину на бумаге, в памяти это может дать вам сумасшедшее глупое значение, в то время как на бумаге вы видите только половину написанного) -> Не гарантирует, что не произойдет сбой, потому что это не использует механизм автоматического выпуска.
- Не гарантирует полного написания значений для чтения!
- Быстрее атомного
В целом они отличаются в 2 аспектах:
Сбой или нет из-за наличия или отсутствия пула авто-релиза.
Разрешить чтение прямо в середине "еще не законченной записи или пустого значения" или не разрешить и разрешить чтение только тогда, когда значение полностью записано.
Прежде чем обсуждать атрибуты @property, вы должны знать, что такое @property. @property предлагает способ определения информации, которую класс должен инкапсулировать. Если вы объявите объект / переменную с помощью @property, то этот объект / переменная будет доступен для других классов, импортирующих его класс. Если вы объявляете объект с помощью @property в заголовочном файле, то вы должны синтезировать его с помощью @synthesize в файле реализации.
Пример:
.h класс
@interface ExampleClass : NSObject
@property (nonatomic, retain) NSString *name;
@end
.m класс
@implementation ExampleClass
@synthesize name;
@end
Теперь компилятор будет синтезировать методы доступа для имени.
ExampleClass *newObject=[[ExampleClass alloc]init];
NSString *name1=[newObject name]; // get 'name'
[obj setName:@“Tiger”];
Список атрибутов @property: atomic. неатомический. сохранить. копия. неизменяемые. читай пиши. назначить. сильный.
atomic: это поведение по умолчанию. Если объект объявлен как атомарный, он становится потокобезопасным. Потокобезопасный означает, что одновременно только один поток определенного экземпляра этого класса может иметь контроль над этим объектом.
Пример:
@property NSString *name; //by default atomic
@property (atomic)NSString *name; // explicitly declared atomic
неатомный: не является потокобезопасным. Вы можете использовать атрибут неатомного свойства, чтобы указать, что синтезированные средства доступа просто устанавливают или возвращают значение напрямую, без каких-либо гарантий относительно того, что произойдет, если к одному и тому же значению обращаются одновременно из разных потоков. По этой причине доступ к неатомарному свойству быстрее, чем к атомарному.@property (nonatomic)NSString *name;
retain: требуется, когда атрибут является указателем на объект. Метод setter увеличивает количество сохраняемых объектов, так что он будет занимать память в пуле автоматического выпуска.@property (retain)NSString *name;
копия: если вы используете копию, вы не можете использовать сохранить. Использование экземпляра экземпляра класса будет содержать собственную копию. Даже если изменяемая строка установлена и впоследствии изменена, экземпляр захватывает любое значение, которое он имеет во время его установки. Методы получения и получения не будут синтезированы.
@property (copy) NSString *name;
NSMutableString *nameString = [NSMutableString stringWithString:@"Liza"];
xyzObj.name = nameString;
[nameString appendString:@"Pizza"];
только для чтения: если вы не хотите разрешать изменение свойства с помощью метода установки, вы можете объявить свойство только для чтения.@property (readonly) NSString *name;
readwrite: это поведение по умолчанию. Вам не нужно явно указывать атрибут readwrite.
@property (readwrite) NSString *name;
assign: создаст установщик, который присваивает значение переменной экземпляра напрямую, а не копирует или сохраняет его. Это лучше всего подходит для примитивных типов, таких как NSInteger и CGFloat, или для объектов, которыми вы не владеете напрямую, таких как делегаты.
@property (assign) NSInteger year;
сильный: это замена для удержания.@property (nonatomic, strong) AVPlayer *player;
unsafe_unretained: в Cocoa и Cocoa Touch есть несколько классов, которые еще не поддерживают слабые ссылки, что означает, что вы не можете объявить слабое свойство или слабую локальную переменную, чтобы отслеживать их. Эти классы включают NSTextView, NSFont и NSColorSpace и т. Д. Если вам нужно использовать слабую ссылку на один из этих классов, вы должны использовать небезопасную ссылку. Небезопасная ссылка похожа на слабую ссылку в том, что она не поддерживает связанный объект, но для него не будет установлено значение nil, если целевой объект освобожден.
@property (unsafe_unretained) NSObject *unsafeProperty;
Свойство atomic гарантирует сохранение полностью инициализированного значения независимо от того, сколько потоков выполняет для него getter & setter.
Неатомарное свойство указывает, что синтезированные методы доступа просто устанавливают или возвращают значение напрямую, без каких-либо гарантий относительно того, что произойдет, если к одному и тому же значению обращаются одновременно из разных потоков.
Атомный означает, что только один поток может получить доступ к переменной одновременно (статический тип). Атомный потокобезопасный, но он медленный.
Неатомарное означает, что несколько потоков могут обращаться к переменной одновременно (динамический тип). Неатомный поток-небезопасный, но это быстро.
Если вы используете атомарный, это означает, что поток будет безопасным и доступным только для чтения. Если вы используете nonatomic, это означает, что несколько потоков обращаются к переменной и являются потокобезопасными, но они выполняются быстро, выполняют операции чтения и записи; это динамический тип.
Правда состоит в том, что они используют спин-блокировку для реализации атомарного свойства. Код, как показано ниже:
static inline void reallySetProperty(id self, SEL _cmd, id newValue,
ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
id oldValue;
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:NULL];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:NULL];
} else {
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
if (!atomic) {
oldValue = *slot;
*slot = newValue;
} else {
spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
_spin_lock(slotlock);
oldValue = *slot;
*slot = newValue;
_spin_unlock(slotlock);
}
objc_release(oldValue);
}
Одной строкой:
Atomic потокобезопасен.
Nonatomic небезопасно для потоков.
Чтобы упростить всю путаницу, давайте разберемся с блокировкой мьютекса. Блокировка мьютекса в соответствии с именем блокирует изменчивость объекта. Так что, если к объекту обращается класс, никакой другой класс не может получить доступ к тому же объекту. В iOS @sychronise также предоставляет мьютекс lock.Now это работает в режиме FIFO и гарантирует, что на поток не влияют два класса, совместно использующие один и тот же экземпляр. Однако, если задача находится в главном потоке, избегайте доступа к объекту с использованием атомарных свойств, так как это может удерживать ваш пользовательский интерфейс и ухудшать производительность.
Атомная: Обеспечить безопасность потока, заблокировав поток с помощью NSLOCK.
Не атомарный: не обеспечивает безопасность потока, так как нет механизма блокировки потока.
В Objective-C реализация атомарного свойства позволяет безопасно читать и записывать свойства из разных потоков. Для неатомарных свойств базовый указатель считанного значения может быть освобожден, когда одновременно записывается новое значение.
Атомный означает, что только один поток обращается к переменной (статический тип). Atomic является потокобезопасным, но медленным. Неатомарность означает, что несколько потоков обращаются к переменной (динамический тип). Nonatomic небезопасен в отношении потоков, но он быстр.
Атомарные свойства:- Когда переменная, назначенная с атомарным свойством, которое означает, что она имеет доступ только к одному потоку и будет поточно-ориентированной и будет хорошей с точки зрения производительности, будет иметь поведение по умолчанию.
Неатомарные свойства:- Когда переменная, назначенная с атомарным свойством, которое означает, что она имеет многопоточный доступ и не будет потокобезопасной, будет медленной с точки зрения производительности, будет иметь поведение по умолчанию и когда два разных потока захотят получить доступ к переменной одновременно это даст неожиданные результаты.