Rust引入了自动特性——如Send和Sync——来解决手动证明每个合成类型的线程安全的使用负担。历史上，系统程序员必须为每个结构注释复杂的并发合同，这既容易出错又冗长。编译器通过自动实现这些特性，对于聚合类型（结构体、枚举、元组）进行处理，仅当它们的所有构成字段都实现这些特性时才适用。
问题出现在原始指针(*const T和*mut T)上。与引用或智能指针不同，原始指针没有所有权或别名语义，编译器无法验证。它们可能指向线程局部存储、未分配的内存或通过外部同步管理的共享可变状态。仅仅基于T来盲目地将Send或Sync应用于原始指针，会违反内存安全，因为编译器无法保证指针在线程边界之间被正确使用。
解决方案分裂了推导逻辑。对于聚合体，编译器执行结构递归：检查每个字段。对于原始指针，编译器明确地保留这些实现，视其为不透明的、潜在不安全的句柄。这迫使开发者使用unsafe impl Send或unsafe impl Sync，对维护线程安全保证承担个人责任，因为编译器无法推断这些。
use std::ptr::NonNull; // 聚合类型 struct Container<T> { data: Vec<T>, // Vec<T> 是 Send 如果 T 是 Send index: usize, } // Container<T> 会自动实现 Send 如果 T: Send // 包含原始指针的类型 struct Node<T> { value: T, next: *mut Node<T>, // 原始指针打破了自动推导 } // 需要显式选项 unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
在为高频交易应用开发一个零分配、无锁的MPMC（多生产者，多消费者）环形缓冲区时，我需要节点驻留在预分配数组中，以避免jemalloc竞争。Node结构包含有效负载和一个*mut Node<T>下一个指针，形成侵入式链表。在试图将缓冲区句柄发送到工作线程时，编译器拒绝了代码，因为Node没有实现Send，尽管我知道节点仅通过原子比较和交换操作访问。
我评估了三种解决方案。首先，将原始指针替换为Box<Node<T>>。由于Box暗示堆所有权和单独分配，这种方案被拒绝，这会导致缓存友好的环形缓冲区碎片化并引入在高频交易中不可接受的分配延迟。其次，使用NonNull<Node<T>>包裹在AtomicPtr中。虽然AtomicPtr本身如果T是Send则是Send，但包含的Node结构仍然未能自动推导，因为NonNull内部的原始指针（这是原始指针的包装器）阻止了结构检查。第三，通过使用unsafe impl块手动实现Send和Sync。
经过正式验证所有对next指针的访问都经过SeqCst原子操作的保护，确保先发生关系防止数据竞争后，我选择了第三种方法。这种解决方案保留了无锁、零分配的架构，同时满足了Rust的类型系统。结果是一个生产级队列，能够每秒处理数百万个事件，没有互斥开销，尽管它需要为未来的维护者广泛的SAFETY注释。
为什么指向Send类型的原始指针不会自动实现Send？
候选人经常假设Send在所有字段之间是“传递的”，包括原始指针。他们未能认识到原始指针是没有内在所有权语义的原始类型。编译器无法区分指向线程局部存储的指针和指向共享堆内存的指针，也无法验证别名规则。因此，*const T和*mut T永远不会自动实现Send或Sync，无论T如何，迫使程序员使用unsafe impl来承担指针的线程安全合同。
如何为包含不安全内部的泛型结构条件性地实现Send？
许多开发者假设unsafe impl必须是无条件的。实际上，你可以写unsafe impl<T> Send for MyType<T> where T: Send + 'static {}。这对于只能在内容是Send时才应实现Send的通用容器（如自定义的UnsafeCell包装器）至关重要。候选人未注意到unsafe impl中的where子句允许与安全特性相同的表达能力，确保线程安全约束通过泛型代码正确传播而不对实现施加过多限制。
在拥有原始指针的类型上实现Sync与Send的安全要求有什么区别？
Send仅要求在线程边界之间转移值的所有权是安全的。对于原始指针，这通常意味着如果被指向的对象是Send，移动地址值是安全的。然而，Sync要求在跨线程共享不可变引用（&Self）是安全的。如果&Node暴露原始指针值（可能会被解引用），而另一个线程通过可变引用改变被指向的对象，这就构成了数据竞争。因此，对于含有原始指针的类型，Sync的实现几乎总是需要证明同步访问（例如，指针仅在Mutex下或通过原子操作访问），而Send可能仅需要证明唯一的所有权转移。