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

问题

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

运行后报错图以下：

分析

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

进一步探讨

1. OC是门动态型语言，在编译阶段不会作类型检测。OC的内存管理是引用计数，在ARC环境下，属性@property的内存管理语义关键字有copy,weak,strong,asssin。在编译阶段，默认状况下编译器会生成一个成员变量、一个setter方法、一个getter方法。而在setter方法中，会根据内存管理语义作相应的引用计数相关的操做。当使用copy修饰属性时，在setter中实际操做是拷贝了一份不可变的类型对象。这样的话，即便是其是可变类型，在被赋值后，咱们获得的是倒是不可变类型的对象。

2. OC具备多态性，父类能够指向子类。对象最终类型会在运行期根据实例化对象确认。在运行时阶段其isa指向的是[NSArray Class]。那么当向self.photos发送一个addObject消息时，self.photos对象是接收不到这个消息的。由于addObject是NSArray的子类NSMutbleArray的方法。

3. 属性语义多种：

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

4. ARC下，属性的默认语义是：

• 基本数据：atomic、assgin、readwrite
• 普通的OC对象：atomic、strong、readwrite

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

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

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

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

相关概念：

1. 自旋锁：当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会一直等待（不会睡眠），当上一个线程的任务执行完毕，下一个线程会当即执行。
2. 自旋锁应用场景： 比较适合作一些不耗时的操做

解决

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

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

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

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

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

二、原子性修改： 使用：nonatomic，减小小型设备中性能消耗。