知识点：可变数组的属性使用copy修饰的后果

视频What's New in LLVM
中，从12:05的时间开始有个关于NSMutableArray可变数组属性的使用问题。

运行后报错图如下：

self.photos的实际类型是 __NSMutable0,也就NSArray类型。没有addObject的方法。

OC是门动态型语言，在编译阶段不会做类型检测。OC的内存管理是引用计数，在ARC环境下，属性@property的内存管理语义关键字有copy,weak,strong,asssin。在编译阶段，默认情况下编译器会生成一个成员变量、一个setter方法、一个getter方法。而在setter方法中，会根据内存管理语义做相应的引用计数相关的操作。当使用copy修饰属性时，在setter中实际操作是拷贝了一份不可变的类型对象。这样的话，即使是其是可变类型，在被赋值后，我们得到的是却是不可变类型的对象。
OC具有多态性，父类可以指向子类。对象最终类型会在运行期根据实例化对象确认。在运行时阶段其isa指向的是[NSArray Class]。那么当向self.photos发送一个addObject消息时，self.photos对象是接收不到这个消息的。因为addObject是NSArray的子类NSMutbleArray的方法。
属性语义多种：

原子性（Atomicity）:原子性(atomic)、非原子性(nonatomic)
Setter语义（Setter Semantics）:strong,weak,copy,asssin
读写属性(Writability): readwrite/readonly
原子性是具有线程安全的，会在属性的setter方法内部加个一个自旋锁、而非原子性是不会在setter方法中加锁的，是非线程安全的。在小型设备的上，内存空间是有限的。给属性加自旋锁是非常消耗资源的。并且不一定说使用了原子性就能保证该属性线程安全。这个仅仅是在setter方法中是安全的，这也是atomic该做的事。如果绕开setter方法使用其他的方式给属性赋值，依然是不安全的，比如使用KVC。

在此情况下，实际编译器添加setter方法如下：

// ARC
- (void)setPhotos:(NSMutableArray<UIImage *> *)photos{
    // 1. 开始加锁，非自然语言，这里不写代码了
    _photos = [photos copy];
    // 2. 加锁结束
}

那么得到的是个self.photos实际是NSArray类。

从上就发现了2个问题：属性就是使用了关键字atomic、copy修饰。那么这里会加锁并且得到NSArray类的self.photos。

相关概念：

自旋锁：当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会一直等待（不会睡眠），当上一个线程的任务执行完毕，下一个线程会立即执行。

自旋锁应用场景：
比较适合做一些不耗时的操作

1、修改copy语义在setter中默认内容：

方式一:
手动重写setter方法，使用赋值前mutableCopy。如下，这样获取到的就是NSMutableArray类型的对象。

- (void)setPhotos:(NSMutableArray<UIImage *> *)photos{
    _photos = [photos mutableCopy];
}

方式二:
使用关键字strong修饰属性。我们得到的依然是可变类型。

- (void)setPhotos:(NSMutableArray<UIImage *> *)photos{
    _photos = photos;
}