集合深浅拷贝以及经常遇到的坑

[TOC]

引言

根据拷贝内容的不同,分为深浅拷贝

  • 深拷贝:内容拷贝,且将指针指向新的内容
  • 浅拷贝:只是简单的指针赋值

苹果为什么这么设计呢?总结起来很简单:即安全又省内存。但是要理解或者避免踩一些坑,还需要看下面的介绍

内存

不得不先说到内存,又不得不说内存分区:程序底层——程序如何在RAM ROM运行,内存分配与分区

看下面图片:

memoryZone

obj1是定义在函数外部的全局变量,处于全局区;obj2是定义在函数内的局部变量,处于栈区。它们都指向了处于堆区的对象。

obj1与obj2是指针,它们指向的对象是内容,那么现在再看深浅拷贝的现象,或者说执行的结果:浅拷贝只是多个指针指向同一对象内容,深拷贝就是每个指针都指向了一个对象内容,互不影响。

自定义对象需要自己实现NSCoping协议,一般情况下,自定义对象都是可变对象,本节讨论的也都是针对系统对象
指针也是会存在堆区的,比如在block里面我们知道,如果指针使用了__block修饰,那么指针会存放在堆区。

返回值的一些基本规则

无论是集合对象还是非集合对象,在收到copy和mutableCopy消息时,都遵守以下规则:

  • 1 copy返回immutable对象;
  • 2 mutableCopy返回mutable对象;

那么很简单,可变与不可变对象的转变:

  • 不可变对象→可变对象的转换:不可变对象.mutableCopy。
  • 可变->不可变:可变对象.copy;

集合拷贝

系统提供的集合类型,比如字典、数组、NSSet等集合类型内存基本都是如下结构:集合内存结构图

arrMemory

我们可以上面代码(代码处于方法内)做个分析,加深对内存的理解。@"123"、@"456"是const属性,因此处于常量区,指针str1、str2、arr局部变量指针处于栈区,@[]数组内容存放位置处于堆区,数组里面的内容存放的是指针str1与str2,当然处于堆区

其实arr = @[str1,str2]相当于[arr addObject:str1];[arr addObject:str2];,数组里面有两个强指针指向了对象@"123"@"456"

图中只是字符串是常量所以在常量区,如果他们是NSDate、UIView等等则会处于堆区

下面的分析也是基于三种程度的拷贝,记为CopyLevel,拷贝层次,简写CL1、CL2、CL3

  • CL1:arr数组指针,如果只发生这层拷贝,则和非集合对象一样,是浅拷贝
  • CL2:arr数组指针指向的的内容,即存储的对象指针。发生本层拷贝,从非集合角度来说已经发生了内容拷贝,即深拷贝。但从集合角度来说,还是浅拷贝。
  • CL3:arr数组里面存储的指针指向的内容,如果发生本层拷贝,可以叫做集合的单层深拷贝。

毫无疑问,CL1是肯定会进行的。重点就在于CL2于CL3.

不可变集合的copy与mutableCopy

下面代码,不可变集合arrM1的copy与mutableCopy。arrM2:mutableCopy,arr:copy

arrTwoCopy
  • 根据第一行打印结果:arrM2和arr都进行CL1拷贝
  • 第二行打印结果:arrM2与arrM1结果不同,说明进行了数组拷贝;arr与arrM1结果相同,说明没有,进行数组拷贝
  • 第三行打印结果:都相同,说明指向的内容没有发生拷贝

可变集合的copy与mutableCopy

下面代码,可变集合arrM1的copy与mutableCopy。arrM2:mutableCopy,arr:copy

arrMTwoCopy
  • 根据第一行打印结果:arrM2和arr都进行CL1拷贝
  • 第二行打印结果:结果均不同,说明都进行了数组拷贝;
  • 第三行打印结果:都相同,说明指向的内容没有发生拷贝

一般结论

我们知道,对于非集合对象,有如下结论:

// 不可变,线程安全
[immutableObject copy] // 浅复制
[immutableObject mutableCopy] // 深复制,对于集合则是只拷⻉贝数组的内容,数组的内容是指针,而指针的内容不会被拷⻉

// 可变对象,线程不安全
[mutableObject copy] //深复制,对于集合则是只拷⻉贝数组的内容,数组的内容是指针,而指针的内容不会被拷⻉
[mutableObject mutableCopy] //深复制,对于集合则是只拷⻉贝数组的内容,数组的内容是指针,而指针的内容不会被拷⻉

集合的单层深拷贝,CL3层的拷贝(one-level-deep copy)

