对这个问题的回答。
在Swift 5.5之前，并发依赖于Grand Central Dispatch（GCD）和手动线程管理，这经常导致数据竞争和因未保护的共享可变状态导致的内存损坏。Swift引入了结构化并发和Actors，以提供隔离保证，但编译器需要一种机制来确保在这些隔离域之间传递的值天生是线程安全的。这导致了Sendable协议的产生，该协议标记类型为在并发边界之间安全共享，通过在类型级别强制值语义或内部同步。
当Actor从其隔离域外接收值时，该值可能是与其他执行上下文共享的引用类型，允许同时更改，违反内存安全。传统方法依赖于运行时锁或互斥量来保护关键部分，但这些方法引入了开销、死锁风险，并且在实现过程中易出错。挑战在于设计一种零成本抽象，静态验证编译时的线程安全，同时保持Swift的性能特征和易用性。
Swift的编译器要求所有跨Actor边界传递的类型都必须遵循Sendable协议，利用静态分析在不引入运行时开销的情况下验证安全性。值类型如struct和enum隐式地是Sendable，因为它们表现出值语义并使用写时复制优化来防止共享的可变状态。对于引用类型（class），编译器要求显式符合Sendable，强制该类为final并仅包含Sendable属性，从而有效保证不可变或内部同步状态，无法被并发访问腐坏。
// 隐式 Sendable 结构 struct UserData: Sendable { let id: UUID let score: Int } // 显式 Sendable 的最终类，具有不可变状态 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)") } }
在架构实时金融交易应用程序时，我们的团队实现了一个PriceFeedActor，负责从多个WebSocket连接聚合市场数据，需要从运行在后台线程上的NetworkManager接收解析的JSON有效负载。最初，我们使用引用类型MarketData类，避免在高频更新期间复制大型数据集，但Swift编译器阻止我们将这些对象直接传递给Actor，因为它们缺乏Sendable合规性，并且包含用于缓存计算的可变字典。这迫使我们重新设计数据模型，以维护Actor的隔离保证，而不牺牲用于亚毫秒交易决策所需的吞吐量。
我们将MarketData重构为一个struct，其中包含用于大型字节缓冲区的私有存储，并通过ManagedBuffer利用Swift的写时复制机制，以便在发生突变之前共享基础存储。这种方法提供了隐式的Sendable合规性，确保了编译时安全，同时在读重操作期间最小化内存重复。然而，手动实现写时复制逻辑的复杂性引入了维护开销，如果在热路径上的写操作中意外触发了自动复制行为，我们会面临性能下降的风险。
我们保留了MarketData引用类型，但将其重构为一个final class，仅包含let常量和深度不可变的Sendable属性，使我们能够在多个Actors之间共享单一只读实例，而不会出现数据竞争。这保留了对大型数据集的引用语义的效率，并完全消除了复制开销，但要求重构我们的缓存策略，以使用Actor隔离的可变状态，而不是内部类的突变。这一架构转变要求我们对缓存层进行重大重构，以将可变状态移动到专用的Actors中，增加了代码复杂性，但确保了严格的隔离保证。
作为对无法立即重构的遗留Objective-C桥接类的临时措施，我们使用**@unchecked Sendable标记它们，以抑制编译器警告，同时通过内部锁手动验证线程安全。这允许快速迁移到新的Actor模型，但实际上禁用了Swift**的静态保证，并重新引入了运行时数据竞争的风险，如果我们的手动同步逻辑存在错误。因此，我们将这种方法限制在非关键日志基础设施中，避免将其用于安全至关重要的生产金融数据。
我们对高频流数据采用了struct方法，使用优化设计与写时复制，同时保留了不可变的class方法用于多个Actors同时访问的静态配置对象。这种混合方法消除了在压力测试期间检测到的所有数据竞争崩溃，与之前基于GCD的架构相比，将并发相关的错误报告减少了94%。编译时的Sendable检查在开发过程中捕获了三个潜在的竞争条件，这些条件会导致之前手动锁系统中偶尔的生产崩溃。
为什么符合Sendable的类型在通过闭包捕获并传递给异步任务时仍然无法编译，而闭包上的@Sendable属性如何解决这种歧义？
虽然类型可以是Sendable，但Swift中的闭包默认通过引用捕获变量，这可能在闭包发送到另一个Actor后，允许对捕获变量的后续突变。@Sendable闭包属性限制捕获为Sendable值，并强制闭包本身不安全地逃逸并发域。这确保了闭包及其所有捕获状态在Actor边界之间保持隔离保证，防止通过可变捕获列表在异步操作中引入数据竞争。
Swift 6的严格并发检查如何影响隐式导入的Objective-C头文件，哪些机制允许与缺乏Sendable注释的遗留框架继续互操作？
Swift 6引入了严格的并发检查，默认将大多数Objective-C类型视为非Sendable，因为它们无法提供静态安全保证。开发人员必须使用**@preconcurrency导入语句逐步采用安全检查，或手动使用SWIFT_SENDABLE宏注释Objective-C头文件。这些注释使编译器能够区分线程安全的遗留对象与需要隔离边界的对象，从而在不影响纯Swift**代码的安全性情况下实现互操作。
在Actor中的非隔离方法与Sendable类型之间的根本区别是什么，当对可变类实例调用非隔离方法时何时会引入未定义行为？
非隔离方法允许从其隔离上下文外部同步访问Actor的数据，但它们在调用者的执行器上执行，而不是在Actor的串行执行器上。这要求方法不能直接访问可变的Actor状态，因为这样做将绕过Actor的隔离保证。当应用于不可Sendable的可变引用类型时，非隔离方法如果访问共享的可变状态而没有适当的同步，可能会引入竞争条件，导致内存损坏或未定义行为。