黑幕背后的Autorelease
st123456
9年前
<h2>我是前言</h2> <p>Autorelease机制是iOS开发者管理对象内存的好伙伴，MRC中，调用<code>[obj autorelease]</code>来延迟内存的释放是一件简单自然的事，ARC下，我们甚至可以完全不知道Autorelease就能管理好内存。而在这背后，objc和编译器都帮我们做了哪些事呢，它们是如何协作来正确管理内存的呢？刨根问底，一起来探究下黑幕背后的Autorelease机制。</p> <p>Autorelease对象什么时候释放？</p> <p>这个问题拿来做面试题，问过很多人，没有几个能答对的。很多答案都是“当前作用域大括号结束时释放”，显然木有正确理解Autorelease机制。<br> 在没有手加Autorelease Pool的情况下，Autorelease对象是在当前的<code>runloop</code>迭代结束时释放的，而它能够释放的原因是<strong>系统在每个runloop迭代中都加入了自动释放池Push和Pop</strong></p> <h2>小实验</h2> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">__weak id reference = nil; - (void)viewDidLoad { [super viewDidLoad]; NSString *str = [NSString stringWithFormat:@"sunnyxx"]; // str是一个autorelease对象，设置一个weak的引用来观察它 reference = str; } - (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; NSLog(@"%@", reference); // Console: sunnyxx } - (void)viewDidAppear:(BOOL)animated { [super viewDidAppear:animated]; NSLog(@"%@", reference); // Console: (null) } </code></pre> </td> </tr> </tbody> </table> <p>这个实验同时也证明了<code>viewDidLoad</code>和<code>viewWillAppear</code>是在同一个runloop调用的，而<code>viewDidAppear</code>是在之后的某个runloop调用的。<br> 由于这个vc在loadView之后便add到了window层级上，所以<code>viewDidLoad</code>和<code>viewWillAppear</code>是在同一个runloop调用的，因此在<code>viewWillAppear</code>中，这个autorelease的变量依然有值。</p> <p>当然，我们也可以手动干预Autorelease对象的释放时机：</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">- (void)viewDidLoad { [super viewDidLoad]; @autoreleasepool { NSString *str = [NSString stringWithFormat:@"sunnyxx"]; } NSLog(@"%@", str); // Console: (null) } </code></pre> </td> </tr> </tbody> </table> <p>Autorelease原理</p> <h2>AutoreleasePoolPage</h2> <p>ARC下，我们使用<code>@autoreleasepool{}</code>来使用一个AutoreleasePool，随后编译器将其改写成下面的样子：</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">void *context = objc_autoreleasePoolPush(); // {}中的代码 objc_autoreleasePoolPop(context); </code></pre> </td> </tr> </tbody> </table> <p>而这两个函数都是对<code>AutoreleasePoolPage</code>的简单封装，所以自动释放机制的核心就在于这个类。</p> <p>AutoreleasePoolPage是一个C++实现的类</p> <p><img alt="黑幕背后的Autorelease" src="https://simg.open-open.com/show/4a8675e144fc0be058b0dc1ab13f4e49.jpg" width="541" height="346"></p> <ul> <li>AutoreleasePool并没有单独的结构，而是由若干个AutoreleasePoolPage以<code>双向链表</code>的形式组合而成（分别对应结构中的parent指针和child指针）</li> <li>AutoreleasePool是按线程一一对应的（结构中的thread指针指向当前线程）</li> <li>AutoreleasePoolPage每个对象会开辟4096字节内存（也就是虚拟内存一页的大小），除了上面的实例变量所占空间，剩下的空间全部用来储存autorelease对象的地址</li> <li>上面的<code>id *next</code>指针作为游标指向栈顶最新add进来的autorelease对象的下一个位置</li> <li>一个AutoreleasePoolPage的空间被占满时，会新建一个AutoreleasePoolPage对象，连接链表，后来的autorelease对象在新的page加入</li> </ul> <p>所以，若当前线程中只有一个AutoreleasePoolPage对象，并记录了很多autorelease对象地址时内存如下图：</p> <p><img alt="黑幕背后的Autorelease" src="https://simg.open-open.com/show/77b3a70f18b12b650e48ff008a42921f.jpg" width="502" height="465"></p> <p>图中的情况，这一页再加入一个autorelease对象就要满了（也就是next指针马上指向栈顶），这时就要执行上面说的操作，建立下一页page对象，与这一页链表连接完成后，新page的<code>next</code>指针被初始化在栈底（begin的位置），然后继续向栈顶添加新对象。</p> <p><strong>所以，向一个对象发送<code>- autorelease</code>消息，就是将这个对象加入到当前AutoreleasePoolPage的栈顶next指针指向的位置</strong></p> <h2>释放时刻</h2> <p>每当进行一次<code>objc_autoreleasePoolPush</code>调用时，runtime向当前的AutoreleasePoolPage中add进一个<code>哨兵对象</code>，值为0（也就是个nil），那么这一个page就变成了下面的样子：</p> <p><img alt="黑幕背后的Autorelease" src="https://simg.open-open.com/show/f0f14bd693da3b0692f36f9426cfae3d.jpg" width="702" height="482"></p> <p><code>objc_autoreleasePoolPush</code>的返回值正是这个哨兵对象的地址，被<code>objc_autoreleasePoolPop(哨兵对象)</code>作为入参，于是：</p> <ol> <li>根据传入的哨兵对象地址找到哨兵对象所处的page</li> <li>在当前page中，将晚于哨兵对象插入的所有autorelease对象都发送一次<code>- release</code>消息，并向回移动<code>next</code>指针到正确位置</li> <li>补充2：从最新加入的对象一直向前清理，可以向前跨越若干个page，直到哨兵所在的page</li> </ol> <p>刚才的objc_autoreleasePoolPop执行后，最终变成了下面的样子：</p> <p><img alt="黑幕背后的Autorelease" src="https://simg.open-open.com/show/2b1b8ee1df4728f6c078d9b290aa2d43.jpg" width="503" height="422"></p> <h2>嵌套的AutoreleasePool</h2> <p>知道了上面的原理，嵌套的AutoreleasePool就非常简单了，pop的时候总会释放到上次push的位置为止，多层的pool就是多个哨兵对象而已，就像剥洋葱一样，每次一层，互不影响。</p> <p>【附加内容】</p> <p>Autorelease返回值的快速释放机制</p> <p>值得一提的是，ARC下，runtime有一套对autorelease返回值的优化策略。<br> 比如一个工厂方法：</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">+ (instancetype)createSark { return [self new]; } // caller Sark *sark = [Sark createSark]; </code></pre> </td> </tr> </tbody> </table> <p>秉着谁创建谁释放的原则，返回值需要是一个autorelease对象才能配合调用方正确管理内存，于是乎编译器改写成了形如下面的代码：</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">+ (instancetype)createSark { id tmp = [self new]; return objc_autoreleaseReturnValue(tmp); // 代替我们调用autorelease } // caller id tmp = objc_retainAutoreleasedReturnValue([Sark createSark]) // 代替我们调用retain Sark *sark = tmp; objc_storeStrong(&sark, nil); // 相当于代替我们调用了release </code></pre> </td> </tr> </tbody> </table> <p>一切看上去都很好，不过既然编译器知道了这么多信息，干嘛还要劳烦autorelease这个开销不小的机制呢？于是乎，runtime使用了一些黑魔法将这个问题解决了。</p> <h2>黑魔法之Thread Local Storage</h2> <p>Thread Local Storage（TLS）线程局部存储，目的很简单，将一块内存作为某个线程专有的存储，以key-value的形式进行读写，比如在非arm架构下，使用pthread提供的方法实现：</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">void* pthread_getspecific(pthread_key_t); int pthread_setspecific(pthread_key_t , const void *); </code></pre> </td> </tr> </tbody> </table> <p>说它是黑魔法可能被懂pthread的笑话- -</p> <p>在返回值身上调用<code>objc_autoreleaseReturnValue</code>方法时，runtime将这个返回值object储存在TLS中，然后直接返回这个object（不调用autorelease）；同时，在外部接收这个返回值的<code>objc_retainAutoreleasedReturnValue</code>里，发现TLS中正好存了这个对象，那么直接返回这个object（不调用retain）。<br> 于是乎，调用方和被调方利用TLS做中转，很有默契的免去了对返回值的内存管理。</p> <p>于是问题又来了，假如被调方和主调方只有一边是ARC环境编译的该咋办？（比如我们在ARC环境下用了非ARC编译的第三方库，或者反之）<br> 只能动用更高级的黑魔法。</p> <h2>黑魔法之__builtin_return_address</h2> <p>这个内建函数原型是<code>char *__builtin_return_address(int level)</code>，作用是得到函数的返回地址，参数表示层数，如__builtin_return_address(0)表示当前函数体返回地址，传1是调用这个函数的外层函数的返回值地址，以此类推。</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">- (int)foo { NSLog(@"%p", __builtin_return_address(0)); // 根据这个地址能找到下面ret的地址 return 1; } // caller int ret = [sark foo]; </code></pre> </td> </tr> </tbody> </table> <p>看上去也没啥厉害的，不过要知道，函数的返回值地址，也就对应着调用者结束这次调用的地址（或者相差某个固定的偏移量，根据编译器决定）<br> 也就是说，被调用的函数也有翻身做地主的机会了，可以反过来对主调方干点坏事。<br> 回到上面的问题，<strong>如果一个函数返回前知道调用方是ARC还是非ARC，就有机会对于不同情况做不同的处理</strong></p> <h2>黑魔法之反查汇编指令</h2> <p>通过上面的__builtin_return_address加某些偏移量，被调方可以定位到主调方在返回值后面的<code>汇编指令</code>：</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">// caller int ret = [sark foo]; // 内存中接下来的汇编指令（x86，我不懂汇编，瞎写的） movq ??? ??? callq ??? </code></pre> </td> </tr> </tbody> </table> <p>而这些汇编指令在内存中的值是固定的，比如movq对应着0x48。<br> 于是乎，就有了下面的这个函数，入参是调用方__builtin_return_address传入值</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">static bool callerAcceptsFastAutorelease(const void * const ra0) { const uint8_t *ra1 = (const uint8_t *)ra0; const uint16_t *ra2; const uint32_t *ra4 = (const uint32_t *)ra1; const void **sym; // 48 89 c7 movq %rax,%rdi // e8 callq symbol if (*ra4 != 0xe8c78948) { return false; } ra1 += (long)*(const int32_t *)(ra1 + 4) + 8l; ra2 = (const uint16_t *)ra1; // ff 25 jmpq *symbol@DYLDMAGIC(%rip) if (*ra2 != 0x25ff) { return false; } ra1 += 6l + (long)*(const int32_t *)(ra1 + 2); sym = (const void **)ra1; if (*sym != objc_retainAutoreleasedReturnValue) { return false; } return true; } </code></pre> </td> </tr> </tbody> </table> <p>它检验了主调方在返回值之后是否紧接着调用了<code>objc_retainAutoreleasedReturnValue</code>，如果是，就知道了外部是ARC环境，反之就走没被优化的老逻辑。</p> <p>其他Autorelease相关知识点</p> <p>使用容器的block版本的枚举器时，内部会自动添加一个AutoreleasePool：</p> <table> <tbody> <tr> <td> <pre> <code class="language-objectivec">[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) { // 这里被一个局部@autoreleasepool包围着 }]; </code></pre> </td> </tr> </tbody> </table> <p>当然，在普通for循环和for in循环中没有，所以，还是新版的block版本枚举器更加方便。for循环中遍历产生大量autorelease变量时，就需要手加局部AutoreleasePool咯。</p> <p>via:http://blog.sunnyxx.com/2014/10/15/behind-autorelease/</p>