我们需要使用- (instancetype)initWithArray:(NSArray<ObjectType> *)array copyItems:(BOOL)flag;方法,且flag为YES。

arrOneLevelCopy

可以看到,三行打印结果都不一样,即发生了CL3层的拷贝。

此方法执行后,arrM1集合里的每个对象都会收到 copyWithZone: 消息。如果集合里的对象遵循 NSCopying 协议,那么对象就会被深拷贝到新的集合,如果没有遵循就直接崩溃了。

等一等,好像有另一个问题:此方法只是会给集合的每个对象发送copyWithZone:方法,那么对于不可变对象,copyWithZone:的执行还是浅拷贝。读者大概也注意到了,图中示例代码,arrM1数组存的也是可变对象dict1,所以有CL3层的拷贝。那如果arrM1存的不是可变对象呢?结果就是没有CL3层的拷贝,大家可以用代码测试下!

为啥叫单层深复制呢? 因为它只给arrM1数组存的对象发送了copyWithZone:方法,而没有对dict1发送copyWithZone:方法,dict1也是集合,它里面也存放着对象呢。。。即集合里面存放的集合。。。好绕,哈哈

另外,除了此方法,集合的解档归档,也是可以实现单层深拷贝的。

绕的东西就到这里,下面看些感兴趣的东西:

一些坑

  • Mutable变copy的坑

有一点需要注意了:copy返回值为不可变对象,如果使用可变对象的接口就会crash。例如:

- (void)arrMCopyTest {
    NSMutableArray *arrM = [NSMutableArray arrayWithObjects:@"123",@"456", nil];
    NSMutableArray *arr = [arrM copy];
    // 下面代码崩溃
    [arr addObject:@"789"];
}

[arrM copy];返回的是不可变类型,即NSArray,向一个NSArray对象发送addObject消息当然方法找不到崩溃。

另一个问题,arr是NSMutableArray类型,它指向父类NSArray编译器为什么不报错呢?copy返回的是id类型,编译器不会对id(俗称万能指针)进行类型检查,所以会经常看到推荐使用instancetype,而不是id

下面的类似错误就很常见了:

@property (nonatomic, copy) NSMutableArray *arr;

- (void)arrMCopyTest {
    NSMutableArray *arrM = [NSMutableArray arrayWithObjects:@"123",@"456", nil];
    self.arr = arrM;
    // 下面代码崩溃
    [self.arr addObject:@"789"];
}

因为self.arr为copy修饰,那么self.arr = arrM就相当于_arr = [arrM copy]

  • 属性指定为copy,却没有被copy
@property (nonatomic, copy) NSString *str;
- (void)viewDidLoad {
    NSMutableString *str = [NSMutableString stringWithFormat:@"123"];
    // self.str = str;
    _str = str;
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    
        [str appendString:@"456"];
        NSLog(@"change");
    });
}

这里在block里面对str进行操作,居然没有对它进行__block修饰!!!感兴趣可以看看这篇博客:iOS中block的使用、实现底层、循环引用、存储位置

打印结果:

2017-07-23 00:33:06.344 CopyTest[95611:31912803] 123
2017-07-23 00:33:07.518 CopyTest[95611:31912803] change
2017-07-23 00:33:08.636 CopyTest[95611:31912803] 123456

都是123456,self.str被意外改变了,如果将代码_str = str;-->self.str = str;值就不会改变了。因为相当于_str = [str copy];

所以建议除了在初始化和释放时(init、dealloc方法中,懒加载还是使用self.),苹果推荐我们使用_下划线的方式直接访问变量,其它地方尽量使用self.来访问。另外我们还经常getter或者setter方法里面做一些自定义操作,如果_方式则这些自定义操作就不会被执行。而且在block里面使用_方式访问变量会更隐蔽的引起循环引用的问题!

  • setter方法
@property (nonatomic, copy) NSString *str;

- (void)setStr:(NSString *)str {
    // _str = str; 不要这样写
    _str = [str copy];
}

讲了这些,大家会不会猛然想到

@property (nonatomic, weak) id delegate;
_delegate = obj;

这样会不会造成_delegate为指向的对象引用计数为0时,系统还会不会将_delegate置为nil?答案是,您多虑了,会的。这和copy不一样。为啥不一样?牵涉到runtime哈希表什么的就不在展开了。。。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,088评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,715评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,361评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,099评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 60,987评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,063评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,486评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,175评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,440评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,518评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,305评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,190评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,550评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,880评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,152评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,451评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,637评论 2 335

推荐阅读更多精彩内容