我自己也在寻找这个，并得出结论，在swift中还没有对此的原生构造。

我确实根据我从Matt Bridges和其他人那里看到的一些代码编写了这个小的帮助函数。

func synced(_ lock: Any, closure: () -> ()) {
    objc_sync_enter(lock)
    closure()
    objc_sync_exit(lock)
}

用法非常简单

synced(self) {
    println("This is a synchronized closure")
}

我发现了一个问题。在这一点上，传入一个数组作为lock参数似乎会导致一个非常迟钝的编译器错误。除此之外，虽然它似乎工作如所愿。

Bitcast requires both operands to be pointer or neither
  %26 = bitcast i64 %25 to %objc_object*, !dbg !378
LLVM ERROR: Broken function found, compilation aborted!

你可以把语句夹在objc_sync_enter(obj: AnyObject?)和objc_sync_exit(obj: AnyObject?)之间。@synchronized关键字在幕后使用这些方法。即。

objc_sync_enter(self)
... synchronized code ...
objc_sync_exit(self)

Dispatch_barrier_async是更好的方法，同时不会阻塞当前线程。

dispatch_barrier_async (accessQueue, { 字典对象。ID = object })

斯威夫特3

此代码具有重入能力，可以与异步函数调用一起工作。在这段代码中，someAsyncFunc()被调用之后，串行队列上的另一个函数闭包将被处理，但会被semapore .wait()阻塞，直到signal()被调用。internalQueue。不应该使用sync，因为如果我没有弄错的话，它会阻塞主线程。

let internalQueue = DispatchQueue(label: "serialQueue")
let semaphore = DispatchSemaphore(value: 1)

internalQueue.async {

    self.semaphore.wait()

    // Critical section

    someAsyncFunc() {

        // Do some work here

        self.semaphore.signal()
    }
}

如果没有错误处理，Objc_sync_enter /objc_sync_exit不是一个好主意。

为什么要让锁变得困难和麻烦呢? 使用分派障碍。

调度障碍在并发队列中创建同步点。 当它正在运行时，队列上的其他块都不允许运行，即使它是并发的并且其他内核可用。 如果这听起来像一个排他(写)锁，它是。 无障碍块可以被认为是共享(读)锁。 只要所有对资源的访问都是通过队列执行的，barrier就能提供非常廉价的同步。

你可以使用GCD。它比@synchronized更详细一点，但可以作为替代品:

let serialQueue = DispatchQueue(label: "com.test.mySerialQueue")
serialQueue.sync {
    // code
}