bthread效率为什么更高？
1 基本概念
bthread是brpc中的用户态线程（也可称为M:N线程库），目的是：提高程序的并发度，同时降低编码难度，在多核cpu上提供更好的scalability和cache locality。其采用M:N模型，即多个用户线程（bthread）映射到少量的系统线程（pthread）上。
linux当下的pthread实现（NPTL）是1:1的，M个bthread也相当于映射至N个LWP。
bthread前身是Distributed Process(DP)中的fiber，一个N:1的合作式线程库，等价于event-loop库，但是同步方式。
2 高效做法
- 用户态调度：避免内核态和用户态之间的切换开销，上下文切换更快。系统线程的切换需要内核接入，而用户态线程的切换完全在用户空间完成，减少了系统调用和上下文切换的开销。
- 更轻量级的上下文切换：用户态线程的上下文数据量风小，只需要保存必要的寄存器状态，而内核线程需要保存更多的状态信息，比如浮点寄存器、信号处理器等。
- M:N模型：多个用户线程由较少的系统线程调度，减少了系统线程的创建和销毁开销，同时也减少了上下文切换的次数。系统线程的数量通常与cpu核心数相当，避免了过多的线程竞争。
- 无锁或细粒度锁的数据结构：任务队列使用无锁队列或细粒度锁，减少了线程间的竞争和等待时间，提高了并发性能。
- 工作窃取（work stealing）：当某个工作线程的任务队列为空时，可以从其他线程的队列中窃取任务，实现负载均衡，避免线程空闲，提高资源利用率。
- 定制化的内存池管理：采用内存池技术，复用栈空间，减少内存分配和释放的开销，避免频繁的系统调用。
- 避免阻塞系统调用：通过异步IO或非阻塞IO配合事件驱动，减少了线程因IO操作而阻塞的情况，提高了CPU利用率。
进一步解释
- 用户态调度
避免内核陷入；
能够实现0系统调用（无需内核调度器）；
| 类型 | 上下文切换时长 | 操作 |
|---|---|---|
| 用户态 | 50 - 100 ns | 仅需保存/恢复必要的寄存器（约10个reg） |
| 内核态 | 1-5 us | 保存完整的上下文（浮点寄存器、信号处理器等）；切换内核态堆栈 |
- M:N模型
| 维度 | M:N模型 | 1:1模型（eg. pthread） |
|---|---|---|
| 线程数量 | 百万级用户线程 | 千级系统线程 |
| 调度开销 | 用户态协作式调度 | 内核抢占式调度 |
| 内存占用 | 每个线程约4-64KB栈 | 每个线程约2-10MB |
| 创建/销毁成本 | 微秒级（纯用户态操作） | 毫秒级（需内核参与） |
- 任务调度策略
- 工作窃取算法
Task *steal_task()
{for (Worker &w : other_workers) {if (Task *t = w.queue.try_steal()) {return t;}}return nullptr;
}// 每个worker线程维护本地任务队列
// 空闲worker从其他worker的队列尾部窃取任务
// 减少锁竞争，提高CPU缓存命中率
- 协作式调度
显式yield让出cpu；
避免不必要的抢占，减少上下文切换；
- 内存管理优化
- 栈内存复用
class StackPool {
public:static constexpr int MAX_CACHED_STACKS = 1000;std::vector<void*> cached_stacks;void *alloc() {if (!cached_stacks.empty()) {return pop_back();}return ::malloc(STACK_SIZE);}void free(void *stack) {if (cached_stacks.size() < MAX_CACHED_STACKS) {cached_tasks.push_back(stack);} else {::free(stack);}}
};// 减少频繁的malloc/free
// 避免内存碎片
** 个人疑问？**
栈内存复用的场景是什么？
- 与异步I/O深度集成
- 事件驱动架构
void async_read(int fd, void *buf, size_t size) {epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, ...);bthread_yield();// IO完成后由事件循环唤醒
}// 通过epoll/kqueue实现非阻塞IO
// IO等待期间自动yield，不阻塞worker线程
3 性能对比数据
参考网络数据，本人未验证。
| 场景 | bthread吞吐量 | pthread吞吐量 |
|---|---|---|
| 10k空循环任务 | 1.2M tasks/sec | 120K tasks/sec |
| 网络代理（1KB包） | 850K req/sec | 65K req/sec |
| 数据库访问 | 720K QPS | 45K QPS |
4 bthread适用场景
- 高并发网络服务（eg. web服务器、rpc框架）
- 大规模并行计算（eg. 分布式任务调度）
- 低延迟交易系统（eg. 金融订单处理）
- 资源受限环境（eg. 嵌入式设备）
5 代价与限制
-
开发复杂度高
eg. 需要手动处理yield点 -
无法利用多核并行
单个worker线程仍绑定单个cpu核心 -
调试困难
用户态线程的堆栈跟踪不如内核线程直观
6 汇总原因
bthread的高效源自现代多核硬件和网络服务特征的深度优化，通过减少不必要的内核交互、精细化资源管理和智能调度策略，在特定场景下可带来数量级的性能提升。
7 FAQ
7.1 bthread不是coroutine
我们常说的协程特指N:1线程库，即所有的协程运行于一个系统线程中，计算能力和各类eventloop库等价。由于不跨线程，协程之间的切换不需要系统调用，可以非常快(100ns-200ns)，受cache一致性的影响也小。但代价是协程无法高效地利用多核，代码必须非阻塞，否则所有的协程都被卡住，对开发者要求苛刻。协程的这个特点使其适合写运行时间确定的IO服务器，典型如http server，在一些精心调试的场景中，可以达到非常高的吞吐。但百度内大部分在线服务的运行时间并不确定，且很多检索由几十人合作完成，一个缓慢的函数会卡住所有的协程。在这点上eventloop是类似的，一个回调卡住整个loop就卡住了，比如ubaserver（注意那个a，不是ubserver）是百度对异步框架的尝试，由多个并行的eventloop组成，真实表现糟糕：回调里打日志慢一些，访问redis卡顿，计算重一点，等待中的其他请求就会大量超时。所以这个框架从未流行起来。
bthread是一个M:N线程库，一个bthread被卡住不会影响其他bthread。关键技术两点：work stealing调度和butex，前者让bthread更快地被调度到更多的核心上，后者让bthread和pthread可以相互等待和唤醒。这两点协程都不需要。
7.2 最好不要在用户程序中调用bthread
除非你需要在一次RPC过程中让一些代码并发运行，你不应该直接调用bthread函数，把这些留给brpc做更好。
7.3 bthread和pthread woker
pthread worker在任何时间只会运行一个bthread，当前bthread挂起时，pthread worker先尝试从本地runqueue弹出一个待运行的bthread，若没有，则随机偷另一个worker的待运行bthread，仍然没有才睡眠并会在有新的待运行bthread时被唤醒。
7.4 bthread中能调用阻塞的pthread或系统函数
只阻塞当前pthread worker。其他pthread worker不受影响
若bthread因bthread API而阻塞，它会把当前pthread worker让给其他bthread。若bthread因pthread API或系统函数而阻塞，当前pthread worker上待运行的bthread会被其他空闲的pthread worker偷过去运行
7.5 pthread可以调用bthread API
bthread API在bthread中被调用时影响的是当前bthread，在pthread中被调用时影响的是当前pthread。使用bthread API的代码可以直接运行在pthread中。
7.6 若有大量的bthread调用了阻塞的pthread或系统函数，会影响RPC运行
比如有8个pthread worker，当有8个bthread都调用了系统usleep()后，处理网络收发的RPC代码就暂时无法运行了。只要阻塞时间不太长, 这一般没什么影响, 毕竟worker都用完了, 除了排队也没有什么好方法. 在brpc中用户可以选择调大worker数来缓解问题, 在server端可设置ServerOptions.num_threads或-bthread_concurrency, 在client端可设置-bthread_concurrency.
规避方法
- 一个容易想到的方法是动态增加worker数. 但实际未必如意, 当大量的worker同时被阻塞时, 它们很可能在等待同一个资源(比如同一把锁), 增加worker可能只是增加了更多的等待者.
- 那区分io线程和worker线程? io线程专门处理收发, worker线程调用用户逻辑, 即使worker线程全部阻塞也不会影响io线程. 但增加一层处理环节(io线程)并不能缓解拥塞, 如果worker线程全部卡住, 程序仍然会卡住, 只是卡的地方从socket缓冲转移到了io线程和worker线程之间的消息队列. 换句话说, 在worker卡住时, 还在运行的io线程做的可能是无用功. 事实上, 这正是上面提到的没什么影响真正的含义. 另一个问题是每个请求都要从io线程跳转至worker线程, 增加了一次上下文切换, 在机器繁忙时, 切换都有一定概率无法被及时调度, 会导致更多的延时长尾.
- 一个实际的解决方法是限制最大并发, 只要同时被处理的请求数低于worker数, 自然可以规避掉"所有worker被阻塞"的情况.
- 另一个解决方法当被阻塞的worker超过阈值时(比如8个中的6个), 就不在原地调用用户代码了, 而是扔到一个独立的线程池中运行. 这样即使用户代码全部阻塞, 也总能保留几个worker处理rpc的收发. 不过目前bthread模式并没有这个机制, 但类似的机制在打开pthread模式时已经被实现了. 那像上面提到的, 这个机制是不是在用户代码都阻塞时也在做"无用功"呢? 可能是的. 但这个机制更多是为了规避在一些极端情况下的死锁, 比如所有的用户代码都lock在一个pthread mutex上, 并且这个mutex需要在某个RPC回调中unlock, 如果所有的worker都被阻塞, 那么就没有线程来处理RPC回调了, 整个程序就死锁了. 虽然绝大部分的RPC实现都有这个潜在问题, 但实际出现频率似乎很低, 只要养成不在锁内做RPC的好习惯, 这是完全可以规避的.
7.7 bthread没有channel
channel代表的是两点间的关系，而很多现实问题是多点的，这个时候使用channel最自然的解决方案就是：有一个角色负责操作某件事情或某个资源，其他线程都通过channel向这个角色发号施令。如果我们在程序中设置N个角色，让它们各司其职，那么程序就能分类有序地运转下去。所以使用channel的潜台词就是把程序划分为不同的角色。channel固然直观，但是有代价：额外的上下文切换。做成任何事情都得等到被调用处被调度，处理，回复，调用处才能继续。这个再怎么优化，再怎么尊重cache locality，也是有明显开销的。另外一个现实是：用channel的代码也不好写。由于业务一致性的限制，一些资源往往被绑定在一起，所以一个角色很可能身兼数职，但它做一件事情时便无法做另一件事情，而事情又有优先级。各种打断、跳出、继续形成的最终代码异常复杂。
我们需要的往往是buffered channel，扮演的是队列和有序执行的作用，bthread提供了ExecutionQueue，可以完成这个目的。
![[蓝桥杯 2023 国 Python B] 划分 Java](http://pic.xiahunao.cn/[蓝桥杯 2023 国 Python B] 划分 Java)
