iOS面试题(十九)内存管理--ARC&MRC&引用计数管理

本文深入解析内存管理核心概念,对比MRC与ARC机制,探讨引用计数管理原理,揭示ARC内部实现细节,以及Runtime协作机制。通过具体方法如alloc、retain、release、retainCount和dealloc的内部实现,阐述内存管理的复杂性和优化策略。
摘要由CSDN通过智能技术生成

 

5.内存管理

  • 内存布局
  • 内存管理方案(更好的简述内存管理方案相关的问题,就要明白他们的数据结构)
  • 数据结构
  • ARC&MRC(什么是ARC,什么是MRC,他们的区别以及各自实现的机制、原理)
  • 引用计数机制(什么是引用计数机制?内存是怎样管理的?)
  • 弱引用表(我们声明weak的一个变量,为什么在内存释放的时候,weak指针会自动置为nil?弱引用变量内存是怎么管理的?)
  • 自动释放池(AutoReleasePool)的实现机制和原理是怎样的?
  • 循环引用

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的内存管理方式,我们需要深入的了解关于引用计数原理来管理内存的一个方式和原理。
比如说ARC里面涉及到了Runtime协作,针对这个点考察比如 weak变量为什么在对象释放的时候会自动置为nil

 

引用计数管理

实现原理分析

alloc /retain/release/retainCount/ dealloc 系统方法内部实现

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()对象清除函数,做后续的清理,然后结束

为什么要进行多种判断才能释放对象?

  • 如果当前对象有弱引用,那么在这个对象释放废弃的时候,我们需要对引用对象进行处理
  • 如果当前对象有关联对象,那么在这个对象释放废弃的时候,我们需要对它的关联对象进行处理
  • 包括引用计数和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的操作

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值