为何Buffer::AddValueTest与AddValueReference多线程性能差异显著？

我正在对比Buffer::AddValueTest()与Buffer::AddValueReference()的性能，基准测试显示256线程场景下AddValueReference的性能比AddValueTest快8倍，这超出预期。单线程时二者性能接近，但线程数增加后，AddValueTest的性能下降速度明显更快。

测试环境：AMD Milan（32核）工作站，clang 19.1.0编译，编译参数-std=c++17 -O3。

性能分析发现AddValueTest在获取和释放互斥锁上消耗更多时间。我原本以为把指标上报逻辑移出锁作用域后，AddValueTest会更快——至少性能应大致相当，想知道该性能问题的根源可能是什么？

实现代码 #

AddValueTest

bool AddValueTest(T val) {
    bool is_full = false;
    size_t buffer_size = 0;
    {
      absl::MutexLock lock(&mu_);
      if (stopped_) return false;

      is_full = buffer_.full();
      if (is_full) {
        buffer_.pop_front();
      }
      buffer_.push_back(std::move(val));
      buffer_size = buffer_.size();
    }

    if (is_full) {
      metric_reporter->IncDroppedValues();
    }
    metric_reporter->ReportQueueLength(buffer_size);
    return !is_full;
}

AddValueReference

bool AddValueReference(T val) {
    absl::MutexLock lock(&mu_);
    if (stopped_) return false;

    bool is_full = buffer_.full();
    if (is_full) {
      buffer_.pop_front();
      metric_reporter->IncDroppedValues();
    }

    buffer_.push_back(std::move(val));
    metric_reporter->ReportQueueLength(buffer_.size());
    return !is_full;
}

问题根源分析 #

• 锁竞争频率与调度开销放大：虽然AddValueTest把指标上报移出了锁，但锁内核心操作（状态检查、buffer修改）和AddValueReference完全一致。多线程场景下，AddValueTest解锁后立即执行指标上报，线程会快速回到就绪状态再次竞争锁；而AddValueReference解锁后没有立即的锁竞争动作。当线程数（256）远超过物理核心数（32）时，这种高频竞争会导致大量线程在锁上阻塞、唤醒，上下文切换和内核态等待的开销被急剧放大，这是性能差距的核心原因。

• absl::Mutex优化机制的利用差异：absl::Mutex内置自适应自旋等优化，当锁持有时间短且竞争不激烈时，会优先用用户态自旋避免内核态切换。AddValueReference在锁内连续完成所有逻辑，锁持有时间稳定，自旋优化能有效发挥作用；而AddValueTest的线程解锁后很快再次抢锁，导致Mutex的自旋策略失效，更多进入开销更大的内核态阻塞等待，进一步拉大性能差距。

• 缓存一致性开销：AddValueTest解锁后线程仍在运行并访问metric_reporter，会让持有锁的线程修改互斥锁内部状态后，需要更频繁地在多个核心间同步缓存行；而AddValueReference解锁后线程可能很快进入休眠，缓存同步的压力更低，减少了缓存一致性协议带来的额外开销。

• 编译器优化的隐性差异：即使都是-O3编译，AddValueTest的锁内逻辑与后续指标上报分离，编译器无法进行跨锁的指令优化；而AddValueReference的逻辑集中在锁内，编译器可以更高效地优化指令序列，缩短锁持有窗口时间，间接降低锁竞争的概率。

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