很多iOS開發(fā)者在剛接觸block時(shí)都遇到過一個(gè)問題在block里明明可以讀外部的局部變量但一賦值就報(bào)錯(cuò)提示Variable is not assignable (missing __block type specifier)。報(bào)錯(cuò)信息已經(jīng)告訴你解法了——加上__block修飾符但那時(shí)候大部分人只是機(jī)械地加上并不知道這背后發(fā)生了什么。我在早期也是這樣直到后來因?yàn)橐粋€(gè)block的循環(huán)引用問題排查了兩天才痛下決心把__block變量的內(nèi)存布局研究明白。這篇文章就把這些底層的知識(shí)整理出來。它不是一個(gè)API使用手冊(cè)而是一份從編譯器視角、從內(nèi)存布局視角重新看待__block變量的指南。讀完你可以清楚地回答__block變量到底存在哪里為什么加上__block就能改值block從棧拷貝到堆的時(shí)候__block變量經(jīng)歷了什么以及ARC下__block變量的循環(huán)引用問題到底怎么回事。這篇文章適合所有正在使用Objective-C的開發(fā)者尤其是對(duì)block的理解還停留在會(huì)寫、會(huì)用層面、遇到內(nèi)存問題卻說不出原因的人。讀完我相信你會(huì)對(duì)block和__block有完全不同的認(rèn)識(shí)。1. 從block里為什么改不了外部變量說起——捕獲機(jī)制的真相1.1 block捕獲普通局部變量時(shí)做了什么先回到最基礎(chǔ)的問題為什么不加__block就改不了外部局部變量很多人只知道結(jié)論但不清楚根因。我用一個(gè)最簡(jiǎn)單的例子說明int a 10; void (^block)(void) ^{ // 這里可以讀a但不能寫a NSLog(%d, a); }; block();在C語(yǔ)言層面block本質(zhì)上是一個(gè)結(jié)構(gòu)體編譯器會(huì)把這個(gè)block改寫成一個(gè)類似這樣的結(jié)構(gòu)struct __block_impl { void *isa; int flags; int reserved; void *FuncPtr; }; struct __main_block_impl_0 { struct __block_impl impl; struct __main_block_desc_0 *Desc; int a; // 捕獲進(jìn)來的變量注意是值拷貝 };也就是說當(dāng)block捕獲一個(gè)普通局部變量a時(shí)它不是去持有a的引用而是把這個(gè)變量的值復(fù)制了一份作為block結(jié)構(gòu)體的一個(gè)成員變量。你可以理解為block只是給這個(gè)值拍了一張照片照片放在block自己的結(jié)構(gòu)體里。之后你在block內(nèi)部讀取a讀的其實(shí)是block結(jié)構(gòu)體里的那個(gè)成員不是外部棧上那個(gè)a。所以在block內(nèi)部給a賦值就相當(dāng)于嘗試修改block結(jié)構(gòu)體里那個(gè)被拷貝的成員而這個(gè)成員在編譯時(shí)是作為const拷貝進(jìn)來的編譯器直接就不允許你這樣做。1.2 不同變量的捕獲規(guī)則差異這個(gè)捕獲規(guī)則不是對(duì)所有變量都一樣的這點(diǎn)很多人容易混淆。我整理一下變量類型block內(nèi)部能否修改捕獲方式普通局部變量否值拷貝block持有副本static局部變量是指針拷貝block持有變量地址全局變量是直接訪問不需要捕獲__block局部變量是通過特殊結(jié)構(gòu)體間接訪問static局部變量之所以可以修改是因?yàn)榫幾g器改成傳遞這個(gè)變量的指針地址block內(nèi)部通過指針去操作原始變量。全局變量更簡(jiǎn)單全局區(qū)地址固定block內(nèi)部直接按符號(hào)訪問。那__block呢它走的是另一條完全不同的路——編譯器不是把a(bǔ)的值拷貝進(jìn)block結(jié)構(gòu)體而是創(chuàng)建一個(gè)額外的結(jié)構(gòu)體對(duì)象來包裝這個(gè)變量然后再把結(jié)構(gòu)體指針傳給block。這條路就是本文的核心。2. 編譯器眼里的__block變量__Block_byref結(jié)構(gòu)體逐字段拆解2.1 用clang -rewrite-objc偷看底層想真正搞清楚__block的內(nèi)存布局最直觀的方式是讓編譯器把Objective-C代碼改寫為C代碼看看它到底生成了什么。先準(zhǔn)備這樣一段代碼int main() { __block int a 10; void (^block)(void) ^{ a 20; NSLog(%d, a); }; block(); return 0; }然后在終端執(zhí)行clang -rewrite-objc main.m會(huì)生成一個(gè)main.cpp文件。核心內(nèi)容在這里我做了一些精簡(jiǎn)和整理// 這是編譯器為 __block int a 生成的結(jié)構(gòu)體 struct __Block_byref_a_0 { void *__isa; __Block_byref_a_0 *__forwarding; int __flags; int __size; int a; // 原始變量 }; // block的結(jié)構(gòu)體 struct __main_block_impl_0 { struct __block_impl impl; struct __main_block_desc_0 *Desc; __Block_byref_a_0 *a; // 指向上面結(jié)構(gòu)體的指針 };看到這張結(jié)構(gòu)圖很多事情就清楚了帶__block的變量a并沒有被直接拷進(jìn)block而是生成一個(gè)__Block_byref_a_0結(jié)構(gòu)體block結(jié)構(gòu)體里只是保存了這個(gè)結(jié)構(gòu)體的指針。2.2 四個(gè)字段各司其職__Block_byref_a_0結(jié)構(gòu)體里每個(gè)字段都有自己的職責(zé)我逐個(gè)拆開講__isa這個(gè)字段在Objective-C對(duì)象里本來是指向類對(duì)象的指針在__block變量結(jié)構(gòu)體里它通常為0或者指向NULL。這個(gè)字段的存在是為了讓結(jié)構(gòu)體在布局上和Objective-C對(duì)象兼容但實(shí)際使用中我們不依賴它。__forwarding這個(gè)是最關(guān)鍵的字段指向真正存儲(chǔ)變量的結(jié)構(gòu)體。為什么需要一個(gè)額外的跳轉(zhuǎn)后面我專門用一節(jié)來講這里先記住它是用來解決block從?？截惖蕉阎笞兞繗w屬問題的。__flags標(biāo)志位用來標(biāo)記這個(gè)變量有沒有被拷貝到堆上以及變量是不是對(duì)象類型等信息。具體位含義在不同平臺(tái)略有差異一般情況下我們不需要手動(dòng)操作它。__size結(jié)構(gòu)體大小。這個(gè)字段非常重要因?yàn)閎lock在拷貝或釋放時(shí)需要知道__Block_byref結(jié)構(gòu)體到底占多少字節(jié)才能正確執(zhí)行內(nèi)存操作。a這才是真正的原始變量。我們的__block int a在內(nèi)存里的本體就是結(jié)構(gòu)體里的這個(gè)字段。block在訪問a的時(shí)候不是直接訪問而是會(huì)走一段類似這樣的代碼// block內(nèi)部對(duì)a的賦值會(huì)被改寫成 (a-__forwarding-a) 20;也就是說通過block持有的__Block_byref_a_0 *a指針先找到__forwarding再通過__forwarding找到真正的變量。前面提到的拍照比喻在這里不適用了更準(zhǔn)確的理解是block拿著一個(gè)地址通過這個(gè)地址去訪問一個(gè)間接層再通過間接層里記錄的指針找到真正的變量的位置。2.3 descriptor里的拷貝與銷毀函數(shù)如果你繼續(xù)往下看重寫生成的代碼還會(huì)發(fā)現(xiàn)一個(gè)__main_block_desc_0結(jié)構(gòu)體里面除了常規(guī)的reserved和size字段之外多了兩個(gè)函數(shù)指針struct __main_block_desc_0 { size_t reserved; size_t Block_size; void (*copy)(struct __main_block_impl_0 *, struct __main_block_impl_0 *); void (*dispose)(struct __main_block_impl_0 *); };這兩個(gè)函數(shù)指針是干什么的當(dāng)一個(gè)block從棧上被拷貝到堆上時(shí)copy函數(shù)會(huì)被調(diào)用它的職責(zé)是如果block捕獲了__block變量、對(duì)象變量或其他需要特殊內(nèi)存管理的變量就要把這些變量也做相應(yīng)的拷貝或引用計(jì)數(shù)調(diào)整。dispose函數(shù)則在block從堆上釋放時(shí)被調(diào)用負(fù)責(zé)釋放相關(guān)資源。這里要特別說明如果__block變量只是一個(gè)int、float這樣的普通數(shù)據(jù)類型copy和dispose函數(shù)可能是個(gè)空的實(shí)現(xiàn)或者非常簡(jiǎn)單的邏輯但如果__block變量持有了Objective-C對(duì)象那么copy函數(shù)就要負(fù)責(zé)把對(duì)象正確retaindispose函數(shù)負(fù)責(zé)release。所以不要小看這兩個(gè)函數(shù)指針?biāo)鼈兪茿RC內(nèi)存管理在block生命周期里的關(guān)鍵入口。3. __forwarding指針棧與堆之間的導(dǎo)航員3.1 為什么要拐一道彎__forwarding的設(shè)計(jì)在整個(gè)__block內(nèi)存布局里是最精妙的地方也最不容易理解。我當(dāng)年第一次看到這個(gè)字段時(shí)也是一頭霧水搞不懂為什么明明直接持有一個(gè)變量還要搞一個(gè)中間指針繞來繞去。答案在于block和__block變量最初都誕生在棧上它們的生命周期本來只屬于當(dāng)前函數(shù)作用域。但是block經(jīng)常需要被存儲(chǔ)到堆上或者被傳遞到其他地方使用比如作為一個(gè)屬性被持有、被異步操作引用。這時(shí)候block會(huì)被從?？截惖蕉选栴}是__block變量該怎么辦如果__block變量留在棧上而block去了堆上那么block訪問__block變量時(shí)就可能訪問到已經(jīng)被銷毀的?？臻g。如果直接把__block變量也一并拷貝到堆上那么原來代碼里訪問棧上的a的地方和block里訪問堆上的a的地方就變成了兩個(gè)不同的變量——這顯然不符合__block的語(yǔ)義因?yàn)開_block存在的意義就是讓block內(nèi)外共享同一個(gè)變量。__forwarding就是把這個(gè)矛盾解決掉的機(jī)制。3.2 從?？截惖蕉褧r(shí)發(fā)生了什么我畫一個(gè)完整的過程描述幫助你建立畫面感。第一步代碼運(yùn)行在棧上創(chuàng)建__Block_byref_a_0結(jié)構(gòu)體棧上的結(jié)構(gòu)體的__forwarding指向自己。此時(shí)block也在棧上block結(jié)構(gòu)體里保存指向這個(gè)結(jié)構(gòu)體的指針。第二步block被拷貝到堆上?？截惖挠|發(fā)時(shí)機(jī)可能是手動(dòng)執(zhí)行[block copy]在ARC下把block賦值給一個(gè)strong屬性或變量block作為參數(shù)傳入某些會(huì)copy它的APIblock被放入NSArray、NSDictionary等容器拷貝發(fā)生時(shí)copy函數(shù)不僅會(huì)把block結(jié)構(gòu)體本身從棧復(fù)制到堆也會(huì)把__Block_byref_a_0結(jié)構(gòu)體從棧復(fù)制到堆。關(guān)鍵來了在拷貝完成后棧上的__Block_byref_a_0的__forwarding指針會(huì)被更新指向堆上的那個(gè)新拷貝的結(jié)構(gòu)體。也就是說整個(gè)流程下來?xiàng)Ｉ系慕Y(jié)構(gòu)體變成了一個(gè)代理它的__forwarding指向堆上的真實(shí)結(jié)構(gòu)體。而堆上的結(jié)構(gòu)體的__forwarding指向自己。之后不管是從block內(nèi)部訪問還是從外部原始代碼位置訪問表達(dá)式最終都通過__forwarding-a來定位變量所以訪問到的都是堆上那一份這就保證了共享語(yǔ)義。我用一個(gè)代碼片段來模擬這個(gè)過程的核心變化__block int a 0; // 棧上結(jié)構(gòu)體 S 創(chuàng)建S-__forwarding S void (^block)(void) ^{ a; // 實(shí)際是 (a-__forwarding-a) }; // 這里block被拷貝假設(shè)拷貝到堆上的結(jié)構(gòu)體為 H // 拷貝完成后S-__forwarding HH-__forwarding H // 此時(shí)從任何路徑訪問 a都會(huì)訪問到 H-a如果沒有__forwarding這層跳轉(zhuǎn)當(dāng)block被拷貝到堆上時(shí)你很難保證外部引用和block內(nèi)部引用指向同一個(gè)變量。棧上的結(jié)構(gòu)體不能動(dòng)了因?yàn)槠渌a可能還在用它的地址直接改block里的指針也只能影響block自己的訪問路徑。__forwarding的存在讓所有路徑都?xì)w一化到通過__forwarding找到真正存儲(chǔ)位置這個(gè)統(tǒng)一的訪問方式上問題就迎刃而解了。3.3 沒有__forwarding會(huì)怎樣這里做一個(gè)假設(shè)推演如果沒有__forwardingblock被拷貝到堆上后堆上的block和棧上的__block變量結(jié)構(gòu)體就會(huì)脫節(jié)。如果函數(shù)返回棧上結(jié)構(gòu)體被銷毀堆上的block訪問到一個(gè)懸空的指針輕則值錯(cuò)亂重則崩潰。即便你非常小心地保證在函數(shù)返回前一定使用完block但block一旦被拷貝到堆上就脫離了函數(shù)的生命周期控制你根本沒法保證它什么時(shí)候會(huì)被執(zhí)行。所以__forwarding不是可選的優(yōu)化而是保證block和__block內(nèi)存安全的基本機(jī)制。4. 堆上的內(nèi)存布局與生命周期驗(yàn)證4.1 用代碼實(shí)測(cè)各階段變量地址理論講再多不如跑一段代碼來驗(yàn)證。我寫了一個(gè)小例子在不同階段打印變量的地址你可以直接跑一下親眼看內(nèi)存地址怎么變。#import Foundation/Foundation.h void testBlockVariableAddress() { __block int a 0; int *stackA a; NSLog(1. block執(zhí)行前a的地址: %p, stackA); void (^block)(void) ^{ int *innerA a; NSLog(2. block內(nèi)部a的地址: %p, innerA); a; NSLog(3. 修改后的a值: %d, a); }; block(); // 此時(shí)block還在棧上block內(nèi)部地址和外部應(yīng)該一致 void (^heapBlock)(void) [block copy]; // 拷貝到堆上 NSLog(4. 拷貝后外部a的地址: %p, a); heapBlock(); }從實(shí)際執(zhí)行結(jié)果來看前三個(gè)日志打印的地址通常是一致的或者至少通過__forwarding訪問到的都是同一個(gè)結(jié)構(gòu)體。第4步打印的地址在block從前沒有被使用過、現(xiàn)在被拷貝到堆上的場(chǎng)景里外部a訪問到的是棧結(jié)構(gòu)體但棧結(jié)構(gòu)體的__forwarding指向堆上的結(jié)構(gòu)體所以值仍然是共享的。如果你在block內(nèi)部打印a經(jīng)過__forwarding跳轉(zhuǎn)后它指向的就是堆上結(jié)構(gòu)體里的變量地址。這個(gè)地址的變化過程其實(shí)就證明了前面說的__forwarding跳轉(zhuǎn)機(jī)制。4.2 block copy前后內(nèi)存布局對(duì)比我用一張文字化的表格來展示copy前后內(nèi)存布局的變化階段棧上堆上訪問結(jié)果copy前存在block結(jié)構(gòu)體和__Block_byref結(jié)構(gòu)體__forwarding指向自身無訪問棧上結(jié)構(gòu)體變量copy后block結(jié)構(gòu)體可能還在__Block_byref結(jié)構(gòu)體的__forwarding指向堆上存在block結(jié)構(gòu)體和__Block_byref結(jié)構(gòu)體__forwarding指向自身訪問堆上結(jié)構(gòu)體變量棧結(jié)構(gòu)體銷毀后已不存在仍存在通過棧上殘留指針或block內(nèi)部指針經(jīng)__forwarding訪問堆上變量這里有一個(gè)非常重要的點(diǎn)block被拷貝到堆上時(shí)它捕獲的對(duì)象類型變量和__block變量的所有權(quán)處理是不完全一樣的。普通對(duì)象變量被捕獲時(shí)如果block被拷貝對(duì)象會(huì)被retain而__block變量結(jié)構(gòu)體被拷貝時(shí)取決于結(jié)構(gòu)體內(nèi)部變量的類型如果是對(duì)象也會(huì)被retain如果是普通類型則只是值拷貝。4.3 __block變量的釋放時(shí)機(jī)__block變量結(jié)構(gòu)體跟隨block的生命周期。block在堆上時(shí)__block變量結(jié)構(gòu)體也在堆上block被釋放時(shí)相關(guān)聯(lián)的__block變量結(jié)構(gòu)體也會(huì)被釋放。也就是說__block變量的生命周期從跟隨棧幀變成了跟隨block。這是理解循環(huán)引用的基礎(chǔ)。如果多個(gè)block同時(shí)捕獲同一個(gè)__block變量每個(gè)block拷貝時(shí)都會(huì)重新拷貝一份__Block_byref結(jié)構(gòu)體嗎答案是否定的。系統(tǒng)會(huì)盡量復(fù)用已經(jīng)存在的堆上結(jié)構(gòu)體通過引用計(jì)數(shù)來管理。這一點(diǎn)在多個(gè)block共享同一個(gè)__block變量的場(chǎng)景里特別重要不要假設(shè)每個(gè)block都有自己獨(dú)立的__Block_byref結(jié)構(gòu)體。5. 內(nèi)存管理中的連環(huán)坑與規(guī)避方案5.1 ARC下__block對(duì)象變量的循環(huán)引用問題這是很多開發(fā)者會(huì)踩的坑也是最容易搞混的地方。在ARC下__block修飾一個(gè)對(duì)象類型變量時(shí)當(dāng)block從?？截惖蕉裚_Block_byref結(jié)構(gòu)體里的對(duì)象指針會(huì)被強(qiáng)引用。也就是說只要堆上的block還存在這個(gè)對(duì)象就不會(huì)被釋放?？紤]這樣一個(gè)場(chǎng)景typedef void (^MyBlock)(void); implementation MyObject - (void)setupBlock { __block MyObject *weakSelf self; // 注意這里用__block而不是__weak MyBlock block ^{ NSLog(%, weakSelf); }; // 如果block被長(zhǎng)期持有 self.block block; }這里的問題是self持有blockblock持有的__Block_byref結(jié)構(gòu)體里強(qiáng)引用了weakSelf而weakSelf指向的就是self本身。這形成了一個(gè)完整的循環(huán)引用鏈導(dǎo)致self無法被釋放。很多人在這個(gè)場(chǎng)景里誤以為__block就是用來打破循環(huán)引用的這其實(shí)是把__block和__weak搞混了。正確的做法是__weak MyObject *weakSelf self; // 真正的打破循環(huán)引用的方式 MyBlock block ^{ NSLog(%, weakSelf); }; self.block block;__weak不會(huì)retain對(duì)象block持有的只是對(duì)象的弱引用不參與引用計(jì)數(shù)循環(huán)引用自然就斷開了。5.2 __block與__weak/__strong的真實(shí)關(guān)系我還見過一些人把__block和__weak、__strong放在一起比較問哪個(gè)更好。這其實(shí)是兩個(gè)完全不同維度的修飾符。__block是存儲(chǔ)類型修飾符核心作用是改變變量被block捕獲時(shí)的存儲(chǔ)方式讓變量可以在block內(nèi)部被修改。__weak和__strong是所有權(quán)修飾符核心作用是控制對(duì)象的引用計(jì)數(shù)。一個(gè)變量可以同時(shí)使用__block和__weak嗎可以。比如__block __weak MyObject *obj self;這種情況下obj這個(gè)變量本身存儲(chǔ)在__Block_byref結(jié)構(gòu)體里但結(jié)構(gòu)體里對(duì)obj的引用是弱引用不會(huì)影響對(duì)象的釋放。實(shí)際開發(fā)中這種寫法偶爾會(huì)出現(xiàn)在需要在block內(nèi)把弱引用重新賦值給某個(gè)臨時(shí)變量、又希望在block執(zhí)行期間對(duì)對(duì)象的生命周期做精細(xì)控制的場(chǎng)景。不過大多數(shù)情況下__weak block內(nèi)部轉(zhuǎn)成__strong的寫法已經(jīng)足夠了。5.3 嵌套block中的__block變量傳遞嵌套block是另一個(gè)容易出問題的地方。當(dāng)一個(gè)__block變量被外層block捕獲然后外層block內(nèi)部又創(chuàng)建了一個(gè)新的內(nèi)層block內(nèi)層block也捕獲了這個(gè)變量這時(shí)候內(nèi)存布局會(huì)怎么變化我遇到過這種場(chǎng)景外層block被拷貝到堆上然后內(nèi)層block也可能被拷貝。如果內(nèi)層block又被單獨(dú)拷貝了一份__Block_byref結(jié)構(gòu)體那整個(gè)共享關(guān)系是不是就被破壞了答案是不會(huì)。因?yàn)開_forwarding機(jī)制保證了所有路徑最終都指向堆上的同一個(gè)結(jié)構(gòu)體。內(nèi)層block捕獲的不再是棧上那個(gè)__Block_byref結(jié)構(gòu)體的地址而是通過外層block訪問到的堆上結(jié)構(gòu)體的地址。所以只要理解了__forwarding是全局唯一的訪問入口嵌套block的問題就迎刃而解了。不過嵌套block場(chǎng)景下還有一個(gè)需要注意的點(diǎn)如果你在block內(nèi)部對(duì)__block變量做修改而這個(gè)block在異步執(zhí)行另外一段代碼也在同時(shí)修改同一個(gè)變量就會(huì)產(chǎn)生數(shù)據(jù)競(jìng)爭(zhēng)。__block不提供任何線程安全機(jī)制它只是一個(gè)存儲(chǔ)和共享的解決方案。多線程環(huán)境下使用__block變量需要自己加鎖或者使用原子操作否則會(huì)有數(shù)據(jù)競(jìng)爭(zhēng)和未定義行為。5.4 block被多次copy時(shí)的行為還有一個(gè)容易忽略的行為對(duì)同一個(gè)block多次執(zhí)行copy操作并不會(huì)每次都重新生成一份新的__Block_byref結(jié)構(gòu)體。系統(tǒng)內(nèi)部會(huì)通過引用計(jì)數(shù)來管理堆上的block結(jié)構(gòu)多次copy只是增加引用計(jì)數(shù)不會(huì)導(dǎo)致__block變量結(jié)構(gòu)體被復(fù)制多份。這解決了一個(gè)潛在的性能問題也避免了一個(gè)邏輯問題如果每次copy都復(fù)制一份__Block_byref結(jié)構(gòu)體那么不同block copy之間就變成了不同的變量徹底違背了__block的共享語(yǔ)義。6. 實(shí)戰(zhàn)經(jīng)驗(yàn)總結(jié)與調(diào)試技巧6.1 用lldb查看__block變量真實(shí)地址在Xcode里斷點(diǎn)調(diào)試時(shí)直接在lldb里打印a有時(shí)候看到的是__Block_byref結(jié)構(gòu)體的地址你會(huì)覺得它和外面代碼打印的a不一樣這是因?yàn)榫幾g器在斷點(diǎn)環(huán)境下可能會(huì)對(duì)訪問做了一些優(yōu)化或者重寫。需要留意的是你在lldb里看到的是一個(gè)中間結(jié)構(gòu)體的地址真正的業(yè)務(wù)變量是通過__forwarding跳轉(zhuǎn)之后才能訪問到的對(duì)象。如果要在lldb里手動(dòng)查看__block變量的底層結(jié)構(gòu)可以這樣做(lldb) frame variable -L這個(gè)命令會(huì)輸出當(dāng)前棧幀里所有變量的內(nèi)存地址包括編譯器的重寫情況。如果你的代碼里有__block int a你可能會(huì)看到類似這樣的輸出0x00007ffeefbff958: (__block int) a 20地址前綴是0x7ffe開頭的就是棧地址0x6000開頭的是堆地址。當(dāng)你看到a的地址從棧變成堆就說明block被拷貝了__block結(jié)構(gòu)體也跟著去了堆上。6.2 從崩潰日志里識(shí)別__block野指針如果你在處理block相關(guān)的崩潰時(shí)崩潰棧里出現(xiàn)__Block_byref相關(guān)的符號(hào)或者EXC_BAD_ACCESS時(shí)地址指向一個(gè)棧地址就要高度懷疑是不是block被釋放了但還有地方在訪問。一個(gè)常見場(chǎng)景是這樣的block被某個(gè)對(duì)象持有但持有對(duì)象已經(jīng)被釋放了block本身也已經(jīng)被釋放了然后某個(gè)定時(shí)器或者異步回調(diào)還在調(diào)用這個(gè)block的指針。這時(shí)候如果block里捕獲了__block變量訪問__forwarding-a就會(huì)讀到已經(jīng)被回收的內(nèi)存產(chǎn)生野指針。排查這類問題的時(shí)候建議優(yōu)先檢查block被持有的鏈條block被誰持有持有的對(duì)象生命周期是不是覆蓋到了block的調(diào)用時(shí)機(jī)block捕獲的__block變量是否被多個(gè)對(duì)象共享如果共享釋放順序是什么樣的把這三條鏈路理清楚了block相關(guān)崩潰的排查就完成了一大半。6.3 從工程角度如何優(yōu)雅使用__block雖然__block機(jī)制很強(qiáng)大但我的實(shí)際經(jīng)驗(yàn)是盡量少用。__block在大多數(shù)場(chǎng)景里的真實(shí)需求是在block內(nèi)部修改外部變量但這種需求往往可以通過設(shè)計(jì)來規(guī)避。比如把需要修改的狀態(tài)封裝成一個(gè)可變對(duì)象block內(nèi)部只修改對(duì)象的屬性就不再需要__block修飾屬性本身了。又比如用局部變量在block前面處理完邏輯再把結(jié)果傳遞給block需要用的參數(shù)。這樣做的優(yōu)點(diǎn)是后續(xù)的內(nèi)存管理邏輯更簡(jiǎn)單可讀性更高。當(dāng)然在需要真正共享狀態(tài)的場(chǎng)景下__block是繞不開的。比如一個(gè)網(wǎng)絡(luò)請(qǐng)求返回的數(shù)據(jù)需要在多次回調(diào)里累加到同一個(gè)變量里比如一個(gè)計(jì)數(shù)器需要被多個(gè)block共享用__block就是最自然的寫法。這時(shí)候只要把生命周期和循環(huán)引用這兩個(gè)問題處理干凈用__block完全沒問題。6.4 我踩過的最后一個(gè)坑分享一個(gè)我自己犯過的錯(cuò)誤。有一段時(shí)間我在寫一個(gè)音頻處理工具用__block來保存中間數(shù)據(jù)指針然后在一個(gè)異步block里訪問。當(dāng)時(shí)想當(dāng)然地認(rèn)為block會(huì)被拷貝到堆上所以__block變量也會(huì)在堆上應(yīng)該是安全的。結(jié)果忽略了block底層是存儲(chǔ)在一個(gè)局部變量里的在ARC下block從棧拷貝到堆的時(shí)機(jī)并不總是立即發(fā)生的。在某些場(chǎng)景下block仍然停留在棧上而棧上空間在函數(shù)返回后就失效了異步再去訪問就出現(xiàn)了玄學(xué)崩潰。從那以后我養(yǎng)成了一個(gè)習(xí)慣凡是block可能被異步調(diào)用的我一定顯式地調(diào)用一次copy或者通過強(qiáng)引用屬性讓ARC幫我們處理確保block和__block結(jié)構(gòu)體都穩(wěn)定地在堆上。這些經(jīng)驗(yàn)分享出來是想提醒你__block不僅僅是加一個(gè)修飾符那么簡(jiǎn)單它背后是一套完整的內(nèi)存管理和共享機(jī)制。理解了它的設(shè)計(jì)原理再遇到block相關(guān)的內(nèi)存問題會(huì)從容得多。