293

Can someone explain to me in detail when I must use each attribute: nonatomic, copy, strong, weak, and so on, for a declared property, and explain what each does? Some sort of example would be great also. I am using ARC.

jscs
  • 63,694
  • 13
  • 151
  • 195
Gaurav_soni
  • 6,064
  • 8
  • 32
  • 49

4 Answers4

561

Nonatomic

Nonatomic will not generate threadsafe routines thru @synthesize accessors. atomic will generate threadsafe accessors so atomic variables are threadsafe (can be accessed from multiple threads without botching of data)

Copy

copy is required when the object is mutable. Use this if you need the value of the object as it is at this moment, and you don't want that value to reflect any changes made by other owners of the object. You will need to release the object when you are finished with it because you are retaining the copy.

Assign

Assign is somewhat the opposite to copy. When calling the getter of an assign property, it returns a reference to the actual data. Typically you use this attribute when you have a property of primitive type (float, int, BOOL...)

Retain

retain is required when the attribute is a pointer to a reference counted object that was allocated on the heap. Allocation should look something like:

NSObject* obj = [[NSObject alloc] init]; // ref counted var

The setter generated by @synthesize will add a reference count to the object when it is copied so the underlying object is not autodestroyed if the original copy goes out of scope.

You will need to release the object when you are finished with it. @propertys using retain will increase the reference count and occupy memory in the autorelease pool.

Strong

strong is a replacement for the retain attribute, as part of Objective-C Automated Reference Counting (ARC). In non-ARC code it's just a synonym for retain.

This is a good website to learn about strong and weak for iOS 5. http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1

Weak

weak is similar to strong except that it won't increase the reference count by 1. It does not become an owner of that object but just holds a reference to it. If the object's reference count drops to 0, even though you may still be pointing to it here, it will be deallocated from memory.

The above link contain both Good information regarding Weak and Strong.

bobobobo
  • 64,917
  • 62
  • 258
  • 363
iDhaval
  • 7,824
  • 2
  • 21
  • 30
  • Thanks for the explanation , i have some questions though , 1. I have my main data class , in this class i have all the attribues set to strong. Then when i am creating another class , i have a variable value of NSString getting value from a textbox , do this NSString value should of weak type ? sorry for noob questions still learning ... – Gaurav_soni Mar 25 '12 at 15:06
  • 1
    if you are using this NSString just internally in that class itself than you don't even need a property you can just make it an iVar and if you are using it in another class than I will advise (strong,copy). – Ankit Srivastava Mar 25 '12 at 15:58
  • 1
    You are missing the Assign property. – mskw Apr 04 '13 at 21:45
  • This is the best explanation for this that I've seen. Thanks! – shim Jul 03 '13 at 15:46
  • If using ARC, would I ever want to use Assign / Copy? Or should I just stick with Weak / Strong? – Jake T. Apr 13 '15 at 07:25
  • 11
    `nonatomic` mean that it should *not* be accessed concurrently by multiple threads. The default is `atomic` which makes it thread safe. – wcochran Apr 16 '15 at 14:02
  • It's not exactly that copy is required when the object is mutable - it is just often a good idea. There are also many cases where you might want a strong or weak reference to an original (shared) mutable object rather than a copy of it. I wish that were a bit more clear - but for a beginner these are excellent guidelines. – codehearted Apr 23 '15 at 01:02
  • 1
    It's a little disturbing that after all this time the definition of nonatomic is still wrong, and resembles atomic. I wonder how many people have used this over the last five years and gotten the wrong impression. What @wcochran said was correct. nonatomic means that access to the pointer is not handled atomically, and so is not thread safe. The benefit as I understand it of nonatomic is that it's lighter weight. – John Bushnell Nov 07 '17 at 17:05
  • 1
    In addition to the comment of @JohnBushnell there are many other errors and inaccuracies in this answer. It has also not aged well, so is somwhat historical. Go look elsewhere if you seek an answer to this question. – CRD Mar 01 '18 at 05:22
  • @wcochran `nonatomic` does not mean that something can't be accessed from multiple threads and `atomic` does not make things thread safe. – bbum Mar 01 '18 at 22:41
  • @bbum "nonatomic" means that you are not guaranteed mutual exclusive access to the object when accessed concurrently from multiple threads. Atomicity is only one step in making code thread safe. It does not ensure bounded waiting, progress, and other such attributes. – wcochran Mar 01 '18 at 23:21
  • @wcochran Not quite; `nonatomic` merely means there is no lock, that does not imply that multithreaded access is either safe or unsafe. Whether it is is an implementation detail. @property atomicity is an optional step in making code thread safe, no more, no less (and as you claim `atomic` does nothing for *transactional integrity*). – bbum Mar 03 '18 at 17:02
  • Can you please give correct answer for this? 1. assign is it increase reference count 1 or not? if yes, or no please give reason for this. 2. copy is it increase reference count by 1 or not? if yes, or no please give reason for this. – nipa Jan 07 '21 at 02:46
  • I guess it's also important to understand the default property attributes: * For memory management a `strong` reference is the default over `weak`, `copy`, `assign` (`retain` is a synonym of `strong`). * For thread safety `atomic` is the default over `nonatomic` * For mutability `readwrite` is the default over `readonly` Source: https://useyourloaf.com/blog/default-property-attributes-with-arc/ – Bruno Bieri Sep 30 '21 at 13:23
