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

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

我简单说下这些规则：

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

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

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

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

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

#import <UIKit/UIKit.h&gt;
#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 函数中的自动释放池块。

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

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

通过@auto releasepool 关键字
通过NSAuto releasePo ol对象

在我们一直使用的Foundati on库工具中，创建和销毁自动释放池已经由@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

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

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启动之后，在主线程的run loop创建之后，系统会在run loop中注册两个 observer，其回调为_wrapRunLoopWithAutoreleasePoolHandler()。我们知道，run loop中触发工作的任务有三种，sorce/timer/observer，observer恰在其列。

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

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

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

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

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

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

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

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

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

non pointer: (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_ reference d: (isa的第42位)用于记录该对象是否被弱引用或曾经被弱引用过。 de allocating: (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;
    }
}