C++多线程调用类成员函数的锁机制及this指针访问疑问

不需要在通过this指针调用成员函数前对整个调用流程加锁。const成员函数触发Helgrind告警，要么是代码中存在未被注意到的真实数据竞争，要么是工具无法识别你代码中的线程安全契约导致的误报，两种情况都不需要通过粗粒度全局加锁解决。

• 存在真实数据竞争，和const修饰无关
  const只是C++语法层面的约束，承诺函数不会修改类的非mutable成员，不代表函数不存在共享状态访问：比如函数内部访问了静态变量、全局变量、其他线程可修改的外部对象指针/引用，或是修改了类内的mutable成员，只要存在多线程同时读写的场景，就会构成真实的数据竞争。最容易被忽略的场景是对象生命周期风险：如果工作线程仍在执行成员函数，this指向的对象已经被析构，Helgrind同样会抛出访问冲突告警。
• Helgrind误报
  Helgrind基于happens-before规则做竞争检测，无法识别用户自定义的生命周期契约：如果对象在启动所有工作线程前已经完成全部初始化，后续所有线程都只读访问成员、没有任何线程执行写操作，这个场景本身是线程安全的，但如果你没有使用标准同步原语明确标记初始化完成的可见性（比如用原生pthread接口创建线程、使用了过于宽松的内存序），工具就会误报“构造线程写成员、工作线程读成员”的竞争。

• 先甄别告警真实性
  对照Helgrind输出的栈回溯和竞争地址，定位到具体触发告警的变量，不要看到告警就直接加锁。如果是误报，只需要补充明确的同步语义标记即可，不需要加锁。
• 零开销消除只读场景的误报
  对于构造完成后完全只读的对象，在启动所有工作线程前加一行std::atomic_thread_fence(std::memory_order_release)，在每个工作线程的入口第一行加std::atomic_thread_fence(std::memory_order_acquire)，或是用std::call_once完成一次性初始化，既可以明确线程间的happens-before关系消除Helgrind误报，也不会带来锁的运行时开销。
• 缩小锁粒度，拒绝粗粒度全局锁
  不要在调用整个成员函数前加锁，把成员函数内的逻辑拆分处理：
  • 纯计算、不访问任何共享可变状态的逻辑：完全不需要加锁，支持多线程并发执行
  • 真正访问共享可变状态的代码片段：仅在执行这部分代码时，对对应共享变量加锁；如果多个共享变量之间没有关联，用不同的锁分别保护，最大程度保留并发能力。
• 读多写少场景用读写锁优化
  如果成员函数内的共享状态是读多写少场景，替换普通std::mutex为std::shared_mutex：读访问时加共享锁，允许多个线程同时进入读逻辑，仅在写访问时加独占锁，相比全量使用独占锁可以大幅提升并发性能。

注意：不要为了消除工具告警添加无意义的粗粒度锁，这类操作会直接把可并发的逻辑串行化，带来不必要的性能损耗。

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