天天看點
傳回

黑幕背後的Autorelease

原文：http://www.cocoachina.com/ios/20141031/10107.html

Autorelease機制是iOS開發者管理對象記憶體的好夥伴，MRC中，調用[obj autorelease]來延遲記憶體的釋放是一件簡單自然的事，ARC下，我們甚至可以完全不知道Autorelease就能管理好記憶體。而在這背後，objc和編譯器都幫我們做了哪些事呢，它們是如何協作來正确管理記憶體的呢？刨根問底，一起來探究下黑幕背後的Autorelease機制。

Autorelease對象什麼時候釋放？

這個問題拿來做面試題，問過很多人，沒有幾個能答對的。很多答案都是“目前作用域大括号結束時釋放”，顯然木有正确了解Autorelease機制。

在沒有手加Autorelease Pool的情況下，Autorelease對象是在目前的runloop疊代結束時釋放的，而它能夠釋放的原因是系統在每個runloop疊代中都加入了自動釋放池Push和Pop

小實驗

1 2 3 4 5 6 7 8 9

__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)}

由于這個vc在loadView之後便add到了window層級上，是以viewDidLoad和viewWillAppear是在同一個runloop調用的，是以在viewWillAppear中，這個autorelease的變量依然有值。

當然，我們也可以手動幹預Autorelease對象的釋放時機：

1 2 3 4 5

- (void)viewDidLoad

