iOS开发 - 穿针引线之内存管理

本文深入探讨了iOS下的内存管理机制,包括MRC与ARC的区别、自动释放池的工作原理及其实现细节、引用计数的存储方式等核心内容。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

1.MRC下内存管理有四句经典总结:

2.在ARC下,如果想要在代码中使用ARC,则需要满足三个条件:

3.内存管理究竟是谁的内存管理?

4.自动释放池最可能出现的地方

5.ARC的命名规则

6.循环引用的内存管理

7.自动释放池的原理

9.ARC下引用计数如何存储

10.isa里面都存储了哪些东西

11.Dealloc做了些什么?


1.MRC下内存管理有四句经典总结:

  • 自己创建的对象,自己持有;
  • 不是自己创建的对象,自己也能持有;
  • 自己创建的对象不需要了,自己释放;
  • 不是自己创建的对象,自己不能释放。

就这几句话几乎总结了内存管理的半壁江山,虽然MRC距离我们已经很遥远了,但我们依然应该牢记这四句话。

2.在ARC下,如果想要在代码中使用ARC,则需要满足三个条件:

  • 能够确定哪些对象需要进行内存管理;
  • 能够表明如何去管理内存;
  • 有可行的的办法传递对象的所有权。

ARC只对可保留的对象指针(ROPs)有效,可保留的对象指针主要有三种:

  • 代码块指针
  • Object-C对象指针
  • 通过__atttribute__((NSObject))类型定义的指针

前两个都很好理解,只有第三个不好理解,__atttribute__((NSObject))在代码中很少见,他它的调用出现在main函数之前,math-O文件加载的过程中,是一个c类型的函数,据文档上说,主要和初始化相关的工作有关,具体不是很清楚,有兴趣的可以自行查阅。

3.内存管理究竟是谁的内存管理?

内存管理是Cocoa的内存管理!为什么这么说呢?因为并不是所有的框架都支持ARC,比如Core Foundation。

我们都学习过retain,release和autorelease。Cocoa有许多内存管理的约定,但他们都很简单,而我们经常会把他们复杂化,而忽略这些规则也是一种常犯的错误,如果你对retain和release还没有真正掌握以处理某些问题,那不妨试先去熟悉一下,加深掌握,然后再继续看这篇博客。

我简单说下这些规则:

  • 当你使用new,alloc和copy方法创建一个对象时,该对象的引用计数器的值为1.当不再使用该对象时,你应该向该对象发送一条release或者autorelease消息。这样,该对象将在其生命周期结束时被销毁。
  • 当你通过其他方法获取一个对象时,假设该对象的引用计数器的值为1,而且已经被设置为自动释放,那么你不需要执行任何的操作来确保该对象得到释放。如果你打算在某一时刻拥有该对象,你就需要对它做retain操作,并在使用结束后将它释放。
  • 如果你保留了某对象,则需要在结束时释放或者通过某种自动释放的方式释放该对象,且必须保证retain和release是成对出现的。

这几条原则和我们上面所述MRC下四大原则相似。

4.自动释放池最可能出现的地方

内存管理是一个棘手的问题,从我们学过的set方法和我前面讲到的内容,你可能已经意识到了一些问题,没错,对象的释放,我们都知道,当对象不再使用的时候必须将其释放,但在某些情况下想要弄清楚什么时候不再使用一个对象并不容易。这时候,就有了自动释放池的存在。

自动释放池正是存在于Cocoa中的一个概念,我们常说自动释放池,但实际中可能九成以上的程序员根本没有真正使用过,但你可能在Xcode生成的示例代码中见过:

#import <UIKit/UIKit.h>
#import "AppDelegate.h"

int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

没错,这是在main函数中的自动释放池块。

自动释放池的概念并不神秘,从字面意思来说,就是自动管理内存,并在合适的时候自动释放的一个用来存放那些能够被自动释放的对象的池子,当然,自动释放池也需要释放,这点,我们后面再讲。

自动释放池的创建有两种:

  • 通过@autoreleasepool关键字
  • 通过NSAutoreleasePool对象

