仅做个人备份，浏览请看原文
目录
概括
三者都实现了一套称为 用户态线程或协程(coroutine) 的线程模型（主要使用M：N的用户态线程模型），只不过他们的实现方式不一样：
（1）grpc-go 基于 go语言原生的gmp模型（#### 进程、线程、gorouter、go的GMP模型 ####_wangfy_的博客-CSDN博客）
（2）grpc-java 基于 netty的线程模型
（3）brpc-cpp 基于 brpc-cpp自己写的一套线程模型
原文要点
线程模型解决的问题，是如何高效的利用多个物理核，进行工作任务的调度，使得系统能够有更高有效的吞吐，更加低的延迟。而不是把时间花在大量的比如系统层面的工作：比如context-switch（PS：实际contextSwitch的时间），cache的同步、线程等待等contention上面）
线程模型这块当前典型的线程模型有几大类
- 连接独占模型：也就是一个连接进来请求后，独占一个线程（进程）进行处理。（无论其中中间在做什么事情，比如调用第三方的服务，等待过程中也是独占着整个线程），比如传统的tomcat servlet就是这么干的。
- 单线程Reactor模型：使用单个线程处理所有连接上的请求，使用epoll-wait 方式，实现事件多路复用机制。典型比如Redis，适用于简单比如小数据的内存数据的获取。每一个回调逻辑都比较简单。（缺点就是：某个回调卡住，真个Reactor 反应堆就block了）
- 多线程Reactor模型: 单线程Reactor不能利用多线程Reactor的优势，所以当前大多数RPC/反向代理的框架大多数都是按照这个来玩的。也就是多个线程/进程Accept同一个连接上的请求（如何更好的处理惊群问题参考见 Nginx）。
但是这种固定线程数的模型中，都需要避免一个问题，就是避免在如上回调逻辑中调用block的逻辑否则一个事件处理Block，就是将整个线程反应堆都给Block了。比如Nginx针对磁盘IO推出多线程支持，在Nginx中磁盘IO层面的请求，不直接inplace在对应的反应堆中进行，而是将磁盘IO的阶段委派给专门的单独的线程池进行。（比如Proxy_temp_file从后端拉数据缓存在本地磁盘消费的场景 ）
总结来说连接独占模型，主要依赖多开线程的方式来提供服务端的吞吐。但是多开线程势必带来的问题就是系统层面的开销比较大（contex-switch、cache-bounding等等），对于高性能场景典型就不太适用。
而从编程模式上，异步的编程模式总归来说是非常复杂的，比如1个请求需要请求N个模块完成的情况下，如果使用异步模式，那简直就是太不直观，写出正确逻辑的代价会非常大，测试也非常困难。
作为专门领域的实现使用Reactor模式没有太大的问题。但是如果是在RPC场景下，对接RPC后端的是复杂的业务逻辑情况下，要基于Reactor来玩真的就太难了，从业务层面最希望的就是同步方式的编程模型。所以从实现通用的RPC框架层面来说，基于这样的线程模型的同时，再上层提供简洁的并发编程组件，就显得格外重要。
那从实现层面，就需要在block（比如网络调用）的情况下，保留当前task执行的上线文(栈、寄存器、signal等)，然后切换到别的可以执行的task上。在task具备执行条件的时候将当前执行线程的context替换为为对应的task中保存的上下文，从而实现执行逻辑的切换。（PS：除了网络，其他block的系统调用，如磁盘IO（依赖中断机制），用户态线程当前看是无能为力的，直接卡pthread，所以当前高性能的nvme磁盘肯定会向异步接口发展，比如内核现在提供的iouring方式的新接口体系）
这种实现模式一般来说称为用户态线程、协程（coroutine），
这个方面实现最彻底的是golang语言，直接在语言runtime层面把这个问题搞定。brpc框架则设计了bthread和相关的组件来实现。从调度模式来看，用户态线程主要分几大类
- N：1用户态线程库模型: N个用户态下线程对应1个native 的thread，如腾讯开源的libco等。
- M：N 用户态线程库模型：典型如go语言的goroutine、brpc的 bthread、开源实现libgo。并且支持work-steal的调度模型来避免长尾效应。
6536
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
