Swift实现类似Kotlin协程带Mutex的并发任务方案咨询

先明确原Kotlin代码的核心需求：

• subAsyncJob1支持多协程并发执行
• subAsyncJob2必须互斥执行，同一时间只能有一个协程进入临界区

方案1：基于Actor的实现（推荐） #

这个方案是正确且符合Swift并发最佳实践的。

Swift的Actor是原生的并发安全原语，核心特性就是保证所有方法调用和属性访问都是串行化的。当多个异步任务调用mutex.lockAsyncJob时，Actor会自动对这些请求排队，确保同一时间只有一个任务能执行传入的闭包逻辑，完美对应Kotlin中Mutex.withLock的互斥效果。

你的Actor实现虽然简单，但完全满足需求：

actor Mutex {
    func lockAsyncJob<T>(_ operation: () async -> T) async -> T {
        return await operation()
    }
}

let mutex = Mutex()

private func startConcurrentJobs() async {
    await withTaskGroup(of: Void.self) { taskGroup in
        taskGroup.addTask {
            await self.asyncJob()
        }
        taskGroup.addTask {
            await self.asyncJob()
        }
    }
}

private func asyncJob() async {
    await subAsyncJob1() // 支持多任务并发执行
    
    await mutex.lockAsyncJob {
        // 同一时间仅一个任务能进入这里
        await subAsyncJob2()
    }
}

private func subAsyncJob1() async {
    // TODO: 并发执行的逻辑
}

private func subAsyncJob2() async {
    // TODO: 需要互斥访问的逻辑
}

方案2：基于DispatchQueue的实现（可行但不推荐） #

这个方案能实现互斥效果，但存在明显弊端：

1. 手动使用withCheckedContinuation挂起和恢复任务，代码冗余且容易出现遗漏resume的错误
2. 在GCD队列的闭包中创建Task，属于混合旧GCD和新Swift并发模型的写法，不够优雅，也增加了调试和维护复杂度
3. 需要手动维护串行队列，相比Actor的自动串行化，额外增加了代码负担

总结 #

优先选择基于Actor的方案，它是Swift并发模型的原生组件，代码更简洁安全，完全匹配原Kotlin代码的逻辑。DispatchQueue方案虽然能工作，但属于过时的GCD模式，在Swift并发环境下不是最优解。

内容的提问来源于stack exchange，提问作者user924