Autorelease机制是iOS开发者管理对象内存的好伙伴，MRC中，调用[obj autorelease]来延迟内存的释放是一件简单自然的事；ARC下，我们甚至可以完全不知道Autorelease就能管理好内存。而在这背后，objc和编译器都帮我们做了哪些事呢，它们是如何协作来正确管理内存的呢？刨根问底，一起来探究下黑幕背后的Autorelease机制吧。
Autorelease对象什么时候释放？
这个问题拿来做面试题，问过很多人，没有几个能答对的。很多答案都是“当前作用域大括号结束时释放”，显然木有正确理解Autorelease机制。
在没有手加Autorelease Pool的情况下，Autorelease对象是在当前的runloop迭代结束时释放的，而它能够释放的原因是系统在每个runloop迭代中都加入了自动释放池Push和Pop。
小实验
1 |
__weak id reference = nil; |
2 |
- (void)viewDidLoad { |
3 |
[super viewDidLoad]; NSString *str = [NSString stringWithFormat:@"sunnyxx"]; // str是一个autorelease对象，设置一个weak的引用来观察它 |
4 |
reference = str; |
5 |
} |
6 |
- (void)viewWillAppear:(BOOL)animated { |
7 |
[super viewWillAppear:animated]; NSLog(@"%@", reference); // Console: sunnyxx} |
8 |
- (void)viewDidAppear:(BOOL)animated { |
9 |
[super viewDidAppear:animated]; NSLog(@"%@", reference); // Console: (null)} |
由于这个vc在loadView之后便add到了window层级上，所以viewDidLoad和viewWillAppear是在同一个runloop调用的，因此在viewWillAppear中，这个autorelease的变量依然有值。
当然，我们也可以手动干预Autorelease对象的释放时机：
1 |
- (void)viewDidLoad |
2 |
{ |
3 |
[super viewDidLoad]; |
4 |
@autoreleasepool { NSString *str = [NSString stringWithFormat:@"sunnyxx"]; |
5 |
} NSLog(@"%@", str); // Console: (null)} |
Autorelease原理
AutoreleasePoolPage
ARC下，我们使用@autoreleasepool{}来使用一个AutoreleasePool，随后编译器将其改写成下面的样子：
1 |
void *context = objc_autoreleasePoolPush();// {}中的代码objc_autoreleasePoolPop(context); |
而这两个函数都是对AutoreleasePoolPage的简单封装，所以自动释放机制的核心就在于这个类。
AutoreleasePoolPage是一个C++实现的类
AutoreleasePool并没有单独的结构，而是由若干个AutoreleasePoolPage以双向链表的形式组合而成（分别对应结构中的parent指针和child指针）。
AutoreleasePool是按线程一一对应的（结构中的thread指针指向当前线程）。
AutoreleasePoolPage每个对象会开辟4096字节内存（也就是虚拟内存一页的大小），除了上面的实例变量所占空间，剩下的空间全部用来储存autorelease对象的地址。
上面的id *next指针作为游标指向栈顶最新add进来的autorelease对象的下一个位置。
一个AutoreleasePoolPage的空间被占满时，会新建一个AutoreleasePoolPage对象，连接链表，后来的autorelease对象在新的page加入。
所以，若当前线程中只有一个AutoreleasePoolPage对象，并记录了很多autorelease对象地址时，内存如下图：
上图中的情况，这一页再加入一个autorelease对象就要满了（也就是next指针马上指向栈顶），这时就要执行上面说的操作，建立下一页page对象，与这一页链表连接完成后，新page的next指针被初始化在栈底（begin的位置），然后继续向栈顶添加新对象。
所以，向一个对象发送- autorelease消息，就是将这个对象加入到当前AutoreleasePoolPage的栈顶next指针指向的位置。
释放时刻
每当进行一次objc_autoreleasePoolPush调用时，runtime向当前的AutoreleasePoolPage中add进一个哨兵对象，值为0（也就是个nil），那么这一个page就变成了下面的样子：
objc_autoreleasePoolPush的返回值正是这个哨兵对象的地址，被objc_autoreleasePoolPop(哨兵对象)作为入参，于是：
1、根据传入的哨兵对象地址找到哨兵对象所处的page。
2、在当前page中，将晚于哨兵对象插入的所有autorelease对象都发送一次- release消息，并向回移动next指针到正确位置。
3、补充2：从最新加入的对象一直向前清理，可以向前跨越若干个page，直到哨兵所在的page，刚才的objc_autoreleasePoolPop执行后，最终变成下面的样子：
嵌套的AutoreleasePool
知道了上面的原理，嵌套的AutoreleasePool就非常简单了，pop的时候总会释放到上次push的位置为止，多层的pool就是多个哨兵对象而已，就像剥洋葱一样，每次一层，互不影响。
【附加内容】
Autorelease返回值的快速释放机制
值得一提的是，ARC下，runtime有一套对autorelease返回值的优化策略。
比如一个工厂方法：
1 |
+ (instancetype)createSark { |
2 |
return [self new]; |
3 |
} |
4 |
// caller |
5 |
Sark *sark = [Sark createSark]; |
秉着谁创建谁释放的原则，返回值需要是一个autorelease对象才能配合调用方正确管理内存，于是乎编译器改写成了形如下面的代码：
1 |
+ (instancetype)createSark { |
2 |
id tmp = [self new]; |
3 |
return objc_autoreleaseReturnValue(tmp); // 代替我们调用autorelease |
4 |
} |
5 |
// caller |
6 |
id tmp = objc_retainAutoreleasedReturnValue([Sark createSark]) // 代替我们调用retain |
7 |
Sark *sark = tmp; |
8 |
objc_storeStrong(&sark, nil); // 相当于代替我们调用了release |
一切看上去都很好，不过既然编译器知道了这么多信息，干嘛还要劳烦autorelease这个开销不小的机制呢？于是乎，runtime使用了一些黑魔法将这个问题解决了...阅读全文>>>