8-14.【内存管理机制】捕获列表如何避免循环引用？为什么捕获顺序有时会影响 ARC？

项阿丑
37 阅读6分钟

1. 捕获列表如何避免循环引用？

捕获列表（Capture List）通过**改变闭包捕获变量的“持有强度”**来打破循环。

循环引用的根源：

默认情况下，闭包对外部引用类型的捕获是强引用（Strong Capture） 。

  • 对象 A 持有 闭包 B。
  • 闭包 B 默认强捕获 对象 A（self）。
  • 结果：引用计数形成闭环，谁都无法降为 0。
捕获列表的干预：

通过在捕获列表中显式声明 [weak self] 或 [unowned self]，你可以告诉编译器：不要增加这个对象的强引用计数。

  • [weak self] ：将捕获的引用变为“弱引用”。它指向对象，但计数不加 1。当对象销毁时，ARC 会通过侧表机制将其自动置为 nil。
  • [unowned self] ：将捕获的引用变为“无主引用”。同样不增加强引用计数，但在底层会维护一个 unowned 计数。它假定对象在闭包执行时一定存在，如果对象已销毁仍去访问，则触发运行时崩溃。

2. 为什么捕获顺序有时会影响 ARC？

在 Swift 中，捕获列表中的声明顺序本身并不直接改变 ARC 的增减逻辑（即谁先 retain 谁后 retain），但它会影响初始化顺序、作用域遮盖以及闭包构造的内存布局。

以下是几个关键原因：

A. 变量遮盖与作用域（Shadowing）

捕获列表中的顺序决定了闭包内部同名变量的指向。

Swift

var x = 10
let closure = { [x] in 
    // 这里的 x 是在闭包定义那一刻拷贝的“常量”
    print(x) 
}
x = 20
closure() // 输出 10

如果在捕获列表中有多个同名或相关联的变量，捕获列表会先于闭包体执行“值拷贝”或“引用转换”。这决定了 ARC 计数在闭包创建时的快照状态。

B. 依赖关系的层降（Dependency Chain）

如果捕获列表涉及多个相互依赖的对象，顺序会影响编译器生成的 init 逻辑。

Swift

[weak self, provider = self.dataProvider]

在这个例子中：

  1. 编译器首先处理 weak self，创建一个弱引用。
  2. 然后处理 provider = self.dataProvider。注意，这里的 self 还是闭包外的强引用（因为捕获列表是并行解析的）。
  3. 如果顺序不当或逻辑错误（例如在 self 还没被捕获前就尝试解构它），可能会导致闭包意外持有某个中间状态的强引用，从而未能如预期般打破循环。
C. 内存对齐与布局（优化层面）

从底层的 HeapContext 来看，捕获列表中的变量顺序决定了它们在堆内存块（Box）中的排列位置。

  • ARC 在执行 swift_release 时，会按照布局顺序依次检查捕获的变量。
  • 虽然这不会改变最终是否释放，但在处理具有复杂 deinit 逻辑的对象图时，销毁的微观顺序可能会影响某些副作用（Side Effects）的触发时机。

3. 捕获顺序的“潜规则”：Lazy 属性与闭包

一个常见的陷阱是在 lazy 属性中使用闭包：

Swift

lazy var someClosure: () -> Void = { [weak self] in
    // 捕获列表在这里非常关键
    self?.doSomething()
}

捕获发生的时机： 捕获列表的动作发生在闭包第一次被访问并初始化时。如果在初始化捕获列表的过程中，self 的状态发生了并发变化，捕获列表的顺序可能决定了编译器选择哪种路径来处理 retain/release。

总结建议

  1. 明确强度：捕获列表中始终先写 weak 或 unowned 变量，确保它们在闭包逻辑开始前就被正确降级。
  2. 值拷贝快照：如果你捕获的是值类型且希望它是“当时的快照”，必须写在捕获列表中；否则，闭包会通过引用捕获一直追踪该变量的最新值。
  3. 避免复杂逻辑：尽量不要在捕获列表中进行复杂的表达式计算（如 [obj = self.child.delegate]），这会使 ARC 的持有链变得难以追踪，建议先在外部用局部变量提取。