{

[

super

viewDidLoad];

@autoreleasepool {        NSString *str = [NSString stringWithFormat:@

"sunnyxx"

];

}    NSLog(@

"%@"

, str); 

// Console: (null)}

Autorelease原理

AutoreleasePoolPage

ARC下，我們使用@autoreleasepool{}來使用一個AutoreleasePool，随後編譯器将其改寫成下面的樣子：

1

void *context = objc_autoreleasePoolPush();

// {}中的代碼objc_autoreleasePoolPop(context);

而這兩個函數都是對AutoreleasePoolPage的簡單封裝，是以自動釋放機制的核心就在于這個類。

AutoreleasePoolPage是一個C++實作的類

黑幕背後的Autorelease
  • AutoreleasePool并沒有單獨的結構，而是由若幹個AutoreleasePoolPage以雙向連結清單的形式組合而成（分别對應結構中的parent指針和child指針）。
  • AutoreleasePool是按線程一一對應的（結構中的thread指針指向目前線程）。
  • AutoreleasePoolPage每個對象會開辟4096位元組記憶體（也就是虛拟記憶體一頁的大小），除了上面的執行個體變量所占空間，剩下的空間全部用來儲存autorelease對象的位址。
  • 上面的id *next指針作為遊标指向棧頂最新add進來的autorelease對象的下一個位置。
  • 一個AutoreleasePoolPage的空間被占滿時，會建立一個AutoreleasePoolPage對象，連接配接連結清單，後來的autorelease對象在新的page加入。

是以，若目前線程中隻有一個AutoreleasePoolPage對象，并記錄了很多autorelease對象位址時記憶體如下圖：

黑幕背後的Autorelease

圖中的情況，這一頁再加入一個autorelease對象就要滿了（也就是next指針馬上指向棧頂），這時就要執行上面說的操作，建立下一頁page對象，與這一頁連結清單連接配接完成後，新page的next指針被初始化在棧底（begin的位置），然後繼續向棧頂添加新對象。

是以，向一個對象發送- autorelease消息，就是将這個對象加入到目前AutoreleasePoolPage的棧頂next指針指向的位置

釋放時刻

每當進行一次objc_autoreleasePoolPush調用時，runtime向目前的AutoreleasePoolPage中add進一個哨兵對象，值為0（也就是個nil），那麼這一個page就變成了下面的樣子：

黑幕背後的Autorelease

objc_autoreleasePoolPush的傳回值正是這個哨兵對象的位址，被objc_autoreleasePoolPop(哨兵對象)作為入參，于是：

1.根據傳入的哨兵對象位址找到哨兵對象所處的page

2.在目前page中，将晚于哨兵對象插入的所有autorelease對象都發送一次- release消息，并向回移動next指針到正确位置

3.補充2：從最新加入的對象一直向前清理，可以向前跨越若幹個page，直到哨兵所在的page

剛才的objc_autoreleasePoolPop執行後，最終變成了下面的樣子：

黑幕背後的Autorelease

嵌套的AutoreleasePool

知道了上面的原理，嵌套的AutoreleasePool就非常簡單了，pop的時候總會釋放到上次push的位置為止，多層的pool就是多個哨兵對象而已，就像剝洋蔥一樣，每次一層，互不影響。

【附加内容】

Autorelease傳回值的快速釋放機制

值得一提的是，ARC下，runtime有一套對autorelease傳回值的優化政策。

比如一個工廠方法：

     
  1.  + (instancetype)createSark {        
    2.       
  2.      return [self new];         
    3.       
  3.  }        
    4.       
  4.  // caller        
    5.       
  5.  Sark *sark = [Sark createSark];        
    6.

秉着誰建立誰釋放的原則，傳回值需要是一個autorelease對象才能配合調用方正确管理記憶體，于是乎編譯器改寫成了形如下面的代碼：

     
  1.  + (instancetype)createSark {        
    2.       
  2.      id tmp = [self new];        
    3.       
  3.      return objc_autoreleaseReturnValue(tmp); // 代替我們調用autorelease        
    4.       
  4.  }        
    5.       
  5.  // caller        
    6.       
  6.  id tmp = objc_retainAutoreleasedReturnValue([Sark createSark]) // 代替我們調用retain        
    7.       
  7.  Sark *sark = tmp;        
    8.       
  8.  objc_storeStrong(&sark, nil); // 相當于代替我們調用了release        
    9.

一切看上去都很好，不過既然編譯器知道了這麼多資訊，幹嘛還要勞煩autorelease這個開銷不小的機制呢？于是乎，runtime使用了一些黑魔法将這個問題解決了。

黑魔法之Thread Local Storage

Thread Local Storage（TLS）線程局部存儲，目的很簡單，将一塊記憶體作為某個線程專有的存儲，以key-value的形式進行讀寫，比如在非arm架構下，使用pthread提供的方法實作：

     
  1.  void* pthread_getspecific(pthread_key_t);        
    2.       
  2.  int pthread_setspecific(pthread_key_t , const void *);        
    3.

說它是黑魔法可能被懂pthread的笑話- -

在傳回值身上調用objc_autoreleaseReturnValue方法時，runtime将這個傳回值object儲存在TLS中，然後直接傳回這個object（不調用autorelease）；同時，在外部接收這個傳回值的objc_retainAutoreleasedReturnValue裡，發現TLS中正好存了這個對象，那麼直接傳回這個object（不調用retain）。

于是乎，調用方和被調方利用TLS做中轉，很有默契的免去了對傳回值的記憶體管理。

于是問題又來了，假如被調方和主調方隻有一邊是ARC環境編譯的該咋辦？（比如我們在ARC環境下用了非ARC編譯的第三方庫，或者反之）

隻能動用更進階的黑魔法。

黑魔法之__builtin_return_address

這個内建函數原型是char *__builtin_return_address(int level)，作用是得到函數的傳回位址，參數表示層數，如__builtin_return_address(0)表示目前函數體傳回位址，傳1是調用這個函數的外層函數的傳回值位址，以此類推。

     
  1.  - (int)foo {        
    2.       
  2.      NSLog(@"%p", __builtin_return_address(0)); // 根據這個位址能找到下面ret的位址        
    3.       
  3.      return 1;        
    4.       
  4.  }        
    5.       
  5.  // caller        
    6.       
  6.  int ret = [sark foo];        
    7.

看上去也沒啥厲害的，不過要知道，函數的傳回值位址，也就對應着調用者結束這次調用的位址（或者相差某個固定的偏移量，根據編譯器決定）

也就是說，被調用的函數也有翻身做地主的機會了，可以反過來對主調方幹點壞事。

回到上面的問題，如果一個函數傳回前知道調用方是ARC還是非ARC，就有機會對于不同情況做不同的處理

黑魔法之反查彙編指令

通過上面的__builtin_return_address加某些偏移量，被調方可以定位到主調方在傳回值後面的彙編指令：

     
  1.  // caller         
    2.       
  2.  int ret = [sark foo];        
    3.       
  3.  // 記憶體中接下來的彙編指令（x86，我不懂彙編，瞎寫的）        
    4.       
  4.  movq ??? ???        
    5.       
  5.  callq ???        
    6.

而這些彙編指令在記憶體中的值是固定的，比如movq對應着0x48。

于是乎，就有了下面的這個函數，入參是調用方__builtin_return_address傳入值

     
  1.  static bool callerAcceptsFastAutorelease(const void * const ra0) {        
    2.       
  2.      const uint8_t *ra1 = (const uint8_t *)ra0;        
    3.       
  3.      const uint16_t *ra2;        
    4.       
  4.      const uint32_t *ra4 = (const uint32_t *)ra1;        
    5.       
  5.      const void **sym;        
    6.       
  6.      // 48 89 c7    movq  %rax,%rdi        
    7.       
  7.      // e8          callq symbol        
    8.       
  8.      if (*ra4 != 0xe8c78948) {        
    9.       
  9.          return false;        
    10.       
  10.      }        
    11.       
  11.      ra1 += (long)*(const int32_t *)(ra1 + 4) + 8l;        
    12.       
  12.      ra2 = (const uint16_t *)ra1;        
    13.       
  13.      // ff 25       jmpq *[email protected](%rip)        
    14.       
  14.      if (*ra2 != 0x25ff) {        
    15.       
  15.          return false;        
    16.       
  16.      }        
    17.       
  17.      ra1 += 6l + (long)*(const int32_t *)(ra1 + 2);        
    18.       
  18.      sym = (const void **)ra1;        
    19.       
  19.      if (*sym != objc_retainAutoreleasedReturnValue)        
    20.       
  20.      {        
    21.       
  21.          return false;        
    22.       
  22.      }        
    23.       
  23.      return true;        
    24.       
  24.  }        
    25.

它檢驗了主調方在傳回值之後是否緊接着調用了objc_retainAutoreleasedReturnValue，如果是，就知道了外部是ARC環境，反之就走沒被優化的老邏輯。

其他Autorelease相關知識點

使用容器的block版本的枚舉器時，内部會自動添加一個AutoreleasePool：

     
  1.  [array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {        
    2.       
  2.      // 這裡被一個局部@autoreleasepool包圍着        
    3.       
  3.  }];        
    4.

當然，在普通for循環和for in循環中沒有，是以，還是新版的block版本枚舉器更加友善。for循環中周遊産生大量autorelease變量時，就需要手加局部AutoreleasePool咯。

iOS 記憶體管理 autorelease
上一篇: 曆經數年努力，中國晶片終于奪下了晶片産能第一名，成功逆襲美日
下一篇: 【BUG記錄】Data source rejected establishment of connection, message from server: “Too many connections“

繼續閱讀