在我们一直使用的Foundation库工具中,创建和销毁自动释放池已经由@autorelease关键字来完成。当你使用@autorelease{}时,所有在花括号里的代码都会被放入这个新池子中,如果你的程序是内存密集型,你就可以使用这种自动释放池。

有一点你要知道,任何在花括号内的变量在括号外无法使用。这是典型的C语言有效范围,比如说在各类循环中。

第二种使用NSAutoreleasePool的方法,创建和释放NSAutoreleasePool对象之间的代码就会使用这个新的池子。创建后成为活动的池子,其引用计数为1,释放后,其引用计数为0,这个池子被销毁。在销毁的过程中,被加在其内的对象也将会被全部释放。

这里推荐使用@autoreleasepool关键字方法,因为他比对象方法更快,而Object-C语言创建和释放的能力远在我们开发者之上。

autorelease经典案例:

for (int i = 0; i < 1000000000; ++i) {
    @autoreleasepool {
        id object = [someArray objectAtIndex:i];
        NSString *desc = [object dealSomething];
    }
}

若是不写autoreasepool块,任由for循环无限大,将会导致ARC内存爆炸。 

5.ARC的命名规则

使用ARC的时候有两种命名规则需要注意:

  • 属性名称不能以new开头
  • 属性不能只有一个read-only而没有内存管理特性。如果没有启动ARC当然没关系,但启动了ARC功能,就必须指定由谁来管理内存,因为默认的特性是assign

需要注意的是,内存管理的关键字和特性是不能一起使用的,两者相互排斥。这里有必要说明下关键字和特性的差别,以strong为例,__strong是关键字,strong是特性,关于使用和出现的地方,想必大家都是清楚的,博主不再多此一举。

6.循环引用的内存管理

前面有讲过可保留指针,内存管理粗暴点讲就是指针的管理,可能不太恰当,但指针和内存确实息息相关。

还有一种内存管理叫做循环引用,循环引用出现的地方很固定,当然这是在ARC环境下,否则MRC下也是很让人怀疑人生的。

鉴于MRC已经逝去了有快10年了吧,因为博主14年接触的iOS,那时很多人还在使用MRC,所以这么说。这里就不再针对MRC来做分析,否则,这篇博客对于读者和作者来说,必将是一场噩梦。

循环引用出现的原因很简单,比方说,对象A创建了对象B,所以对象A拥有了一个指向对象B的强引用,现在,如果对象B有一个指向对象A的强引用,那么对象A的引用计数值就会加到2,任何事物都有结束的时候,程序也不例外,所以当对象A的拥有者不再需要对象A的时候,就会向对象A发送release消息,这样会让对象A的引用计数值减少为1,由于对象A此时的引用计数和对象A创建的对象B的引用计数都为1,所以他们没有被释放掉。这就是一个经典的内存泄漏:程序无法访问到对象A和对象B,但他们仍然占用着内存。

为了解决这个问题,可以使用弱引用。我们首选weak,通过weak来获取对象B对于对象A的引用,由于是弱引用,引用计数不会增加,所以当对象A的拥有者释放它的时候,它的引用计数就会变为0,同时他也会释放对象B。weak的好处不止如此,不仅释放,还可以再被释放的时候主动置nil,避免了野指针的存在。

声明弱引用有两种方式:一是声明变量时使用__weak关键字,另一个是对属性使用weak特性。

另外,由于weak是弱引用,用__weak修饰的变量一定会被注册到autorelease中,否则,创建之后就会随之销毁,为了延长生命周期,必须注册到autorelease中,延缓释放。

7.自动释放池的原理

  • 每⼀次runloop开启时,会创建⾃动释放池,这个我们下面详细讲解其和runloop的关系; 
  • 程序执⾏过程中能够⾃动释放对象,在出了其当前作⽤域之后,会被添加到最近的⾃动释放池; 
  • runloop休眠或结束前,会释放/销毁⾃动释放池。 ⾃动释放池的主要底层数据结构是:__AtAutoreleasePool 和 AutoreleasePoolPage,调⽤了 autorelease的对象最终由AutoreleasePoolPage对象来管理,所有的AutoreleasePoolPage对象通过双向链表的形式连接在⼀起。