英文版

8-14. [Memory Management] How do capture lists avoid retain cycles? Why does capture order sometimes affect ARC?

1. How do capture lists avoid retain cycles?

Capture lists break retain cycles by changing the "holding strength" of variables captured by the closure.

The Root of Retain Cycles:

By default, closures perform a Strong Capture of external reference types.

  • Object A holds Closure B.
  • Closure B, by default, strongly captures Object A (self).
  • Result: The reference counts form a closed loop, and neither can ever drop to 0.
Intervention via Capture Lists:

By explicitly declaring [weak self] or [unowned self] in the capture list, you tell the compiler: Do not increment the strong reference count of this object.

  • [weak self] : Converts the captured reference into a "weak reference." It points to the object but does not increment the count. When the object is deallocated, ARC automatically sets this reference to nil via the Side Table mechanism.
  • [unowned self] : Converts the captured reference into an "unowned reference." It also does not increment the strong count but maintains an unowned count at the underlying level. It assumes the object will always exist when the closure executes; if accessed after the object is destroyed, it triggers a runtime crash.

2. Why does capture order sometimes affect ARC?

In Swift, the declaration order within a capture list doesn't directly change the fundamental ARC logic (i.e., who gets retained first), but it affects initialization order, scope shadowing, and the memory layout of the closure's construction.

Here are the key reasons:

A. Variable Shadowing and Scope

The order in the capture list determines what the variable name refers to inside the closure body.

Swift

var x = 10
let closure = { [x] in 
    // This x is a "constant" copied at the moment the closure was defined
    print(x) 
}
x = 20
closure() // Outputs: 10

If there are multiple variables with the same name or related dependencies, the capture list performs "value copying" or "reference conversion" before the closure body executes. This determines the snapshot state of ARC counts at the moment of closure creation.

B. Dependency Chain Downgrading

If a capture list involves multiple interdependent objects, the order affects the init logic generated by the compiler.

Swift

[weak self, provider = self.dataProvider]

In this example:

  1. The compiler first processes weak self, creating a weak reference.
  2. Then it processes provider = self.dataProvider. Note that self here is still the strong reference from outside the closure (because capture lists are parsed in parallel context).
  3. If logic is misplaced (e.g., trying to deconstruct self before it is properly captured/scoped), it might cause the closure to unexpectedly hold a strong reference to an intermediate state, failing to break the cycle as intended.
C. Memory Alignment and Layout (Optimization Level)

From the perspective of the underlying HeapContext, the order of variables in the capture list determines their arrangement within the heap memory block (Box).

  • When ARC executes swift_release, it inspects captured variables according to their layout order.
  • While this doesn't change whether something is released, the micro-order of destruction in complex object graphs can affect the timing of certain Side Effects triggered during deinitialization.

3. The "Hidden Rule": Lazy Properties and Closures

A common trap occurs when using closures within lazy properties:

Swift

lazy var someClosure: () -> Void = { [weak self] in
    // The capture list is critical here
    self?.doSomething()
}

Timing of Capture: The capture list actions occur when the closure is accessed and initialized for the first time. If the state of self changes concurrently during this initialization, the capture list order can determine which path the compiler takes to handle retain/release.

Summary & Recommendations

  1. Define Strength First: Always list weak or unowned variables first in the capture list to ensure they are properly "downgraded" before closure logic begins.
  2. Value Copy Snapshots: If you capture a value type and want it to be a "snapshot of that moment," you must include it in the capture list; otherwise, the closure will track the latest value of the variable via reference capture.
  3. Avoid Complex Logic: Try not to perform complex expressions within the capture list (e.g., [obj = self.child.delegate]). This makes the ARC holding chain difficult to trace. It is better to extract these into local variables outside the closure first.
avatar
文章
阅读
粉丝