用于!Sync类型的UnCell封装是否可靠？Send边界是否正确？

开发实现需要满足Sync约束的类型时，常会用到!Sync类型（比如bumpalo::Bump）作为内部实现组件。我目前的方案是给外层类型编写unsafe impl Sync声明，且仅在&mut self方法中操作内部的!Sync类型，想确认如下封装隔离unsafe逻辑的方案是否健全可靠，尤其是其中的Send trait边界设置是否正确：

pub struct UnCell<T> {
    value: T
}

unsafe impl<T> Sync for UnCell<T> {}

impl<T> UnCell<T> {
    pub fn new(value: T) -> Self {
        Self { value }
    }
    pub fn into_inner(self) -> T {
        self.value
    }
    pub fn get(&mut self) -> &T {
        &self.value
    }
}
impl<T: Send> UnCell<T> {
    pub fn get_mut(&mut self) -> &mut T {
        &mut self.value
    }
}

这个实现不健全，存在明确的内存安全风险，Send边界设置完全错误。

核心问题 #

• 你为UnCell<T>实现Sync时没有加任何trait约束，等于告诉编译器「任意T的不可变引用都可以安全跨线程共享」，这直接违反了Sync的安全契约。Sync的核心要求是：当多个线程同时持有类型的不可变引用时，不会触发数据竞争。
• 你试图通过「仅用&mut self方法访问内部值」来规避并发访问，但无约束的Sync实现会直接击穿这个防护：如果T是!Send类型（比如引用计数非原子的Rc<u32>），UnCell<Rc<u32>>会被编译器判定为可跨线程共享，用户完全可以把它包在Arc<Mutex<_>>里传到其他线程，拿到锁之后调用into_inner()把Rc move到当前线程——非原子引用计数跨线程修改会直接触发数据竞争，造成内存损坏。
• 你给get_mut加的T: Send边界完全没有防护作用：get、into_inner方法都没有这个边界，用户可以直接绕过get_mut，跨线程转移!Send类型的所有权，或者拿到内部!Sync类型的引用触发未定义行为。

正确实现方案 #

你要做的本质是「标记内部值只会被独占访问，不会出现并发读写」，这种场景下实现Sync的唯一必要约束是T: Send——因为跨线程共享UnCell的引用后，只要能拿到独占引用就可能把内部值move到当前线程，必须保证T本身支持跨线程转移所有权。
不需要给任何方法单独加Send边界，只要保证所有访问内部值的方法都接收&mut self，就不会出现多线程同时访问内部值的情况。修正后的代码如下：

pub struct UnCell<T> {
    value: T
}

// 安全保证：所有内部值访问都要求&mut self，不存在并发访问，仅要求T可跨线程转移所有权
unsafe impl<T: Send> Sync for UnCell<T> {}
// Send trait由编译器自动实现即可：UnCell<T>是否可跨线程发送，和T保持一致，不需要手动标记

impl<T> UnCell<T> {
    pub fn new(value: T) -> Self {
        Self { value }
    }
    pub fn into_inner(self) -> T {
        self.value
    }
    pub fn get(&mut self) -> &T {
        &self.value
    }
    pub fn get_mut(&mut self) -> &mut T {
        &mut self.value
    }
}

这个实现下，UnCell<bumpalo::Bump>这类Send + !Sync类型可以安全被标记为Sync，符合你只通过独占引用操作内部值的使用场景，不会暴露安全风险。

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