AutoreleasePoolPage的数据结构是AutoreleasePoolPageData。每⼀个autoreleasepool对象只有⼀个哨兵,哨兵放在第⼀⻚中,目的是销毁的时候做一个标示位。每⼀个AutoreleasePoolPage对象占⽤4094字节内存,本身成员占⽤56字节,每⼀⻚的前 56个字节存储AutoreleasePoolPage的AutoreleasePoolPageData结构体数据。第⼀⻚的第56往后8个字节存储哨兵,后⾯ 存储autorelease对象,总共可以存储504个。从第⼆⻚开始,每⻚可以存储505个对象。

objc_autoreleasepool的push查找child,没有时创建新的⻚。

objc_autoreleasepool的pop 查找parent,向上查找,释放里面的对象,销毁page,遇到哨兵对象即停⽌。

AutoreleasePoolPage 结构如下:

class AutoreleasePoolPage {

    magic_t const magic;

    id *next;//下一个存放 autorelease 对象的地址

    pthread_t const thread; //AutoreleasePoolPage 所在的线程

    AutoreleasePoolPage * const parent;//父节点

    AutoreleasePoolPage *child;//子节点

    uint32_t const depth;//深度,也可以理解为当前 page 在链表中的位置

    uint32_t hiwat;

}

曾经有人跟我说autorelasePool释放的时候引用计数表也跟着清空操作,我当时还有点懵,现在,从上表来看,autorelasePool和引用计数表是一点关系都没有的,autorelasePool释放的时候 ,随之释放的应该是被注册到autoreleasePool内的对象,第一张表总共可以存储504个,从第⼆⻚开始,每⻚可以存储505个对象。只是从上表中我们无从看到体现。

8.自动释放池什么时候被释放

App启动之后,在主线程的runloop创建之后,系统会在runloop中注册两个observer,其回调为_wrapRunLoopWithAutoreleasePoolHandler()。我们知道,runloop中触发工作的任务有三种,sorce/timer/observer,observer恰在其列。

第一个observer主要负责监听runloop的Enter事件,即即将进入runloop,其回调内调用_objc_autoreleasePoolPush()创建自动释放池,这个上面说自动释放池原理的时候有提到。这个observer优先级最高,保证创建自动释放池发生在其他所有回调之前完成。

第二个observer负责监听两个事件,一个是BerforWaiting,即即将进入休眠,此时调用两个函数,_objc_autoreleasePoolPop()和_objc_autoreleasePoolPush(),先释放旧的池子,再创建新的池子,因为runloop没有退出,app还在运行,自动释放池还会使用,所以不会销毁,只是释放旧池创建新池。另一个监听的是Exit,即将退出runloop,此时调用的是_objc_autoreleasePoolPop(),来释放自动释放池,这个observer优先级最低,保证释放池子发生在其他所有的回调之后。

在主线程中执行的代码多是事件回调,Timer回调,这些事件被runloop创建好的autoreleasePool所环绕,所以才有了ARC的能力,关于自动释放池和内存管理,我们下面会讲到。

9.ARC下引用计数如何存储

从64位开始,对象的引用计数就存放在优化过后的isa指针中,也可能存放在sideTable中。根据哈希算法去查找所在的位置,无需遍历,十分快捷。

SideTables 表在非嵌入式的64位系统中,有64张SideTable 表,每一张SideTable 主要是由三部分组成。自旋锁、引用计数表、 弱引用表。全局的引用计数之所以不存在同一张表中,是为了避免资源竞争,解决效率的问题。

引用计数表中引入了分离锁的概念,将一张表拆成多个部分,对他们分别加锁,可以实现并发操作,提升执行效率。通过指针的地址,查找到引用计数的地址,大大提升查找效率。存储是通过DisguisedPtr (objc_ object) 函数存储, 同时也通过这个函数查找,这样就避免了循环遍历。

10.isa里面都存储了哪些东西

