猿族代码战记：Mutex 升级版——守护 Swift 并发的“香蕉仓库”

🦍 引子

旧金山废墟的猿族技术区，金属支架撑起的荧光屏泛着冷光，首席 Swift 架构师科巴的指节因攥紧终端而发白 ------ 食物计数系统又出问题了。

刚录入的 27 根香蕉，刷新页面竟变成 29，再点一下又跳回 28，旁边年轻猿工程师紧张地挠着头："科巴大人，不会是小猩猩偷偷改数据吧？" 科巴瞪了他一眼："是'并发幽灵'！自从用 Actor 保护状态，简单的计数全成了麻烦 ------ 查个库存要写await，就像咱们去仓库拿根香蕉，得先找凯撒签字、找后勤登记，折腾半小时！"

在本堂猩猩课堂中，您将学到如下内容：

🦍 引子
🛡️ 第一章：Actor 的麻烦 ------ 被异步绑架的简单需求
🔧 第二章：Mutex 实战 ------ 零 bug 香蕉计数器
📱 第三章：适配 SwiftUI------ 让 @Observable "看见" 变化
⚔️ 第四章：抉择 ------Mutex vs Actor
🌟 结尾：代码丛林的生存法则

今天，他要拿出压箱底的 "轻量武器" Mutex，让代码既能挡住并发风险，又能像猿族奔袭般迅猛如潮。

🛡️ 第一章：Actor 的麻烦 ------ 被异步绑架的简单需求

科巴拉过一把生锈的金属椅坐下，指尖在键盘上敲出 Actor 代码："你们看，要改香蕉数量，必须写await counter.addBanana()------ 就一个破赋值操作，硬生生被拖进异步队列！"

他顿了顿，指着屏幕上的@MainActor标签，"就算把计数器绑在主线程，其他哨站的猿想查库存，还是得等主线程'有空'------ 这和把仓库钥匙只给主营地的猿，其他猿只能站在门口等，有啥区别？"

旁边的猿工程师小声问："那以前咱们是怎么处理的？"

"以前靠 GCD 串行队列！" 科巴一拍桌子，"就像给仓库配个专属管理员，所有拿香蕉的请求都排队，谁也别插队。但队列太重了，现在 Swift 出了 Mutex------ 它是'轻量级锁'，只护一小块状态，操作完自动解锁，还不用写一堆异步代码！"

🔧 第二章：Mutex 实战 ------ 零 bug 香蕉计数器

科巴清了清嗓子，手指在键盘上飞快跳动，边写边讲解："Mutex 的核心是withLock方法 ------ 它会先'抢锁'，确保当前只有一个线程能操作状态，操作完不管成功或失败，都会自动'释放锁'，绝不会像手动加锁那样，忘了解锁导致整个系统卡死。"

很快，FoodCounter类的代码出现在屏幕上：

swift 复制代码

class FoodCounter {
    // 初始化 Mutex，把初始香蕉数设为0------相当于给空仓库装了把新锁
    private let mutex = Mutex(0)
    
    // 增加香蕉：开锁、给库存+1、自动锁门
    func addBanana() {
        mutex.withLock { count in
            count += 1 // 操作超简单，就像把香蕉放进仓库，一秒搞定
        }
    }
    
    // 减少香蕉：逻辑和加香蕉一样，只是把+1改成-1
    func removeBanana() {
        mutex.withLock { count in
            count -= 1
        }
    }
    
    // 读取库存：重点！读操作也要走 withLock，防止读的时候正好在写（比如刚加了半根香蕉）
    var bananaCount: Int {
        mutex.withLock { count in
            return count // 只读取，不修改，但也要保证独占访问
        }
    }
}

"千万别犯懒！" 科巴突然提高声音，"有猿觉得'读操作不用锁'，结果读的时候正好赶上写，拿到的是'脏数据'------ 上次有个猿没加锁读库存，以为还有 10 根香蕉，结果实际只剩 2 根，导致整个哨站的猿饿了半天！"

他演示了如何使用计数器，代码简洁得让猿工程师们发出惊叹：

swift 复制代码

let counter = FoodCounter()

counter.bananaCount = 10 // 直接赋值，不用等异步
print(counter.bananaCount) // 立刻输出10，没有半点延迟
counter.addBanana()

print(counter.bananaCount) // 输出11，实时更新

