问题的历史： 在Swift出现之前，Objective-C开发者依赖于Grand Central Dispatch的dispatch_once函数来保证单例和全局状态的单次初始化。虽然这一模式有效，但需要显式的样板代码和静态令牌的手动管理。Swift 1.0引入了一种编译器合成的机制，以消除这些样板代码，自动为全局变量和静态存储属性注入线程安全保护，而无需开发者的干预。
问题描述： 当多个线程同时访问一个全局变量，而该变量的初始化尚未完成时，竞争条件可能会导致双重初始化、内存泄漏或部分构造对象的撕裂读取。这个挑战需要确保确切的一次语义，同时不对初始化后的后续访问施加同步开销，并在平台之间保持ABI兼容性。
解决方案： Swift编译器为每个延迟的全局或静态变量生成一个隐藏的原子标志（或特定平台的等效物）和一个同步屏障。在第一次访问时，生成的代码会对这个标志进行原子检查；如果未初始化，它会获取一个低级锁（历史上是dispatch_once，现在通常是轻量级的原子比较并交换或互斥锁），再次验证状态（双重检查锁定），执行初始化表达式，设置标志，然后释放。后续访问在确认初始化后完全绕过同步，通过原子加载来实现。
// 开发者编写： let sharedCache = ImageCache() // 编译器生成大约： // static var $__lazy_storage: ImageCache? // static var $__once_token: AtomicBool/Builtin.Word // 并带有线程安全初始化包装
问题描述： 在为iOS开发一个高吞吐量分析SDK时，工程团队需要一个可跨多个线程访问的全局EventBuffer实例来记录用户交互。该缓冲区在第一次记录调用时需要线程安全的实例化，但后续访问每分钟发生数百万次，因此锁竞争不可接受。团队评估了三种架构方法来解决这一初始化挑战。
考虑的第一种解决方案：手动DispatchOnce包装。 他们考虑实现一个类似于旧有Objective-C模式的自定义dispatch_once包装。这个方法提供了显式控制和对从Objective-C迁移过来的资深开发者的熟悉感。然而，它引入了显著的样板代码，要求在模块之间复制，提高了一致性实现的风险，并把代码库显式绑定到libDispatch原语。优点包括同步逻辑的显式可见性；缺点包括维护负担和潜在的人为错误在令牌管理中。
考虑的第二种解决方案：即时静态初始化。 他们评估使用static let shared = EventBuffer()，依靠Swift的内置保证。这完全消除了手动同步代码，并允许编译器优化。然而，这种方法对他们的用例失败，因为该缓冲区需要在应用启动后才能获得的运行时配置参数（队列大小、刷新间隔）。优点是零同步开销和保证的安全性；缺点是对于参数化初始化的灵活性不足。
考虑的第三种解决方案：显式NSLock与手动检查。 团队考虑使用NSLock或pthread_mutex_t手动实现双重检查锁定。这样可以最大限度地控制初始化时机和设置过程中的错误处理。然而，它引入了关于锁排序风险的复杂性，如果初始化代码访问其他全局变量，并在热点路径上产生可测的性能开销。优点是细粒度控制；缺点是复杂性和性能下降。
选择的解决方案及其结果： 团队选择了一种混合方法。对于无参数的单例访问器，他们依赖于Swift编译器生成的延迟初始化(static let shared: EventBuffer = { ... }())，利用内置的原子保护。对于依赖配置的设置，他们将初始化移入在应用启动时调用的显式configure()方法，完全避免延迟初始化。这个选择消除了与初始化相关的竞争条件崩溃（之前占0.5%的会话）并减少了平均访问时间，相比手动锁定减少了60%，因为编译器将初始化后的路径优化为简单的非原子加载。
Swift全局的延迟初始化是否具体使用了dispatch_once，还是不同的机制？
尽管早期Swift版本实际上生成了dispatch_once调用，但现代Swift使用编译器生成的原子操作（通常在LLVM Builtin.Word类型上比较和交换），这些操作可能在Darwin平台上映射到dispatch_once或在Linux上映射到pthread互斥锁。关键区别在于这是一个可能变化的实现细节；编译器可能会将其优化为放松的原子加载，甚至在优化构建中常量传播。候选人常常错误地认为dispatch_once是保证的或在回溯中可见，忽视Swift在其运行时契约中对此的抽象。
为什么访问Swift中的延迟全局变量可能导致死锁，这与C++中的静态初始化有何不同？
当全局A的初始化表达式访问全局B，而B的初始化（直接或间接）又访问A，形成循环依赖时，就会发生死锁。与**C++不同，Swift在整个表达式评估过程中保持初始化锁定，而C++**可能使用具有不同排序保证的函数局部静态变量。防止死锁的措施包括通过重构打破循环依赖，使用lazy var实例属性而不是全局变量处理复杂的初始化图，或在应用启动过程中实现显式初始化阶段，而不是依赖于延迟评估。
@main入口点属性如何与全局变量初始化时机交互？
候选人常常假设全局变量在main()中首次使用时进行初始化。然而，Swift在@main函数入口点执行之前执行所有全局变量和类型元数据的静态初始化。这个急切的初始化发生在运行时启动期间，意味着耗时的全局初始化器甚至在这些变量尚未立即引用时也会延迟应用启动。理解这一点对于启动性能优化至关重要，因为将重初始化移入lazy var或显式设置函数可以显著改善首次帧的时间指标。Objective-C开发者往往期待与+initialize方法类似的延迟行为，但Swift全局变量遵循不同的生命周期。