如何线程安全地实现与使用C++ PIMPL惯用法？

你的代码没有未定义行为，现有加锁措施已经足够保证线程安全，两个标注的可能加锁点都不需要额外加锁，具体原因如下：

关于Locking Point A（解引用m_impl位置） #

C++并发规范里对数据竞争的定义非常明确：只有当多个线程同时访问同一个内存位置，且至少有一个线程是写操作、且没有任何同步机制的时候，才会产生数据竞争触发未定义行为。如果所有线程都是读操作，根本不需要加锁。
你代码里的m_impl是unique_ptr<Impl>类型，在Foo构造函数里完成初始化赋值之后，整个运行期从来没有被修改过——没有调用过reset、没有做过指针赋值、没有发生过移动，所有线程访问m_impl的时候都只是读取它存储的指针值，然后解引用调用Impl的成员方法，全程没有对m_impl本身的写操作，所以多线程同时解引用完全安全，不需要额外加锁。
只有当你的PIMPL实现存在修改m_impl指针本身的逻辑（比如延迟初始化、运行时切换实现类）时，才需要对m_impl的读写加锁。

关于Locking Point B（跨线程调用foo.DoSomething位置） #

这个位置的调用同样完全合规，不需要调用方加锁：

• foo实例是在main函数的单线程上下文里完成构造的，两个子线程是在foo构造结束之后才启动，不存在构造过程中对象被跨线程访问的问题
• 你调用的DoSomething是const成员函数，整个调用路径没有修改Foo对象本身的任何成员（m_impl全程只读），多线程同时调用同一个对象的const成员函数、且不修改对象状态的场景，本身就被C++标准认可为线程安全
• 真正的共享资源（std::cout、Impl内部的可变状态）已经被Impl内部持有的m_mutex正确保护，进入共享区域前的同步是到位的
• 你的代码里是先join两个子线程，等所有子线程执行完毕后才会离开foo的作用域触发析构，不存在子线程还在访问对象时对象就被销毁的竞态，析构过程也是安全的。

你测试时从来没遇到异常不是运气好，是代码本身就不存在数据竞争。很多人有个错误认知：跨线程调用对象方法就必须在调用方加锁，本质是混淆了「调用方法」和「修改对象状态」的边界——只要方法不修改对象的非mutable成员、所有实际被修改的共享状态都有正确的同步保护，外层调用完全不需要额外加锁。

现有加锁方案的失效场景 #

你现在的写法只在两种场景下会出线程安全问题：

• 后续给Foo新增了会修改m_impl指针本身的接口（比如重置实现、移动赋值、swap操作等），并且这些接口会和DoSomething在多线程下被同时调用
• Impl内部新增了没有被m_mutex保护的可变共享状态，多线程下会对这些状态做并发无保护读写

PIMPL类多线程安全的实现准则 #

要写出多线程下安全的PIMPL类，遵守以下规则即可：

• 优先在构造函数里完成m_impl的初始化，尽量不要在对象可能被多线程访问的阶段修改m_impl指针本身；如果必须做延迟初始化，用std::once_flag配合std::call_once实现，不要手写双重检查锁，很容易因内存序写错引入未定义行为
• Impl内部的所有可变共享状态，全部由Impl自己持有的锁保护，不要把锁放到外层Foo类，避免不必要的耦合
• 如果确实需要支持运行时切换m_impl的场景，在Foo层单独加一把锁，所有对m_impl的读写（包括解引用调用）都要在持有这把锁的前提下进行
• 永远不要在构造函数里把this指针泄露给其他线程，确保对象完全构造完成后再被跨线程访问
• 持有跨线程共享的PIMPL对象时，要确保所有访问该对象的线程都退出后再销毁对象，避免析构竞态

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