defer 是干什么用的

很簡(jiǎn)單，用一句話概括，就是 defer block 里的代碼會(huì)在函數(shù) return 之前執(zhí)行，無(wú)論函數(shù)是從哪個(gè)分支 return 的，還是有 throw，還是自然而然走到最后一行。

這個(gè)關(guān)鍵字就跟 Java 里的 try-catch-finally 的finally一樣，不管 try catch 走哪個(gè)分支，它都會(huì)在函數(shù) return 之前執(zhí)行。而且它比 Java 的finally還更強(qiáng)大的一點(diǎn)是，它可以獨(dú)立于 try catch 存在，所以它也可以成為整理函數(shù)流程的一個(gè)小幫手。在函數(shù) return 之前無(wú)論如何都要做的處理，可以放進(jìn)這個(gè) block 里，讓代碼看起來(lái)更干凈一些~

其實(shí)這篇文章的緣起是由于在對(duì) Kingfisher 做重構(gòu)的時(shí)候，因?yàn)樽约簩?duì) defer 的理解不夠準(zhǔn)確，導(dǎo)致了一個(gè) bug。所以想藉由這篇文章探索一下 defer 這個(gè)關(guān)鍵字的一些 edge case。

典型用法

Swift 里的 defer 大家應(yīng)該都很熟悉了，defer 所聲明的 block 會(huì)在當(dāng)前代碼執(zhí)行退出后被調(diào)用。正因?yàn)樗峁┝艘环N延時(shí)調(diào)用的方式，所以一般會(huì)被用來(lái)做資源釋放或者銷毀，這在某個(gè)函數(shù)有多個(gè)返回出口的時(shí)候特別有用。比如下面的通過(guò) FileHandle 打開文件進(jìn)行操作的方法：

func operateOnFile(descriptor: Int32) {
let fileHandle = FileHandle(fileDescriptor: descriptor)

let data = fileHandle.readDataToEndOfFile()

if /* onlyRead */ {
fileHandle.closeFile()
return
}

let shouldWrite = /* 是否需要寫文件 */
guard shouldWrite else {
fileHandle.closeFile()
return
}

fileHandle.seekToEndOfFile()
fileHandle.write(someData)
fileHandle.closeFile()
}

我們?cè)诓煌牡胤蕉夹枰{(diào)用 fileHandle.closeFile() 來(lái)關(guān)閉文件，這里更好的做法是用 defer 來(lái)統(tǒng)一處理。這不僅可以讓我們就近在資源申請(qǐng)的地方就聲明釋放，也減少了未來(lái)添加代碼時(shí)忘記釋放資源的可能性：

func operateOnFile(descriptor: Int32) {
let fileHandle = FileHandle(fileDescriptor: descriptor)
defer { fileHandle.closeFile() }
let data = fileHandle.readDataToEndOfFile()

if /* onlyRead */ { return }

let shouldWrite = /* 是否需要寫文件 */
guard shouldWrite else { return }

fileHandle.seekToEndOfFile()
fileHandle.write(someData)
}

defer 的作用域

在做 Kingfisher 重構(gòu)時(shí)，對(duì)線程安全的保證我選擇使用了 NSLock 來(lái)完成。簡(jiǎn)單說(shuō)，會(huì)有一些類似這樣的方法：

let lock = NSLock()
let tasks: [ID: Task] = [:]

func remove(_ id: ID) {
lock.lock()
defer { lock.unlock() }
tasks[id] = nil
}

對(duì)于 tasks 的操作可能發(fā)生在不同線程中，用 lock() 來(lái)獲取鎖，并保證當(dāng)前線程獨(dú)占，然后在操作完成后使用 unlock() 釋放資源。這是很典型的 defer 的使用方式。

但是后來(lái)出現(xiàn)了一種情況，即調(diào)用 remove 方法之前，我們?cè)谕痪€程的 caller 中獲取過(guò)這個(gè)鎖了，比如：

func doSomethingThenRemove() {
lock.lock()
defer { lock.unlock() }

// 操作 `tasks`
// ...

// 最后，移除 `task`
remove(123)
}

