質問の歴史: 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インスタンスを必要としました。このバッファは、最初のロギング呼び出し時にスレッドセーフなインスタンス化を必要としましたが、後続のアクセスは1分あたり数百万回発生し、ロックの競合は受け入れられませんでした。チームはこの初期化の課題を解決するために3つのアーキテクチャアプローチを評価しました。
考慮された最初の解決策: 手動DispatchOnceラッパー。 彼らは、レガシーObjective-Cパターンに似たカスタムdispatch_onceラッパーの実装を検討しました。このアプローチは、Objective-Cから移行する上級開発者にとって明示的な制御と親しみを提供しました。しかし、これはモジュール間での複製を必要とし、一貫性のない実装のリスクを増大させ、コードベースを明示的にlibDispatchプリミティブに結びつけました。利点には同期ロジックの明示的な可視性が含まれ、欠点にはメンテナンスの負担とトークン管理における人的ミスの可能性がありました。
考慮された2番目の解決策: 即時静的初期化。 彼らは、Swiftの組み込み保証を利用して、static let shared = EventBuffer()を使用することを検討しました。これにより手動同期コードが完全に排除され、コンパイラの最適化が可能になりました。しかし、このアプローチは、バッファがアプリ起動後に入手可能なランタイム設定パラメータ（キューサイズ、フラッシュ間隔）を必要としたため、彼らのユースケースには失敗しました。利点は同期オーバーヘッドがゼロで安全性が保証されることでしたが、欠点はパラメータ化された初期化に対する柔軟性のなさでした。
考慮された3番目の解決策: 手動チェックを伴う明示的な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ミューテックスにマッピングされる可能性があります。重要な違いは、これは変更の対象となる実装の詳細であるということです。コンパイラはこれをリラックスした原子読み込みや最適化されたビルドの定数伝播に最適化する可能性があります。候補者は、Swiftがこれをランタイム契約の一部として抽象化しているために、dispatch_onceが保証されるか、バックトレースで可視化されると誤って想定することが多いです。
なぜSwiftの遅延グローバル変数にアクセスするとデッドロックが発生する可能性があり、これはC++での静的初期化とどのように異なるのか？
デッドロックは、グローバルAの初期化式がグローバルBにアクセスし、Bの初期化（直接または間接的に）がAにアクセスすることで循環依存関係が生じると発生します。Swiftは、式の評価中、全体の期間にわたって初期化ロックを保持しますが、**C++**は異なる順序保証のもとで関数ローカルな静的変数を使用することがあります。予防策には、循環依存関係を構造改革によって打破し、複雑な初期化グラフのためにグローバルではなくlazy varインスタンスプロパティを使用するか、遅延評価に頼らずにアプリ起動時に明示的な初期化フェーズを実装することが求められます。
@mainエントリポイント属性は、グローバル変数の初期化タイミングとどのように相互作用するのか？
候補者は、グローバル変数がmain()内で初めて使用されると初期化されるとしばしば仮定します。しかし、Swiftでは、@main関数のエントリポイントが実行される前に、すべてのグローバル変数および型メタデータの静的初期化が行われます。この早期初期化は、実行時の起動中に発生するため、高価なグローバル初期化子が、これらの変数がすぐに参照されなくてもアプリの起動を遅延させます。これを理解することは、初回のフレームのメトリクスを大幅に改善できるため、スタートアップパフォーマンスの最適化において重要です。Objective-Cの開発者は、+initializeメソッドに類似した遅延動作を期待することが多いですが、Swiftのグローバル変数は異なるライフサイクルに従います。