开发笔记:Swift并发编程的10大陷阱

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Swift并发编程的10大陷阱相关的知识，希望对你有一定的参考价值。

在使用 Swift 进行并发编程时，操作系统提供了一些底层的基本操作。例如，苹果为此提供了框架或其他东西，比如已经在 Javascript 中广泛使用的 promise。这篇文章将对 Swift 的并发编程做更加全面的介绍，并告诉大家，如果不了解并发，有可能会犯下哪些错误。

Swift 中的原子性与数据库中的事务具有相同的概念，即一次性写入一个值被视为一个操作。在将应用程序编译为 32 位时，如果没有使用原子性，并在代码中使用了 int64_t，那么可能会出现相当奇怪的行为。为什么？让我们来详细了解下：

int64_t x = 0
Thread1:
x = 0xFFFF
Thread2:
x = 0xEEDD

第一个线程开始往 x 写入值，但由于应用程序需要运行在 32 位操作系统上，我们必须将要写入 x 的值分成两批 0xFF。

当 Thread2 尝试同时写入 x 时，可能会按以下顺序执行：

Thread1: part1
Thread2: part1
Thread2: part2
Thread1: part2

最后我们会得到：

x == 0xEEFF

既不是 0xFFFF 也不是 0xEEDD。

如果使用原子性，我们就创建了一个单独的事务，于是就变成：

Thread1: part1
Thread1: part2
Thread2: part1
Thread2: part2

结果，x 包含 Thread2 设置的值。Swift 本身没有提供原子性实现，不过已经有建议要在 Swift 中添加原子性，但目前，你必须自己实现它。

最近，我修复了一个 bug，这个 bug 是由两个不同线程同时向一个数组写入引起的。如果同一组中的两个操作可以并行运行并且同时失败，会发生什么？它们将尝试同时向错误数组写入，这将导致 Swift.Array 的“allocate capacity”错误。要修复这个问题，数组必须是线程安全的，可以使用同步数组。

一般情况下，在每次写入时必须进行加锁。

但需要注意的是，读取也可能失败：

var messages: [Message] = []
func dispatch(_ message: Message) {
 messages.append(message)
 dispatchToPlugins()
}
func dispatchToPlugins() {
 while messages.count > 0 {
   for plugin in plugins {
     plugin.dispatch(message: messages[0])
   }
   messages.remove(at:0)
 }
}
Thread1:
dispatch(message1)
Thread2:
dispatch(message2)

我们循环遍历一个数组，只要数组长度不为 0，就将数组中的元素分派给插件，然后从数组中移除。这种方式非常容易导致“index out of range”异常。

现在的 CPU 有多个内核，并包含了智能编译器，我们无法预测代码会运行在哪个内核上。硬件甚至会优化我们的内存操作。簿记（bookkeeping）可确保它们在同一个内核上是按照一定的顺序执行的。遗憾的是，这仍然可能导致一个内核会看到不同顺序的内存变更。看看这个简单的例子：

//Processor #1:
while f == 0 {
 print x
}
//Processor #2:
x = 42
f = 1

你可能希望这段代码会打印出 42，因为 x 是在 f 被设置为 false 之前赋值的。不过有时可能发生这种情况，即第二个 CPU 以相反的顺序看到内存的变更，因此会先结束循环，打印 x 的值，然后才看到新值 42。

我还没有在 ios 上看到过这种情况，但这并不意味着它不会发生。特别随着 CPU 内核数量越来越多，对这种底层硬件陷阱的认识至关重要。

那么该如何解决这个问题？Apple 为此提供了内存屏障。它们是一组命令，用于确保在执行下一个内存操作之前完成当前的操作。这将阻止 CPU 优化我们的代码，导致执行时间变慢一些。但你没有必要太注意这点性能差异，除非你是在构建高性能的系统。

内存屏障使用起来很简单，但要注意，它是一个操作系统函数，不属于 Swift。因此 API 是使用 C 语言实现的。

OSMemoryBarrier() // from

在上面的代码中使用内存屏障：

//Processor #1:
while f == 0 {
 OSMemoryBarrier()
 print x
}
//Processor #2:
x = 42
OSMemoryBarrier()
f = 1

