Linux下Futex吞吐量问题：std::future/promise异步API性能瓶颈

我太懂这种挫败感了——用std::future/std::promise把C风格回调的异步IO包装成现代C++接口，逻辑上完全顺理成章，结果跑性能测试时发现，居然是底层的futex拖了后腿，哪怕我们都知道futex是用户态里最高效的同步机制之一。

先拆解一下为什么会出现这种情况：futex本身的单次开销确实很低，但std::future/std::promise的通用实现带来的额外成本，在高并发IO场景下会被无限放大：

• 高频的等待/唤醒累积开销：每个IO请求对应一次std::promise::set_value()和std::future::get()，这意味着每次完成都要触发futex的唤醒操作，大量小IO请求的情况下，这些零碎的系统调用（哪怕是用户态优先的futex）会攒出可观的性能损耗。
• 不必要的线程上下文切换：当等待线程因为futex挂起时，哪怕只是短暂的IO延迟，也可能触发内核态的上下文切换——这可比用户态操作重多了，而std::future的默认实现通常不会做自旋等待的优化。
• 隐性的内存同步开销：std::promise的状态更新会插入内存屏障，保证线程间的可见性，高频调用下这些内存屏障的开销也会被放大。

针对这些问题，给你几个实际可行的优化方向：

1. 自定义轻量级同步机制，减少futex依赖 #

如果想保留future/promise的接口风格，可以自己实现一套更贴合IO场景的简化版：

• 批量唤醒策略：把多个待完成的IO请求分组，当一批请求全部完成后，一次性唤醒所有等待的线程，大幅减少futex唤醒的次数。
• 自旋+超时降级：如果你的IO延迟很低（比如本地SSD或高速网络），可以让等待线程先自旋等待几轮（比如100次循环），如果还没等到结果再触发futex的内核挂起，避免不必要的上下文切换。

2. 切换到C++20协程，彻底绕开futex #

这是我最推荐的方案——协程的挂起和恢复完全在用户态完成，不需要依赖futex或者内核调度：
你可以封装一个自定义的awaitable对象，发起IO时挂起协程，C风格回调触发时直接恢复协程，全程无内核态开销。简单示例如下：

#include <coroutine>

// 假设你的IO库有这样的C风格异步接口
extern "C" void AsyncRead(void* ctx, uint64_t addr, byte* buff, uint64_t buffSize, void(*callback)(int));

struct ReadAwaitable {
    uint64_t addr;
    byte* buff;
    uint64_t buffSize;
    void* io_ctx;

    bool await_ready() const noexcept { return false; }
    void await_suspend(std::coroutine_handle<> handle) {
        // 把协程句柄传给C回调，完成后直接恢复协程
        AsyncRead(io_ctx, addr, buff, buffSize, [handle](int err) {
            // 这里可以加错误处理逻辑
            if (!err) handle.resume();
        });
    }
    void await_resume() noexcept {}
};

// 协程版的Read接口
struct task {
    struct promise_type {
        task get_return_object() { return {}; }
        std::suspend_never initial_suspend() noexcept { return {}; }
        std::suspend_never final_suspend() noexcept { return {}; }
        void return_void() noexcept {}
        void unhandled_exception() noexcept { std::terminate(); }
    };
};

task Read(uint64_t addr, byte* buff, uint64_t buffSize, void* io_ctx) {
    co_await ReadAwaitable{addr, buff, buffSize, io_ctx};
}

这种方式完全摆脱了std::future/std::promise的底层开销，性能提升会非常显著。

3. 复用std::promise对象，减少内存开销 #

如果必须保留std::future接口，可以通过对象池复用std::promise：

• 维护一个std::promise的对象池，每次IO请求从池中取出闲置的promise，完成后调用promise.reset()重置状态再放回池中，避免频繁创建销毁对象带来的内存分配和状态初始化成本。
• 用std::shared_future代替std::future，如果多个线程需要等待同一个IO结果，std::shared_future可以共享状态，避免多次复制带来的内存同步开销。

总的来说，futex本身不是问题，问题是std::future/std::promise的通用实现没有针对高并发IO做场景优化。根据你的项目约束选择合适的方案，不管是优化现有实现还是切换到协程，都能有效解决性能瓶颈。

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