在Netty上运行gRPC服务时，是否应避免编写阻塞代码？

必须避免在Netty事件循环线程中执行长时间阻塞代码——这是保证gRPC服务性能和可用性的核心原则。

为什么不能阻塞Netty线程？ #

Netty的工作者事件循环组（Worker EventLoopGroup）里的线程是IO处理线程，每个线程要负责同时处理多个连接的IO事件、流水线处理器逻辑。如果你的RPC处理逻辑在这个线程上执行阻塞操作（比如同步数据库查询、慢第三方接口调用、Thread.sleep()等），会直接导致该线程被卡住，无法处理其他请求。一旦多个线程都被阻塞，整个服务会彻底失去响应，无法处理新的连接和请求。

gRPC的两种Stub模式与阻塞代码的关系 #

gRPC提供了两种调用模式，不同模式下阻塞代码的处理逻辑有区别：

• 阻塞式Stub（BlockingStub）：这种模式看起来是传统的阻塞写法，但gRPC内部会自动把阻塞的服务方法调用放到独立的业务线程池中执行，不会占用Netty的IO线程。不过要注意：如果你在服务方法里写了长时间阻塞的逻辑，依然要确保这些逻辑是在业务线程池里运行——gRPC默认会提供线程池，但建议你自定义配置合适的线程池参数（比如核心线程数、队列大小），避免默认池被耗尽。
• 异步Stub（AsyncStub/Stub）：这种模式下，回调逻辑是在Netty事件循环线程上执行的，所以绝对不能在回调里写阻塞代码，否则会直接卡住IO线程。所有耗时操作都要手动放到业务线程池处理。

正确的实践方案 #

• 所有耗时超过几毫秒的阻塞操作，都要放到独立的业务线程池执行，不要让Netty IO线程处理这些逻辑。
• 使用阻塞式Stub时，通过ServerBuilder.executor()指定自定义业务线程池，精准控制资源分配。
• 避免在gRPC服务方法或异步回调中直接执行任何阻塞操作，比如同步读取大文件、同步调用慢外部服务、无限制的循环计算等。

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