45

nonatomic property means @synthesized methods are not going to be generated threadsafe -- but this is much faster than the atomic property since extra checks are eliminated.

strong is used with ARC and it basically helps you , by not having to worry about the retain count of an object. ARC automatically releases it for you when you are done with it.Using the keyword strong means that you own the object.

weak ownership means that you don't own it and it just keeps track of the object till the object it was assigned to stays , as soon as the second object is released it loses is value. For eg. obj.a=objectB; is used and a has weak property , than its value will only be valid till objectB remains in memory.

copy property is very well explained here

strong,weak,retain,copy,assign are mutually exclusive so you can't use them on one single object... read the "Declared Properties " section

hoping this helps you out a bit...

bobobobo
  • 64,917
  • 62
  • 258
  • 363
Ankit Srivastava
  • 12,347
  • 11
  • 63
  • 115
  • why strong,weak,retain,copy,assign mutually exclusive – vinoth.kumar Oct 16 '15 at 09:54
  • `nonatomic` only means no exclusion is applied. It does not mean that access is not thread safe. That is an implementation detail that `atomic` vs. `nonatomic` does not capture. – bbum Mar 03 '18 at 17:03
  • @bbum Can you explain the difference between no exclusion and not thread safe..? – Ankit Srivastava Mar 04 '18 at 08:09
  • 1
    @AnkitSrivastava *exclusion* is when thread A blocks thread B from going down a code path. If that code path is safe for execution from multiple threads, then exclusion is not necessary. *Not thread safe* means the code path may yield undefined results if A and B go down it concurrently. That is *exclusion* can be used to make something thread safe, but thread safety does not require exclusive-- non-concurrent-- execution. – bbum Mar 04 '18 at 18:00
16

This link has the break down

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.spelling.property

assign implies __unsafe_unretained ownership.

copy implies __strong ownership, as well as the usual behavior of copy semantics on the setter.

retain implies __strong ownership.

strong implies __strong ownership.

unsafe_unretained implies __unsafe_unretained ownership.

weak implies __weak ownership.

Mick MacCallum
  • 129,200
  • 40
  • 280
  • 281
  • isn't the Assign property only used for iVar and values? So why is it unsafe and why is there a need to note that it is unretained? – mskw Apr 04 '13 at 21:47
7

Great answers! One thing that I would like to clarify deeper is nonatomic/atomic. The user should understand that this property - "atomicity" spreads only on the attribute's reference and not on it's contents. I.e. atomic will guarantee the user atomicity for reading/setting the pointer and only the pointer to the attribute. For example:

@interface MyClass: NSObject
@property (atomic, strong) NSDictionary *dict;
...

In this case it is guaranteed that the pointer to the dict will be read/set in the atomic manner by different threads. BUT the dict itself (the dictionary dict pointing to) is still thread unsafe, i.e. all read/add operations to the dictionary are still thread unsafe.

If you need thread safe collection you either have bad architecture (more often) OR real requirement (more rare). If it is "real requirement" - you should either find good&tested thread safe collection component OR be prepared for trials and tribulations writing your own one. It latter case look at "lock-free", "wait-free" paradigms. Looks like rocket-science at a first glance, but could help you achieving fantastic performance in comparison to "usual locking".

nickolay
  • 3,643
  • 3
  • 32
  • 40