Rust疑问：示例场景下Rc为何未实现Send特征？

Send从来不是只保证「把值跨线程移动这一个动作本身安全」，它的要求是：只要一个类型实现了Send，那么开发者按照这个类型的公开API做任何合法操作，跨线程传值之后都绝对不能触发内存未定义行为。
Rust的trait约束是类型级别的静态检查，编译器不会逐行跟踪你某一段代码里会不会踩坑——只要这个类型存在一种合法的使用方式会在多线程下出内存安全问题，就绝对不能标记为Send。

你觉得移动过程没问题，是只盯着「把x2移去子线程」这一步，漏了两个关键事实：

• 你把x2移走之后，主线程里的x1还在，它和x2指向同一块堆内存，共享同一个用非原子操作实现的引用计数器。
• 对普通内存位置的非原子读写，只要出现多线程无同步的并发访问，直接就是未定义行为，和你之前移动操作是不是按顺序完成没有任何关系。

哪怕你不在两个线程里额外克隆Rc，风险也客观存在：两个持有的Rc实例离开作用域时，会各自触发一次对共享计数器的非原子递减。

• 如果你没调用join等子线程执行完，主线程会先drop x1修改计数器，子线程可能还在运行，等它结束drop x2时会再次修改计数器。两个非原子操作并发执行时，很容易出现计数更新丢失：比如两个线程都读到当前计数是2，各自减1写回1，实际应该是0，最终堆内存不会被释放，造成内存泄漏；也可能出现计数提前减到0，堆内存被释放，另一个线程还持有指向这块内存的指针，触发use-after-free。
• 就算你每次都老老实实join，只要Rc允许跨线程传，你完全可以合法地在主线程和子线程里分别对自己持有的Rc调用clone，这些clone操作都会非原子修改同一个共享计数器，直接产生竞态。编译器没法阻止你调用这些公开API，所以只能从根上禁止Rc跨线程传递。

单线程里所有对引用计数的修改都是严格串行的，不存在并发访问非原子变量的问题，所以Rc在单线程下是完全安全的，性能还比原子计数的Arc更好。但只要允许Rc跨线程转移，就没法堵住两个线程同时操作共享计数器的可能，而非原子操作天生不支持多线程并发访问，这就是Rc不实现Send的根本原因。
需要跨线程用引用计数智能指针就用Arc，它的计数修改用的是CPU提供的原子指令，天生支持多线程并发访问，所以实现了Send。

你写的这段特定代码如果用unsafe绕过编译器检查把Rc发去子线程，在某些环境、某些运行条件下可能确实不会立刻崩溃，但这只是刚好没触发未定义行为的巧合，不代表这个操作是安全的。Rust的安全规则是兜底所有合法使用场景，不是为某一段碰巧没踩坑的代码开绿灯。

内容的提问来源于stack exchange，提问作者user3690467