OC底层内存管理剖析III：lock的实战剖析

2023-10-01 02:26:49

揭秘多线程中的死锁谜团：一把锁引发的悲剧

在并发编程的世界里，多线程是一种常见的技术，它允许我们同时执行多个任务，从而提高应用程序的性能和响应能力。然而，当多线程处理共享资源时，如果没有妥善管理，就会出现死锁的风险。本文将带你深入探索多线程死锁的成因、后果和规避策略，避免应用程序陷入死胡同。

死锁的成因：线程的无休止等待

死锁是一个程序中的一种状态，其中多个线程都在等待彼此持有的资源才能继续执行。通常，死锁发生在两个或多个线程试图同时获取同一把锁时。

想象一下这样一个场景：线程 A 获取了锁 A，而线程 B 获取了锁 B。此时，线程 A 需要锁 B 才能继续执行，而线程 B 需要锁 A 才能继续执行。由于两把锁都被占用，两个线程都陷入了无限循环的等待中，无法取得进展。这就是死锁的本质：线程相互等待，形成一个无法打破的循环。

实战剖析：一个危险的疏忽

为了更深入地理解死锁，让我们分析一个真实的示例：

- (void)start {
  [self.lock lock];
  if (!self.isRunning) {
    self.isRunning = true;
    [NSThread detachNewThreadWithTarget:self selector:@selector(run) object:nil];
  }
  [self.lock unlock];
}

在这个代码示例中，问题潜伏在 [self.lock unlock] 这行代码中。假设 self.isRunning 在调用这行代码之前恰好变为 NO，就会出现死锁。

死锁的原因在于：当线程 A 调用 start 方法时，它获取了 self.lock 锁，并标记 self.isRunning 为 true。然后，它启动了一个后台线程来调用 run 方法。

后台线程持续处理任务，直到它完成所有任务并标记 self.isRunning 回 NO。同时，主线程调用了 stop 方法，意图停止队列。stop 方法需要获取 self.lock 锁，但由于后台线程持有该锁，它将被阻塞等待。

此时，后台线程完成了所有任务并释放了 self.lock 锁，但主线程仍然被阻塞在 stop 方法中，等待获取 self.lock 锁。由于后台线程已经释放了 self.lock 锁，线程 A 无法继续执行，而后台线程也无法继续执行，因为主线程持有了它需要的锁。这样，两个线程就陷入了一个循环等待的死锁中。