这个问题很少遇到，但是答案当然不是。
atomic在set方法里加了锁，防止了多线程一直去写这个property，造成难以预计的数值。但这也只是读写的锁定。跟线程安全其实还是差一些。看下面。
@interface MONPerson : NSObject
@property (copy) NSString * firstName;
@property (copy) NSString * lastName;
- (NSString *)fullName;
@end
Thread A:
p.firstName = @"Rob";
Thread B:
p.firstName = @"Robert";
Thread A:
label.string = p.firstName; // << uh, oh -- will be Robert
但是如果有个C也在写，D在读取，D会读到一些随机的值（ABC修改的值），这就不是线程安全的了。最好的方法是使用lock。
Thread A:
[p lock]; // << wait for it… … … …
// Thread B now cannot access
pp.firstName = @"Rob";
NSString fullName = p.fullName;
[p unlock];
// Thread B can now access plabel.string = fullName;
Thread B:
[p lock]; // << wait for it… … … …
// Thread A now cannot access p…
[p unlock];
atomic有个很大的问题是很慢，要比nonatomic慢20倍。
当然最后建议这种数值数值变化可以让服务器来做。
我们可以将多线程不安全解释为：多线程访问时出现意料之外的结果。这个意料之外的结果包含几种场景，不一定是指crash。
atomic可以保证setter和getter存取的线程安全，不会让你拿到一个崩溃的值，但是这个对象就不是线程安全的。