现在的64位系统(arm64架构)中,苹果对isa做了优化,变成了一个共用体( union )结构,还使用位域来存储更多的信息,里面除了存储一个地址外还存储了很多其他信息。一个指针占8个字节,也就是64位,苹果只用了其中的33位来存储地址,其余31位用来存储其他信息。

  • nonpointer: (isa的第0位)表示是否对isa指针开启指针优化。0:纯isa指针,1:优化过的isa。
  • has_ assoc:(isa的第1位)记录这个对象是否是关联对象。
  • has_ cxx_ dtor: (isa的第2位)记录是否有c++的析构函数。
  • shiftcls: (isa的第3- 35位,共占33位)记录对象的地址值。
  • magic: (isa的第36- 41位,共占6位)用于在调试时分辨对象是否完成初始化。
  • weakly_ referenced: (isa的第42位)用于记录该对象是否被弱引用或曾经被弱引用过。 deallocating: (isa的 第43位)标志对象是否正在释放内存。
  • has_ sidetable_ rc: (isa的第44位)用于标记是否有扩展的引用计数。当一个对象的引用计数比较少时,其引用计数就记录在isa中,当引用计数大于某个值时就会采用sideTable来协助存储引用计数。
  • extra_ rc: (isa的第45- 63位,共占19位),用来记录该对象的引用计数值-1。这里总共是19 位,如果引用计数很大,19位存不下的话就会采用sideTable来协助存储。

其结构如下:

union isa_ t
{
    Class cls;
    uintptr_t bits;
    struct {
        uintptr_t nonpointer            : 1;
        uintptr_t has_assoc             : 1;
        uintptr_t has_cxx_dtor          : 1;
        uintptr_t shiftcls              : 33;
        uintptr_t magic                 : 6;
        uintptr_t weakly_referenced     : 1;
        uintptr_t deallocating          : 1;
        uintptr_t has_sidetable         : 1;
        uintptr_t extra_rc              : 9;
    }
}

在这张表里我们看到了很多有意思的东西,包括关联对象,引用计数表。这些东西原来存在于isa中,这时候我就有个疑问了,dealloc的时候都做了些什么呢?

11.Dealloc做了些什么?

执行Dealloc的时候,

1)首先调用_ objc_ rootDealloc()

2)接下来调用rootDealloc()

3)这时候会判断是否可以被释放,判断的依据主要有5个,判断是否有以下五种情况:

  • NONPointer_ISA     
  • weakly_reference
  • has_assoc
  • has_CXX_dtor
  • has_sidetable_rc 

4)如果有以上五中任意种,将会调用object_dispose()方法做下一步的处理 。如果没有之前五种情况的任意一种, 则可以执行C函数的free()。

5)执行完毕。

object_dispose()做了哪些操作呢?

1)直接调用objc_destructlnstance()。

2)调用函数的free()。

objc_destructlnstance()做了哪些操作呢?

1)先判断hasCxxDtor,如果有C++的相关内容,要调用object_cxxDestruct(), 销毁C++相关的内容。

2)再判断hasAssocitatedObjects,也就是是否存在关联对象,如果有的话,要调用object_remove_associations(), 销毁关联对象的一系列操作。

3)然后调用clearDeallocating()。

4)执行完毕。

clearDeallocating()做了什么操作呢?

1)先执行sideTable_clearDellocating()。

2)再执行weak_clear_no_lock,在这一步骤中,会将指向该对象的弱引用指针置为nil。

3)接下来执行table.refcnts.eraser(),从引用计数表中擦除该对象的引用计数。

4)到这里,dealloc的执行就结束了。

我们看到,我们所熟悉的关联对象,弱引用,引用计数表,都是在这里销毁掉的,而这些东西,都是存在于上面讲到的isa中的。

最后,还要说明一下,iOS的内存管理是在编译期就已经确定的,不同于垃圾回收机制,垃圾回收机制是在运行时处理的。所以在iOS的运行时,如果涉及到内存管理的东西,要格外注意了,系统不会帮我们自动管理内存的。

到这里,这篇内存管理的博客就要和大家说再见了,历时三天,查阅大量资料,可能还会有遗漏的重要内容,欢迎大家补充,有问题欢迎评论区留言讨论。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

CodingFire

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值