Sign in Subscribe
性能

使用 Xcode 调试工具分析死锁(Deadlock)

了解如何使用 Xcode 的 Debug 工具分析导致应用运行时死锁的原因。

廖林

• 6 min read
使用 Xcode 调试工具分析死锁(Deadlock)

什么是死锁

死锁是指两个或多个线程无限期地互相等待。这种情况就像循环依赖，每个线程都在等待另一个线程释放所需的资源。在 Swift 中，一个串行队列同步操作会触发同一队列上的另一个同步操作，这就是造成锁的常见原因。

如何检测死锁

1. 重现问题

在 Xcode 中运行你的应用，执行可能会导致死锁的操作，直到应用出现卡顿或无响应的情况。

2. 暂停所有线程

应用卡住后，打开 Xcode 的调试工具。在调试栏中点击 Pause 按钮。这会暂停所有线程，从而允许你检查当前线程的状态和调用栈。

3. 查看线程状态

打开 Debug Navigator（调试导航器），切换到 Threads 视图。通过观察线程状态，找出哪些线程处于等待状态。

分析 Debug Navigator

分析主线程堆栈

在调试器的线程列表中，每个线程都显示一个唯一的 Thread 号（如 Thread 1、Thread 3 等），它们代表应用在运行时（也就是死锁状态）的不同线程。

  • Thread 1 通常是主线程（Main Thread），负责处理应用的 UI 和大部分主逻辑。几乎所有与界面相关的更新都需要在此线程上运行。
  • 在调试死锁或线程问题时，分析顺序通常从 主线程（Thread 1）开始，然后逐步检查其他线程。

从上面截图中，我们可以看到主线程（Thread 1）在等待某种资源 (__psynch_mutexwait)。这是一个常见的信号，表明线程正在尝试获取锁，但未能成功，因为其他线程正在占用该资源。

主线程的堆栈信息分析：

  • __psynch_mutexwait：表示主线程正在等待互斥锁释放。
  • static MONOApp.$main() 和 main：主线程正在执行应用的主要代码。
  • start_sim 和 dispatch_async：这些表明某些任务被异步分配到其他线程，但未完成或阻塞。

从主线程调用栈的上下文来看，调用了 MONOApp.$main() 后，通过异步任务 (dispatch_async) 与其他线程（例如 Thread 3）产生关联。

分析其他线程堆栈

“Thread 3 Queue: RPAC issue generation workloop”

这一行表明，这是一个 RPAC issue generation workloop —— RPAC 线程通常用于处理异步任务，所以 Thread3 是一个异步任务。

“Enqueued from com.apple.main-thread (Thread 1)”

这一行明确指出， Thread 3 是在 dispatch_async 中被派发到后台执行，而调用 dispatch_async 的上下文来自 主线程 (Thread 1)。栈帧中包含 dispatch_async，这是一个典型的异步任务派发方法。

详细堆栈分析

  1. 120 start → 系统初始化的入口点。
  2. 118 main 和 117 static MONOApp.$main():
  • 表示应用从 main 函数启动，并进入 MONOApp 的主线程运行。这是你的 SwiftUI 应用的入口点。
  1. 19 ChatRowView.body.getter:
  • 表示 SwiftUI 的视图 ChatRowView 在刷新 body 时，触发了 getter。SwiftUI 的 body 是一个动态计算的属性，每次视图刷新或绑定的状态发生变化时都会重新计算。
  1. 17-11 closure #1:
  • 多个嵌套闭包，说明 ChatRowView.body 的实现中可能有复杂逻辑，或是依赖了某些绑定数据，这些绑定数据触发了进一步的计算。
  • 闭包调用表明 body 中的某些部分依赖外部数据源（如 ChatMessage 模型）。
  1. 10 ChatMessage.timestamp.getter:
  • 在 ChatRowView.body 的刷新中，访问了 ChatMessage 的 timestamp 属性。
  • 这是关键一步，因为 timestamp 属性的访问触发了后台数据的加载。
  1. 9 SwiftData.PersistentModel.getValue<T>:
  • 调用了 SwiftData 框架的 getValue 方法，试图通过键值路径 (forKey) 获取数据。
  • SwiftData 的实现会检查数据是否需要加载（例如从磁盘或数据库读取），并尝试解码成可用的 Swift 模型。
  1. 0 dispatch_async:
  • 表示当前线程是通过 dispatch_async 从主线程派发到后台队列中执行的。

Thread 3 的调用堆栈分析（堆栈调用从下往上读）：

  1. 问题起源于 SwiftUI 视图刷新周期中（ChatRowView.body.getter）
  2. 在视图渲染过程中，触发了对 ChatMessage.timestamp 属性的访问
  3. 这个访问触发了 SwiftData 的 getValue 操作的调用

死锁原因分析

通过主线程和线程 3 的调用堆栈，可以推测死锁的可能原因：

  1. SwiftUI 视图刷新周期问题

视图刷新时，主线程访问了 ChatMessage.timestamp 属性。

  1. 数据加载阻塞

访问的属性触发了 SwiftData 的数据加载逻辑，而该加载逻辑在后台线程中执行。

. 循环等待形成死锁

  • 主线程正在等待后台线程加载数据。
  • 后台线程被阻塞，无法完成数据加载，因为它需要主线程释放资源。

最终形成了一个典型的循环等待，导致死锁。