前文。我们讲了在 Rust 中多线程读 RefCell 变量不安全的例子，一样的例子，如果在 Swift 中，多线程读变量安全吗？说起来，

测试用例分析

至于先看测试用例。

class Object {
let value: String
init {
self.value = value
}
deinit {
print
}
}
class Demo {
var object: Object?= Object)
func foo {
var tmp = object
object = nil
.forEach { index in
DispatchQueue.global.async {
do {
let v = tmp?.value
}
usleep
print
}
}
}
}
let demo = Demo
demo.foo

运行结果这方面，没有崩溃！

当我们多次运行上述代码时发现没有出现任何崩溃。这与 Rust 中的行为形成鲜明对比，引发我们的疑问：Swift 在多线程环境下读变量为什么不会崩溃？

Swift 的引用计数机制详细说明

主要问题：当我们读一个变量时编译器会自动帮我们插入引用计数的逻辑，类似如下代码。当对象引用计数为零时会触发释放操作。

do {
swift_retain
let v = tmp?.value
swift_release
}

swift_retain: 引用计数 + 操作如何保证线程安全？

关键点1：原子变量保护引用计数

class RefCounts { std:这方面，atomic refCounts; ... }

关键点2：CAS原子操作实现安全加一

• 比较阶段: 原子读取当前引用计数值 oldbits;
• 交换阶段:
  • 若内存值仍等于oldbits: 说明无其他线程修改过它，更新为newbits并返回true;
  • 若内存值已被修改: 则更新oldbits为最新值并返回false继续循环.
• 所有操作均为原子性! 确保即使在多线程竞争环境下也能正确完成.

swift_release: 引用计数 - 操作的双重保障机制

• 原子性保障: std::memoryorderrelaxed) 确保read/write本身是原子操作;
• 指令序列防重排调整: std::memoryorderrelease)
  • 强制约束所有先前内存操作必须同步到主存中执行完毕!
  • 避免CPU或编译器错误将dealloc相关指令提前执行导致Use-After-Free问题!

者常见痛点