将函数调用替换为gRPC调用时是否需要保证代码线程安全？

核心判断 #

你当前无锁运行正常属于概率性巧合，是否需要加锁取决于两个前提：服务端是否存在跨请求共享的可变状态、是否要求请求处理效果严格对齐原始单线程调用的顺序逻辑。

关键逻辑说明 #

• 你对调用顺序的保证存在认知误区：单线程客户端串行发送同步gRPC请求，只能保证请求按顺序从客户端发出、按顺序送达服务端，完全不能保证服务端按顺序完成两个请求的处理。gRPC默认同步服务端采用线程池处理请求，先到的请求如果被分配到不同线程、且本身处理逻辑更耗时，完全可能后执行完成，此时第二个请求的处理就会读取到不符合预期的中间状态，和原始单线程顺序调用的逻辑不一致。
• 如果拆分出的gRPC服务是无状态的，所有请求处理逻辑不涉及任何跨请求共享的可变数据（比如所有状态都随请求参数传递、无全局/静态可变变量、无进程内共享缓存），那么完全不需要加锁，线程池并行处理也不会出现逻辑问题。
• 如果服务端存在跨请求的共享可变状态，且要求请求处理效果严格对齐原始单线程调用的表现，可选两种方案：
  • 方案一：给所有共享可变状态的访问路径加std::mutex互斥锁，保证同一时间只有一个请求能修改/读取共享状态，天然保证操作的可见性和顺序性。
  • 方案二：给该类有顺序依赖的请求指定专用的单线程执行器，强制所有相关请求在同一个线程上串行处理，无需额外加锁就能和原始单线程逻辑表现完全一致。
• 你当前未触发问题属于测试场景的巧合：通常是因为测试时请求处理耗时都很短、线程池调度刚好按请求到达顺序完成执行，一旦上线后出现慢请求、CPU调度负载升高，大概率会触发顺序错乱的问题。

内容的提问来源于stack exchange，提问作者P. Saladin