这样，我们所有的内存操作都将按顺序进行，不必担心硬件内存重新排序会产生不必要的副作用。

发生竞态条件时，多个线程的行为取决于单个线程的运行时行为。假设有两个线程，一个执行计算并将结果保存在 x 中，另一个（可能来自不同的线程，比如用户交互线程）将结果打印到屏幕上：

var x = 100
func calculate() {
   var y = 0
   for i in 1...1000 {
       y += i
   }
   x = y
}
calculate()
print(x)

根据这些线程执行的时间点，Thread2 有可能不会将计算结果打印到屏幕上，它可能还持有之前的值，而这样的行为是非预期的。

还有另外一种情况，即两个线程向同一个数组写入。假设第一个线程将“Concurrency with Swift:”中的单词写入数组，另一个线程写入“What could possibly go wrong?”。我们可以这样实现：

func write(_ text: String) {
   let words = text.split(separator: " ")
   for word in words {
       title.append(String(word))
   }
}
write("Concurrency with Swift:") // Thread 1
write("What could possibly go wrong?") // Thread 2

我们可能会得到错乱的标题：

“Concurrency with What could possibly Swift: go wrong?”

这不是我们所期望的那样，不是吗？不过我们有很多种方法可以解决这个问题：

var title : [String] = []
var lock = NSLock()
func write(_ text: String) {
   let words = text.split(separator: " ")
   lock.lock()
   for word in words {
       title.append(String(word))
       print(word)
   }
   lock.unlock()

另一种方法是使用 Dispatch Queue：

var title : [String] = []
func write(_ text: String) {
   let words = text.split(separator: " ")
   DispatchQueue.main.async {
       for word in words {
           title.append(String(word))
           print(word)
       }
   }

可以根据你的需求选择其中的一种。一般来说，我倾向于使用 Dispatch Queue。这种方法可以防止出现死锁等问题，我们将在下面详细介绍。

我们可以使用多种方法来解决竟态条件问题，但如果我们使用了 Lock、Mutexe 或 Semaphore，将会引入另一个问题：死锁。

死锁是由环状等待引起的。一个线程在等待第二个线程持有的资源，第二个线程也在等待第一个线程持有的资源。

举个简单的例子，在一个银行账户上执行一个事务，这个事务分为两个部分：先取款，后存款。

代码看起来像这样：

class Account: NSObject {
   var balance: Double
   var id: Int
   override init(id: Int, balance: Double) {
       self.id = id
       self.balance = balance
   }
   func withdraw(amount: Double) {
       balance -= amount
   }
   func deposit(amount: Double) {
       balance += amount
   }
}
let a = Account(id: 1, balance: 1000)
let b = Account(id: 2, balance: 300)
DispatchQueue.global(qos: .background).async {
   transfer(from: a, to: b, amount: 200)
}
DispatchQueue.global(qos: .background).async {
   transfer(from: b, to: a, amount: 200)
}
func transfer(from: Account, to: Account, amount: Double) {
   from.synchronized(lockObj: self) { () -> T in
       to.synchronized(lockObj: self) { () -> T in
           from.withdraw(amount: amount)
           to.deposit(amount: amount)
       }
   }
}
extension NSObject {
   func synchronized(lockObj: AnyObject!, closure: () throws -> T) rethrows ->  T
   {
       objc_sync_enter(lockObj)
       defer {
           objc_sync_exit(lockObj)
       }
       return try closure()
   }
}

我们在事务之间引入了依赖关系，这将导致死锁。

另一个死锁问题是哲学家就餐问题。在维基百科上是这么描述的：

“五位沉默的哲学家坐在圆桌旁，桌上放着一碗意大利面。叉子放置在每对相邻的哲学家之间。

每位哲学家都必须在思考和吃饭之间交替。不过，哲学家只有在左手边和右手边的叉子同时可用时才能吃意大利面。每个叉子同时只能由一位哲学家持有，因此只有当没有其他哲学家在使用它时，其中的一位哲学家才能使用它。一位哲学家在吃完之后，需要放下两把叉子，以便让其他哲学家使用叉子。哲学家可以拿起他右手边或左手边的叉子，但是在拿到两个叉子之前不能开始进食。

进食不受意大利面条或胃的限制，假设面条可以无限量供应，哲学家的胃也是填不饱的。”

你可以花很多时间来解决这个问题，这里有一个简单的方法，例如：

1 . 抓住你左边的叉子，如果有的话

2 . 等待右边的叉子

2a. 如果它可用：拿起它

2B. 如果经过一段时间后，没有叉子可用，把左边的叉子放回原处

3 . 退后并重新开始

这种方式可能不起作用，实际上很有可能会引起死锁。

活锁（livelock）是死锁的一个特例。死锁是指等待一个资源被释放，而活锁是指多个线程等待其他线程释放资源。这些资源不断改变状态，但这些切来切去的线程却毫无进展。

在现实生活中，活锁可以发生在一个狭小的巷子里，两个人都想要穿过去，但出于礼貌，他们走在了同一边。然后他们尝试同时切换到了另一边，结果又把彼此挡住了。这可以无限期地发生下去，从而产生活锁。你之前可能经历过这个。

锁可能导致的另一个问题是严重争用锁（Heavily Contended Lock）。想象一下收费站，如果汽车到达收费站速度比收费站的处理速度快，就会发生堵车。锁和线程也是如此。如果一个锁被严重争用，那么同步部分就执行缓慢。这将导致很多线程排队，被挂起，最终会影响性能。

如前所述，线程可以有不同的优先级。线程优先级可以让我们确保特定任务将尽快得到执行。但是，如果我们将少量任务添加到低优先级线程中，而将大量任务添加到高优先级线程中，会发生什么？低优先级线程将会出现饥饿，因为它将得不到执行时间。结果是，低优先级的任务将不会被执行或需要很长时间才能执行完。

一旦我们加入锁机制，上面的线程饥饿就会变得很有趣。现在假设有一个低优先级的线程 3，它锁定了一个资源。高优先级线程 1 想要访问此资源，因此必须等待。另一个优先级高于 3 的线程 2 将会带来灾难性的结果。因为它的优先级高于线程 3，它将首先被执行。如果这个线程长时间运行，它将占用线程 3 可以使用的所有资源。由于线程 3 无法执行，导致线程 1 阻塞，所以线程 2 成了饿死线程 1 的“凶手”。即使线程 1 的优先级高于线程 2，情况也是如此。

说了这么多与线程有关的内容，还有最后一点需要提及。你可能不会遇到这种情况，但它仍然可能发生。线程的状态改变其实是上下文切换。作为开发人员，我们经常抱怨在多任务间切换（或被人打断）会让我们效率低下。如果进行上下文切换，CPU 也会发生同样的情况。所有预加载的命令都需要刷新，而且在短时间内它无法进行任何命令预测。

那么如果我们经常切换线程会发生什么呢？CPU 将无法再预测任何内容，从而导致效率低下。它只能执行当前命令，并且必须等待下一个，这会导致更多的开销。

作为一般性准则，尽量不要使用太多线程：

“尽可能少，够用就好。”

即使你正确地完成了所有操作，可以完全控制好同步、锁定、内存操作和线程，但仍然有一点需要注意。Swift 编译器不保证会保留你的代码的执行顺序，这可能导致你的同步机制不会与你编写它们时的顺序保持一致。

换一种说法：

“Swift 本身并不是 100％线程安全的”。

如果你想要对并发性（例如在使用 AudioUnits 时）做出 100% 的保证，可能需要回到 Objective-C。

如你所见，并发是个复杂的话题。很多情况下都会出错，但同时又给我们带来好处。我们使用的大多数工具都是面向开发人员的，如果代码太多，将无法进行调试。所以，谨慎选择你的工具。

苹果提供了一些调试并发性的工具，例如 Activity Group 和 Breadcrumb。可惜的是，它们目前在 Swift 中不受支持（尽管有一个包装器可用在 Activity 上）。

https://medium.com/flawless-app-stories/parallel-programming-with-swift-what-could-possibly-go-wrong-f5bcc38b1814

2018 世界杯总决赛巅峰对决在即，《技术领导力 300 讲专栏》超级团燃情上线。

池建强、冯大辉、左耳朵耗子、tinyfool 四位技术大佬轮番上阵，领衔开团，邀你一起拼，让强者更强。