问题的答案

问题的历史

在 Swift 引入 自动引用计数 (ARC) 之前，开发人员通过手动管理内存，使用 retain、release 和 autorelease 调用，导致频繁的内存泄漏或悬空指针。Swift 的 ARC 在编译时自动插入保留/释放调用，但它在闭包方面引入了一种细微的复杂性，闭包是捕获周围变量的引用类型。这在 Swift 中产生了一类新的特定内存问题，其中两个引用类型可能形成不可销毁的循环依赖，从而需要引入捕获列表语法以提供对这些捕获语义的明确控制。

问题

当一个类实例将一个闭包存储为属性，并且该闭包引用 self 或其他实例属性时，ARC 会增加实例的引用计数，以使其在闭包的生命周期内保持活着。由于闭包本身被实例强引用，因此会形成保留循环：实例强引用闭包，而闭包又强引用实例。没有一个引用计数达到零，导致 deinit 永远无法执行，并造成应用程序生命周期内的内存泄漏。

解决方案

Swift 提供了捕获列表——方括号内以逗号分隔的表达式，位于闭包参数列表之前——以修改默认的捕获行为。指定 [weak self] 创建一个弱引用（可选，释放时成为 nil），而 [unowned self] 创建一个非拥有的引用（假设存在，释放后访问会崩溃）。对于值，[x = x] 捕获当前值而不是引用。这明确打破了强引用循环，允许 ARC 在删除外部引用时释放该实例。

代码示例：

class DataManager {
    var completionHandler: ((Data) -> Void)?
    var data: Data = Data()
    
    func fetchData() {
        // 保留循环：self 持有闭包，闭包持有 self
        completionHandler = { newData in
            self.data = newData // 对 self 的强捕获
        }
    }
    
    func fetchDataFixed() {
        // 解决方案：弱捕获
        completionHandler = { [weak self] newData in
            guard let self = self else { return }
            self.data = newData
        }
    }
    
    deinit {
        print("DataManager 被释放")
    }
}

生活中的情况

在一个生产 iOS 应用中，我们实现了一个 ProfileViewController，依赖 UserService 类异步获取个人资料数据。该服务使用闭包作为完成处理程序的 API，存储为属性以支持可取消的请求。我们观察到，从个人资料屏幕导航时从未触发 ViewController 的 deinit，并且 Instruments 报告有一个持久的内存图对象图保持视图层次结构。

我们考虑了几种架构方法来解决这个泄漏问题。

我们尝试在 viewWillDisappear 中显式将完成处理程序设置为 nil。虽然这在用户导航回来的时候技术上打破了循环，但对于突然终止或意外状态转换，它证明是不可靠的。如果闭包从未被调用，并且在消失事件之前系统在内存压力下释放了视图控制器，这也会导致泄漏。这种方法需要过度的防御性编程，并违反了单一职责原则，迫使视图控制器管理服务的内部状态。

我们评估了在闭包中使用 [unowned self] 以避免可选解包的开销。这提供了语法上的简洁性和零成本抽象的好处。然而，在测试期间，我们发现了竞争条件，快速导航可能在网络请求仍在进行时释放 ViewController，导致在回调尝试访问已释放实例时崩溃。在生产环境中出现未定义行为的风险超过了性能优势。

我们在闭包的入口点实现了 [weak self]，并结合了 guard let self = self else { return } 检查。这安全地处理了所有生命周期场景：如果在回调触发之前视图控制器被释放，弱引用变为 nil，guard 失败无声，ARC 随后清除闭包。虽然这需要稍多的样板代码，并引入了一小部分可选处理开销，但保证了内存安全和无崩溃操作。

我们在代码库中普遍采用了弱捕获方法。在将 UserService 集成重构为使用 [weak self] 后，内存图调试确认 ProfileViewController 实例在关闭时立即被释放。Xcode 的内存图调试器显示没有来自闭包的剩余强引用，并且 Instruments 的泄漏检测报告特性中没有泄漏。这种模式成为我们所有基于闭包的异步 API 的标准。

候选人经常错过的内容

在闭包中捕获结构实例与捕获类实例有何不同，为什么结构无法创建保留循环？

许多候选人错误地认为，在闭包中捕获 self 总是存在保留循环的风险，无论上下文如何。结构是 Swift 中的值类型，这意味着它们是复制而不是引用。当一个结构被闭包捕获时，ARC 将结构的值复制到闭包的捕获列表中（或根据优化捕获对不可变副本的引用），但重要的是，结构没有引用计数。因为闭包持有的是值，而不是指向堆分配对象的指针，所以闭包和原始结构实例之间不存在循环引用的可能性。

风险仅存在于 self 指向类（引用类型）时，在这种情况下，闭包存储一个指向堆对象的指针，从而增加其引用计数。理解这种区别对于决定在处理 SwiftUI 视图结构与 UIKit 视图控制器时是否应用捕获列表修饰符至关重要。

[weak self] 和 [unowned self] 在对象生命周期假设方面的精确定义为何，什么情况下 [unowned self] 会导致崩溃？

候选人通常将这两者视为可互换。[weak self] 将捕获转换为可选的 WeakReference，当对象被释放时，ARC 会自动将其设置为 nil。访问它需要可选绑定，即使对象死去也很安全。而 [unowned self] 创建一个非拥有引用，假设对象在闭包的整个生命周期内将存在；它的行为类似于一个从不设置为 nil 的隐式解包可选值。

如果闭包的生命周期超出了对象（例如，存储的完成处理程序在控制器弹出后被调用），访问 self 解引用了一个悬空指针，导致 EXC_BAD_ACCESS 崩溃。仅在闭包和对象具有相同生命周期时使用 [unowned self]，例如在非逃逸闭包或特定委托模式下，闭包不能超出捕获者的生命周期。

捕获列表如何与闭包作用域外声明的变量交互，以及 [x] 对于值类型是创建副本还是引用？

一个常见的误解是捕获列表仅影响 self。当你写 { [x] in ... } 时，你明确捕获了闭包创建时 x 的当前值，有效地创建了一个在闭包内不可变的影子副本。如果没有捕获列表，闭包会捕获对原始变量存储位置的引用，允许它查看闭包创建后所做的修改，并可能参与循环逻辑，如果 x 是引用类型的话。

对于值类型，例如 Int 或 String，[x] 捕获一个副本，防止闭包观察到外部对 x 的变化，并确保闭包的行为是基于捕获时状态的确定性。这种区别在闭包超出其定义范围，并在原始上下文发生变化后异步执行时变得至关重要。

在什么具体的引用计数条件下，将闭包分配给实例属性会生成保留循环，以及捕获列表如何改变 ARC 语义以解决此问题？

问题的答案

问题的历史

问题

解决方案

生活中的情况

候选人经常错过的内容