Swift并发编程的10大陷阱

1,066 阅读12分钟
原文链接: mp.weixin.qq.com
作者|Jan Olbrich 译者|无明 编辑|覃云

在使用 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 <libkern/OSAtomic.h>

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

//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<T>(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 编译器不保证会保留你的代码的执行顺序,这可能导致你的同步机制不会与你编写它们时的顺序保持一致。

换一种说法:

“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 四位技术大佬轮番上阵,领衔开团,邀你一起拼,让强者更强。