OC总结篇 - 内存管理

内存管理

内存在哪

`硬盘RAM`
手机中关于本机里的总容量和可用容量指的都是硬盘,也就是说,安装的APP占用的是硬盘空间

`内存ROM`
打开APP时,占用的才是内存空间

`CPU`
负责计算,比如我们写好一个程序,运行时会有一段加载蓝色进度条的过程,其实是 CPU 将我们写的 OC 语言转化成了计算机能读懂的二进制语言


手机中下载的 APP 都在硬盘中存放,当你打开了某一 APP, 它就被移到了内存中
若你按 HOME 键,APP 仍在内存中,再打开时能迅速打开
但若你将它杀掉, 则回到了硬盘,再次打开时,会缓慢的加载,因为要从硬盘移动到内存
我们平时说的沙盒,是在硬盘里
我们平时说的内存管理,是运行时管理上面内存
我们平时说的缓存,是缓存到硬盘中,运行时先从硬盘去取,硬盘没有再去下载

为什么要进行内存管理

若你的APP某个页面没做好内存管理,那么当运行时,系统内存不够时,会看你didReceiveMemoryWarning中是否进行了处理
若没有的话,手机会关掉你之前打开的在后台运行的APP,来给你腾内存空间
当把全部内存空间都给你用了,还不够,就会崩掉
所以,不管理会崩溃

内存管理,是指运行时对计算机内存资源的分配和使用,目的是高效，快速的分配，并且在适当的时候释放和回收内存资源。

内存区域

栈: 放函数,方法,和一些临时变量
堆: alloc分配的对象,block,copy
BSS:未初始化的全局变量,静态变量
数据段:初始化的全局变量,静态变量
代码段: 代码,加载到内存上

客户端能做的内存管理,是对堆上的OC对象进行内存管理
栈对应的函数退出后在内存中就销毁掉了

内存管理方案

1. TaggedPointer
2. NONPOINTER_ISA
3. 散列表
   引用计数表RefcountMap
   弱引用表weak_table_t
   自旋锁spinlock_t

1. TaggedPointer
   对一些小对象,如NSNumber等,采用的是TaggedPointer这种内存管理方案


2. NONPOINTER_ISA
   对于64位架构下的iOS应用程序采用的是NONPOINTER_ISA这种内存管理方案
   在64位架构下,ISA这个指针本身是占64个bit位的,但其实有32位或者40位就够用了,剩余的bit位其实是浪费的
   苹果为了提高内存的利用率,在iSA剩余的这些bit位当中,存储了一些关于内存管理方面的相关内容,这个叫非指针型的ISA


3. 散列表
引用计数表RefcountMap
弱引用表weak_table_t
自旋锁spinlock_t

散列表内部是个Side Tables()结构,是哈希表,里面有多个Side Table表,也叫做分离锁
为何要多个Side Table表?一个不行吗?
假如只有一张Side Table,相当于我们在内存当中分配的所有对象的引用计数都放到了一张大表中,如果要操作某个对象的引用计数值进行修改,由于所有的对象可能是在不同的线程中分配创建的,那么对这张表操作时就需要进行加锁处理,来保证数据访问的安全,这样就存在了效率问题
分离锁:可以把内存对象所对应的引用计数表分拆成多个部分,假设分拆成8个,需要对8个表分别加锁,假如对象A在表1中,对象B在表2中,当A和B同时进行引用计数操作时,可以并发操作,但如果只有一张表就只能按顺序操作,分离锁可以提高访问效率

`引用计数表RefcountMap`
引用计数表是哈希表,可以理解为是一个字典,可以通过指针,找到对应对象的引用计数,这个查找过程是一个哈希查找,这个哈希算法实际上是对传入对象的指针做一个伪装的操作,然后去获取对应的引用计数
之所以使用哈希查找,是为了提高查找效率,之所以能提高查找效率,是因为我们存储一个对象的引用计数时,是通过同一个函数来计算存储位置的,而获取对象的引用计数值的时候,也通过同一个函数来计算应该获取的索引位置
因为插入和获取都是通过同一个函数来计算位置,就会避免循环遍历的操作,所以才说,哈希查找可以提高查找效率
对象指针可以作为一个key,经过Hash函数的一个运算,会计算出一个值Value,来决定出这个对象所对应的Side Table是哪张,或者说在数组的位置索引是哪个