這樣做顯然在 remove 中造成了死鎖 (deadlock)：remove 里的 lock() 在等待 doSomethingThenRemove 中做 unlock() 操作，而這個(gè) unlock 被 remove 阻塞了，永遠(yuǎn)不可能達(dá)到。

解決的方法大概有三種：

1. 換用 NSRecursiveLock：NSRecursiveLock 可以在同一個(gè)線程獲取多次，而不造成死鎖的問(wèn)題。
2. 在調(diào)用 remove 之前先 unlock。
3. 為 remove 傳入按照條件，避免在其中加鎖。

1 和 2 都會(huì)造成額外的性能損失，雖然在一般情況下這樣的加鎖性能微乎其微，但是使用方案 3 似乎也并不很麻煩。于是我很開心地把 remove 改成了這樣：

func remove(_ id: ID, acquireLock: Bool) {
if acquireLock {
lock.lock()
defer { lock.unlock() }
}
tasks[id] = nil
}

很好，現(xiàn)在調(diào)用 remove(123, acquireLock: false) 不再會(huì)死鎖了。但是很快我發(fā)現(xiàn)，在 acquireLock 為 true 的時(shí)候鎖也失效了。再仔細(xì)閱讀 Swift Programming Language 關(guān)于 defer 的描述：

A defer statement is used for executing code just before transferring program control outside of the scope that the defer statement appears in.

所以，上面的代碼其實(shí)相當(dāng)于：

func remove(_ id: ID, acquireLock: Bool) {
if acquireLock {
lock.lock()
lock.unlock()
}
tasks[id] = nil
}

GG 斯密達(dá)…

以前很單純地認(rèn)為 defer 是在函數(shù)退出的時(shí)候調(diào)用，并沒(méi)有注意其實(shí)是當(dāng)前 scope 退出的時(shí)候調(diào)用這個(gè)事實(shí)，造成了這個(gè)錯(cuò)誤。在 if，guard，for，try 這些語(yǔ)句中使用 defer 時(shí)，應(yīng)該要特別注意這一點(diǎn)。

defer 和閉包

另一個(gè)比較有意思的事實(shí)是，雖然 defer 后面跟了一個(gè)閉包，但是它更多地像是一個(gè)語(yǔ)法糖，和我們所熟知的閉包特性不一樣，并不會(huì)持有里面的值。比如：

func foo() {
var number = 1
defer { print("Statement 2: \(number)") }
number = 100
print("Statement 1: \(number)")
}

將會(huì)輸出：

Statement 1: 100
Statement 2: 100

在 defer 中如果要依賴某個(gè)變量值時(shí)，需要自行進(jìn)行復(fù)制：

func foo() {
var number = 1
var closureNumber = number
defer { print("Statement 2: \(closureNumber)") }
number = 100
print("Statement 1: \(number)")
}

// Statement 1: 100
// Statement 2: 1

defer 的執(zhí)行時(shí)機(jī)

defer 的執(zhí)行時(shí)機(jī)緊接在離開作用域之后，但是是在其他語(yǔ)句之前。這個(gè)特性為 defer 帶來(lái)了一些很“微妙”的使用方式。比如從 0 開始的自增：

class Foo {
var num = 0
func foo() -> Int {
defer { num += 1 }
return num
}

// 沒(méi)有 `defer` 的話我們可能要這么寫
// func foo() -> Int {
// num += 1
// return num - 1
// }
}

let f = Foo()
f.foo() // 0
f.foo() // 1
f.num // 2

輸出結(jié)果 foo() 返回了 +1 之前的 num，而 f.num 則是 defer 中經(jīng)過(guò) +1 之后的結(jié)果。不使用 defer 的話，我們其實(shí)很難達(dá)到這種“在返回后進(jìn)行操作”的效果。

雖然很特殊，但是強(qiáng)烈不建議在 defer 中執(zhí)行這類 side effect。

This means that a defer statement can be used, for example, to perform manual resource management such as closing file descriptors, and to perform actions that need to happen even if an error is thrown.

從語(yǔ)言設(shè)計(jì)上來(lái)說(shuō)，defer 的目的就是進(jìn)行資源清理和避免重復(fù)的返回前需要執(zhí)行的代碼，而不是用來(lái)以取巧地實(shí)現(xiàn)某些功能。這樣做只會(huì)讓代碼可讀性降低。

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論