为何gRPC C++客户端更推荐使用Callback API而非同步API？

gRPC官方C++文档明确，多数RPC场景下优先使用Callback API。对比同步客户端示例与Callback客户端示例后发现，Callback示例会把任务委托给其他线程，主线程仅休眠等待。

Callback代码示例 #

// The actual RPC.
std::mutex mu;
std::condition_variable cv;
bool done = false;
Status status;
stub_->async()->SayHello(&context, &request, &reply,
                         [&mu, &cv, &done, &status](Status s) {
                           status = std::move(s);
                           std::lock_guard<std::mutex> lock(mu);
                           done = true;
                           cv.notify_one();
                         });

std::unique_lock<std::mutex> lock(mu);
while (!done) {
  cv.wait(lock);
}

同步代码示例 #

// The actual RPC.
Status status = stub_->SayHello(&context, request, &reply);

疑问：Callback API是否会因线程开销导致运行速度更慢？

解答 #

核心结论：Callback API 不会因线程开销变慢，反而在高并发场景下性能更优 #

• 示例代码的局限性：你看到的Callback示例只是基础演示用法，故意让主线程等待回调完成，这并非Callback API的典型使用方式。实际场景中，主线程完全可以在等待回调的同时处理其他任务，不会空耗资源。
• 线程模型本质：gRPC的同步API底层同样依赖线程池处理IO操作，并非真正的"单线程同步"——同步调用会阻塞当前线程直到RPC完成，这会导致线程资源被长时间占用，高并发时易出现线程耗尽问题。而Callback API基于异步IO模型，复用底层线程池的线程，线程开销反而更低。
• 性能优势场景：处理大量并发RPC请求时，Callback API可在单个线程中管理多个异步请求，避免了同步API中频繁创建/销毁线程、线程上下文切换的开销，整体吞吐量显著提升。官方文档推荐它，正是因为多数实际生产场景（尤其是高并发）下，它的性能表现更出色。
• 额外注意点：若仅处理单个RPC请求，同步和Callback API的性能差异可忽略不计；但涉及批量请求或高并发场景时，Callback API的优势会凸显出来。

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