`弱引用表weak_table_t`
弱引用表示根据weak_table_t来定义的,也是一张哈希表,给与一个对象的指针作为key,通过一个哈希函数,就可以计算出对应的弱引用的对象的存储位置

`自旋锁spinlock_t`
适用于轻量访问
是一种"忙等"的锁,如果当前锁已被其他线程获取,当前线程会不断探测这个锁有没有被释放,如果被释放了,线程就会第一时间去获取这个锁

其他锁,比如`信号量`:当它获取不到这个锁时,会把自己的线程进行阻塞休眠,然后等到其他线程释放这个锁的时候,再唤醒当前线程

自动引用计数方案是怎么管理内存的

MRC手动管理内存
ARC由编译器和Runtime协作进行自动引用计数管理内存,编译器会为我们自动插入retain和release

自动引用计数主要通过下面几个方法管理内存
alloc, retainCount, retain, release, dealloc, AutoreleasePool - 自动释放池
这几个方法的内部实现如下:


alloc:
通过alloc函数分配内存之后的对象,并没有设置引用计数为1
刚刚新alloc出来的一个对象,在引用计数表中,是没有这个对象相关联的key-value映射,读出来的it -> second应该为0



retainCount:
但当我们通过retainCount获取引用计数却为1
声明一个局部变量,指定它的值为1,通过当前对象到引用计数表中去查找,把查找的结果做一个向右偏移的操作,再结合局部变量1做一个增加1的操作,最后返回给调用方



retain:
经过哈希查找,找到对应的引用计数值,然后进行相应的加1操作



release:
根据当前对象指针,访问SideTable当中的引用计数表refcnts,去查找这个对象对应的引用计数值,然后对这个值进行减1操作



dealloc:
在内部判断当前对象是否可以直接释放,直接释放有以下几个判断条件
1.判断当前对象是否使用了非指针型的isa
2.判断当前对象是否被weak指针指向
3.判断当前对象是否有关联对象
4.判断当前对象的内部实现是否涉及C++相关内容以及当前对象是否使用ARC来管理内存
5.判断当前对象的引用计数是否是通过sideTable中的引用计数表来维护的
只有上面条件全部满足,才可以调用C函数的free直接进行内存释放
否则就会调用object_dispose()对象清除函数,做后续的清理,然后结束
清除流程是:有关联对象就移除关联对象,有弱引用就将弱引用置为nil,然后从弱引用计数表中擦除该对象
所以说,当一个对象有weak指针指向它,当这个对象dealloc或者废弃之后,它的weak指针为何会被自动置为nil
是因为在dealloc的内部实现中,有做关于它相关的弱引用指针自动置为nil的操作



AutoreleasePool - 自动释放池
作用: 
在每一次runloop循环将要结束时,会对前一次创建的AutoreleasePool进行pop操作,同时会push进来一个新的AutoreleasePool
在viewDidLoad中所创建的array对象,是在当次runloop将要结束的时候,调用AutoreleasePoolPage的pop方法中释放的

数据结构
是以栈为结点通过双向链表的形式组合而成
是和线程一一对应的

内部实现
在autoreleasepool中的所有对象,都会添加到自动释放池中,当进行pop之后, autoreleasepool中所有对象都会被发送一次release消息

内存管理的风险-循环引用

三种循环引用类型

1. 自循环引用
2. 相互循环引用
3. 多循环引用

常见的会导致循环引用

1. 代理
2. block
3. NSTimer
   https://www.jianshu.com/p/820e7a66f6a0

如何避免循环引用

1. 代理
   在使用代理时,两个对象,一个强引用,一个弱引用,避免产生相互循环引用

2. block
   __block
  MRC下,__block修饰对象不会增加其引用计数,避免了循环引用
  ARC下,__block修饰对象会被强引用,无法避免循环引用,需手动解环

3. NSTimer



其他方法
1. 在合适的时机手动断环

2. __weak
修饰对象不会增加其引用计数,避免了循环引用,例如对象B会强持有A,对象A弱引用B

3. __unsafe_unretained
修饰对象不会增加其引用计数,避免了循环引用
如果被修饰的对象在某一时机被释放,会产生悬垂指针,再通过这个指针去访问原对象的话,会导致内存泄露,所以一般不建议用__unsafe_unretained去解除循环引用

__weak

如何检测内存泄露

MLeaksFinder