この質問への答え。
Swift 5.5以前は、同時性はGrand Central Dispatch (GCD)と手動スレッド管理に依存しており、これが頻繁にデータ競合やメモリ破損を引き起こしていました。SwiftはActorsを用いて構造化された同時性を導入し、隔離の保証を提供しましたが、コンパイラは隔離された領域間で渡される値が本質的にスレッドセーフであることを確認するためのメカニズムを必要としていました。これが、値の意味論または型レベルでの内部同期を強制することによって、並行境界間での共有を安全とするタイプをマークするSendableプロトコルの導入につながりました。
Actorがその隔離領域の外から値を受け取ると、その値は他の実行コンテキストと共有された参照型である可能性があり、同時に変異が行われることでメモリ安全性に違反する可能性があります。従来のアプローチは、クリティカルセクションを保護するためにランタイムのロックやミューテックスに依存していましたが、これらはオーバーヘッド、デッドロックのリスクを招き、実装中に人為的なエラーが発生しやすくなります。課題は、Swiftのパフォーマンス特性と使いやすさを維持しつつ、コンパイル時にスレッドセーフを静的に検証するゼロコストの抽象化を設計することでした。
Swiftのコンパイラは、Actorの境界を越えて渡されるすべての型にSendableの適合性を義務付け、ランタイムオーバーヘッドなしに安全性を検証するために静的分析を利用しています。structやenumなどの値型は、値の意味論を示し、共有された変更可能な状態を防ぐためにコピーオンライターの最適化を使用するため、暗黙的にSendableと見なされます。参照型（class）に対しては、コンパイラが明示的なSendableの適合性を要求し、そのクラスがfinalであり、Sendableプロパティのみを含むことを強制し、同時アクセスによって破損されることのない不変または内部同期状態を実質的に保証します。
// 暗黙的に Sendable の struct struct UserData: Sendable { let id: UUID let score: Int } // 不変状態を持つ明示的に Sendable の final class final class Configuration: Sendable { let apiEndpoint: String let timeout: Duration init(endpoint: String, timeout: Duration) { self.apiEndpoint = endpoint self.timeout = timeout } } actor DataProcessor { func process(_ data: UserData) async { // 安全: UserData は Sendable print("Processing \(data.id)") } }
リアルタイムの金融取引アプリケーションを設計する際、私たちのチームは複数のWebSocket接続からの市場データを集約するPriceFeedActorを実装し、バックグラウンドスレッドで実行されているNetworkManagerから解析されたJSONペイロードを受信する必要がありました。最初は、大きなデータセットを高頻度で更新するために、参照型MarketDataクラスを使用していましたが、Swiftコンパイラは、これらのオブジェクトがSendableの適合性を持っておらず、計算結果をキャッシュするための変更可能な辞書を含んでいるため、Actorに直接渡すことを阻止しました。これにより、私たちはActorの隔離保障を維持しながら、サブミリ秒取引決定に必要なスループットを犠牲にすることなく、データモデルの再設計を強いられました。
私たちはMarketDataを大きなバイトバッファのプライベートストレージを持つstructに再構築し、Swiftのコピーオンライター機構を利用して、変更が発生するまで基盤ストレージを共有することにしました。このアプローチは自動的に暗黙的なSendableの適合性を提供し、読取りが多い操作中のメモリの重複を最小限に抑えつつコンパイル時の安全性を保証しました。しかし、手動のコピーオンライターロジックを実装する複雑さはメンテナンスオーバーヘッドを引き起こし、ホットパスの書き込み操作中に自動コピー動作が予期せずトリガーされた場合にパフォーマンスの低下を招くリスクがありました。
私たちはMarketDataの参照型を保持しましたが、let定数と深く不変なSendableプロパティのみを持つfinal classとして再構築し、複数のActors間でデータ競合なしに単一の読み取り専用インスタンスを共有できるようにしました。これにより、大きなデータセットに対する参照意味論の効率が保持され、コピーオーバーヘッドが完全に排除されましたが、変更可能な状態を内部クラスの変更ではなく、専用のActorsに移動させるキャッシュ戦略の再構築が必要でした。このアーキテクチャの変更は、コードの複雑性を増加させましたが、厳密な隔離保証を確保しました。
すぐに再設計できなかったレガシーObjective-Cブリッジクラスのための一時的な手段として、それらに**@unchecked Sendableを付けてコンパイラの警告を抑制し、内部ロックを介してスレッドセーフを手動で検証しました。これにより、新しいActor**モデルへの迅速な移行が可能になりましたが、Swiftの静的保証が実質的に無効になり、手動の同期ロジックにエラーが含まれていた場合、ランタイムデータ競合のリスクが再び導入されました。その結果、このアプローチは生産的な金融データに使用されることを避け、非クリティカルなロギングインフラストラクチャに制限しました。
高頻度のストリーミングデータには、最適化されたデザインでコピーオンライターを使用するstructアプローチを採用し、同時に複数のActorsによってアクセスされる静的構成オブジェクトには不変のclassアプローチを予約しました。このハイブリッドアプローチにより、ストレステスト中に検出されたすべてのデータ競合クラッシュが排除され、以前のGCDベースのアーキテクチャに比べて同時性に関連するバグ報告が94%減少しました。コンパイル時のSendableチェックは、以前の手動ロックシステムでの間欠的な生産クラッシュを引き起こしていた3つの潜在的な競合条件を開発中に検知しました。
Sendableに適合する型がasync Taskに渡されたクロージャによってキャプチャされたとき、なぜコンパイルに失敗し、@Sendable属性がこのあいまいさをどのように解決するのか？
型がSendableである可能性がある一方で、Swiftのクロージャはデフォルトで変数を参照でキャプチャするため、クロージャが他のActorに送信された後にキャプチャされた変数の変更が許される可能性があります。@Sendableクロージャ属性はキャプチャをSendable値に制限し、クロージャ自体が安全に並行ドメインから逃げることを強制します。これにより、クロージャとそのキャプチャされたすべての状態がActorの境界を越えて隔離の保証を維持し、非同期操作での変更可能なキャプチャリストによるデータ競合の導入を防ぎます。
Swift 6の厳格な同時性チェックが暗黙的にインポートされたObjective-Cヘッダーにどのように影響し、Sendableアノテーションのないレガシーフレームワークとの相互運用をどのように可能にするのか？
Swift 6は、静的安全保証を提供できないため、ほとんどのObjective-C型をデフォルトで非Sendableとして扱う厳格な同時性チェックを導入します。開発者は、@preconcurrencyインポートステートメントを使用して安全チェックを段階的に採用する必要があるか、手動でSWIFT_SENDABLEマクロでObjective-Cヘッダーに注釈を付けなければなりません。これらのアノテーションにより、コンパイラはスレッドセーフなレガシーオブジェクトと隔離境界を必要とするオブジェクトを区別できるようになり、純粋なSwiftコードの安全性を損なうことなく相互運用が可能になります。
アクター内の非隔離メソッドとSendable型との根本的な違いは何か、そして変更可能なクラスインスタンスで非隔離メソッドを呼び出すときにいつ未定義の動作が導入されるのか？
非隔離メソッドは、隔離コンテキストの外からActorのデータに対して同期アクセスを許可しますが、呼び出し元のエグゼキュータ上で実行されるため、Actorの直列エグゼキュータ上では実行されません。このため、そのメソッドは変更可能なActorの状態に直接アクセスしない必要があります。そうでなければ、Actorの隔離保証をバイパスすることになります。変更可能な参照型に適用された場合にSendableでない場合、非隔離メソッドが適切な同期なしに共有の変更可能な状態にアクセスすると、レースコンディションが導入され、メモリ破損や未定義の動作を引き起こす可能性があります。