ARC&MRC
内存管理涉及到以下几个方法：
alloc : 分配对象的内存空间。
retain : 使一个对象的引用计数加1
release : 使对象的引用计数减1
retainCount : 获取当前对象的引用计数值
autorelease : 当前对象会在autoreleasePool结束的时候,调用这个对象的release操作,进行引用计数减1
dealloc : 在MRC中若调用dealloc,需要显示的调用[super dealloc],来释放父类的相关成员变量
MRC
什么是MRC：通过手动引用计数来进行对象的内存管理。
MRC中方法retain / release / retainCount / autoreleaset / dealloc, 除了dealloc外，其他的都是MRC特有的，在ARC中若调用这些方法,会引起编译报错。
ARC
什么是ARC：通过自动引用计数来管理内存。
之前我认为编译器为我们在对应的位置自动插入相应的retain和release操作,但不完善
1.ARC不仅是需要编译器LLVM自动为我们在对应的位置插入相应的retain和release操作,还需要Runtime的功能支持,
然后由编译器LLVM和Runtime来共同协作才能组成ARC的全部功能。
2.ARC中方法alloc/dealloc
ARC中禁止手动调用retain / release / retainCount / dealloc,
ARC可以重写某个对象的delloc方法,但不能在dealloc中显示调用[super dealloc]。
3.ARC中新增weak, strong属性关键字。
ARC和MRC的区别
1.MRC手动管理内存,ARC是由编译器LLVM和Runtime协作进行自动引用计数来自动管理内存。
2.MRC可以调用一些引用计数相关方法,但ARC中不能调用。
另外,因为ARC是由编译器为我们自动插入retain和release的,说明ARC中有相当一大部分是由MRC的机制和原理组成的，
所以为了更好的理解iOS的内存管理方式，我们需要深入的了解关于引用计数原理来管理内存的一个方式和原理。
引用计数管理
alloc内部实现
- 经过一系列的函数封装及调用,最终调用了C函数calloc。
- 关于通过alloc函数分配内存之后的对象,并没有设置引用计数为1，
但当我们通过retainCount获取引用计数却为1，原因是在retainCount内部实现。
retain内部实现
/*通过当前对象的指针this,到SideTables当中,
经过哈希运算,去获取它所属的SideTable
*/
SideTable& table = SideTables()[this];
/*再通过当前对象的指针this,在SideTable中,也是通过哈希查找,
从SideTable当中的引用计数表refcnts中,
去获取当前对象的引用计数值refcntStorage(无符号long型的值)
*/
size_t& refcntStorage = table.refcnts[this];
/*
然后再对引用计数值进行+1操作
*/
refcntStorage += SIDE_TABLE_RC_ONE;
- 经历两次哈希查找, size_t是无符号long型的一个值。
- 注意当对引用计数进行+1操作时,并不是直接加的1,而是加的一个宏定义,
是因为size_t在存储引用计数变量时,里面的64个bit位,前两个位置不是存储引用计数的,
后面62位存储的才是引用计数,所以我们所谓的+1操作，加的是对应的偏移量操作（这个偏移量是4，给我们反映的结果就是+1操作）。
在进行retain操作时,系统是如何查找对应的引用计数的?
经过两次哈希查找,找到对应的引用计数值,然后进行相应的加1操作。
release内部实现 (和retain正好相反 -1操作)
/*通过当前对象的指针this,到SideTables当中,
经过哈希运算,去获取它所属的SideTable
*/
SideTable& table = SideTables()[this];
/*根据当前对象指针,
访问SideTable当中的引用计数表refcnts,
去查找这个对象对应的引用计数值
*/
RefcountMap :: iterator it = table.refcnts.find[this];
/*
然后对这个值进行减1操作
*/
it -> second -= SIDE_TABLE_RC_ONE;
retainCount内部实现
SideTable& table = SideTables()[this];
//声明一个局部变量,指定它的值为1
size_t refcnt_result = 1;
//通过当前对象到引用计数表中去查找
RefcountMap :: iterator it = table.refcnts.find[this];
//把查找的结果做一个向右偏移的操作,再结合局部变量1做一个增加1的操作,最后返回给调用方
refcnt_result += it -> second >> SIDE_TABLE_RC_SHIFT;
关于通过alloc函数分配内存之后的对象,并没有设置引用计数为1，但当我们通过retainCount获取引用计数却为1问题：
刚刚新alloc出来的一个对象,在引用计数表中,是没有这个对象相关联的key-value映射,
这个值读出来的it -> second应该为0,然后由于局部变量refcnt_result是1,
所以此时,只经过alloc调用的对象,调用它的retainCount,获取到的就是1。
dealloc内部实现
首先调用_objc_rootDealloc这样一个私有函数,这个函数内会调用rootDealloc函数,
在rootDealloc函数内部判断当前对象是否可以直接释放,直接释放有以下几个判断条件
1.判断当前对象是否使用了非指针型的isa。
2.判断当前对象是否被weak指针指向。
3.判断当前对象是否有关联对象。
4.判断当前对象的内部实现是否涉及C++相关内容或者当前对象是否使用ARC来管理内存。
5.判断当前对象的引用计数是否是通过sideTable中的引用计数表来维护的。
如果采用非指针型的isa指针,它当中会存储一部分引用计数的值,当超出上线时,会使用sideTable方式去存储
- 只有当当前对象既不是非指针型的isa指针,
- 同时没有弱引用,
- 也没有关联对象,
- 也没有涉及到C++的相关内容,
- 也没有涉及到ARC,
- 也没有采用sideTable来存储引用计数,
只有上面条件全部满足,才可以调用C函数的free直接进行内存释放,
否则就会调用object_dispose()对象清除函数,做后续的清理,然后结束。
为什么要进行多种判断才能释放对象?
1.如果当前对象有弱引用,那么在这个对象释放废弃的时候,我们需要对引用对象进行处理。
2.如果当前对象有关联对象,那么在这个对象释放废弃的时候,我们需要对它的关联对象进行处理。
3.包括引用计数和C++的相关内容 等都需要处理。
object_dispose()函数的内部实现：
1.首先调用objc_destructInstance()函数,这个函数是销毁实例的含义。
2.当这个方法调用之后,再调用C函数的free,最后结束dealloc。
objc_destructInstance()函数的内部实现：
在objc_destructInstance()中,首先会判断,当前对象中是否有C++相关的内容,或者当前对象是否采用了ARC(hasCxxDtor)?
- 如果没有的话.会判断当前对象是否有关联对象（hasAssociatedObjects）,
- 如果有的话,调用_object_remove_assocations()对象的相关关联对象的移除函数后,再调用调用clearDeallocating()函数。
- 如果没有的话,调用clearDeallocating()函数。
- 如果有的话,调用object_cxxDestruct()移除后，再判断当前对象是否有关联对象hasAssociatedObjects等。
我们通过关联对象的技术,为一个类添加了一些实例变量,那么我们在对象的dealloc方法中,是否有必要对它的关联对象进行移除操作呢?
- 在系统的dealloc内部实现中,会自动判断当前对象是否有关联对象。
- 如果有的话,系统内部就帮助我们把相关的关联对象移除了。
clearDeallocating方法的内部实现
- 首先调用sidetable_clearDeallocating函数。
- 之后调用weak_clear_no_lock()函数,将指向该对象的弱引用指针置为nil。
- 然后调用table的引用计数擦除操作,实际上就是将当前对象在引用计数表中的一些存储数据给清除掉,然后就结束了调用流程。
备注:如果说一个对象有weak指针指向它,当这个对象dealloc或者废弃之后,它的weak指针为何会被自动置为nil？
是因为在dealloc的内部实现中,有做关于它相关的弱引用指针自动置为nil的操作。