📱 第三章：适配 SwiftUI------ 让 @Observable "看见" 变化

正当猿族为新计数器欢呼时，负责 SwiftUI 仪表盘的猿跑过来："科巴大人，计数器接入界面后，香蕉数变了，界面却一动不动！" 科巴凑过去看了眼平板 ------ 屏幕上的数字始终停留在 10，哪怕点了 "加香蕉" 按钮也没反应。

"这是因为 @Observable '瞎'了！" 科巴很快找到问题，"Mutex 保护的是内部的库存数，库存变了，但 Mutex 本身没变化 ------@Observable 只能'看见'对象属性的直接修改，看不到 Mutex 里面的小动作。"

他伸手在键盘上敲了几行代码，给bananaCount的get和set加了 "传令兵"：

swift 复制代码

@Observable
final class FoodCounter: Sendable { // 加Sendable，允许计数器跨线程传递
    private let mutex = Mutex(0)
    
    var bananaCount: Int {
        get {
            // 告诉@Observable："有人在读香蕉数量啦，记下来！"
            self.access(keyPath: \.bananaCount)
            return mutex.withLock { $0 }
        }
        set {
            // 告诉@Observable："香蕉数量要变了，准备更新界面！"
            self.withMutation(keyPath: \.bananaCount) {
                mutex.withLock { count in
                    count = newValue
                }
            }
        }
    }
    
    // 省略addBanana和removeBanana...
}

"这俩方法是 @Observable 宏自动加的'钩子'，" 科巴解释，"access告诉框架'有人在读数据'，withMutation告诉框架'数据要改了'------ 这样界面就能跟 Mutex 里的库存同步，点一下按钮，数字立刻更新，童叟无欺！"

⚔️ 第四章：抉择 ------Mutex vs Actor

科巴把猿族工程师召集到一起，在黑板上画了张对比表，用炭笔重重标出关键差异：

对比维度	Mutex（轻量锁）	Actor（异步卫士）
代码风格	同步代码，不用写`await`，清爽直接	强制异步，处处要`await`，略显繁琐
适用场景	保护 1-2 个简单属性（如计数）、操作耗时极短	保护复杂对象（如网络管理器）、操作耗时较长（如下载图片）
线程行为	抢不到锁会 "阻塞"（等锁释放）	抢不到隔离权会 "挂起"（不阻塞线程）
学习成本	低，API 简单，上手快	高，要理解隔离域、Sendable 等概念

"选哪个不是看'谁更强'，而是看'谁更适合'！" 科巴敲了敲黑板，"如果你的需求像'数香蕉'一样简单，不想写一堆异步代码，就用 Mutex------ 它是'贴身短刀'，快准狠；如果你的需求是'跟人类服务器同步数据'，要处理一堆异步逻辑，就用 Actor------ 它是'坚固盾牌'，能扛住复杂并发。"

他顿了顿，补充道："我通常会两种都试一下，哪个写起来顺手就用哪个。比如这次的计数器，用 Mutex 写出来的代码比 Actor 简洁一半，还不用处理异步等待，那肯定选 Mutex 啊！"

🌟 结尾：代码丛林的生存法则

科巴把最后一行代码提交到猿族的代码仓库，终端屏幕上的香蕉计数稳定跳动 ------ 从 100 跳到 101，又跳到 102，那是远方哨站的猿刚入库的香蕉，正通过 Mutex 守护的代码，实时同步到主营地的仪表盘。

他走到窗边，看着外面：凯撒正带领年轻的猿族围着平板学习 Swift，阳光透过废墟的缝隙洒在他们身上，像给代码世界镀上了一层金光。

科巴拉过身边的年轻猿工程师，指着屏幕上的 Mutex 代码说："咱们猿族在丛林里生存，不会拿长矛去抓兔子，也不会拿匕首去对付狮子 ------ 代码世界也一样，没有'最强的工具'，只有'最适合当下的工具'。Mutex 是短刀，适合近距离快速解决问题；Actor 是盾牌，适合抵御大规模的并发攻击。懂取舍，会选工具，才是真 - 正的工程师。"

平板上的计数又跳了一下，这次是 103------ 猿族的食物储备越来越多，他们的 Swift 代码，也在 Mutex 和 Actor 的守护下，越来越稳固。

那么，各位微秃小猩猩，你们学"废"了吗？感谢观看，下次再会啦！8-)