1. gRPC 的流式模式（unary/server streaming/client streaming/bidi）在 Java 中的线程模型与背压控制
问题
gRPC 的四种流式模式（unary、server streaming、client streaming、bidirectional streaming）在 Java 实现中的线程模型是怎样的？背压（backpressure）如何控制？
考察点
- gRPC 四种调用模式对应的 API 形态与适用场景
- Java gRPC 的线程模型（调用线程、EventLoop/执行器、流式回调）
- 背压机制：流控、OutboundFlowController、消息缓冲
答案
gRPC 定义了四种流式模式：unary（单请求单响应）、server streaming（单请求多响应）、client streaming（多请求单响应）和 bidi streaming（多请求多响应）。在 Java 中，unary 调用由调用线程发起并阻塞等待（同步 stub），或通过 ListenableFuture/CompletableFuture 异步回调；流式调用则注册 StreamObserver 回调，事件的回调在线程池/EventLoop 上执行。gRPC 的流控基于 HTTP/2 的窗口机制，OutboundFlowController 负责在发送端限制待发送字节数，避免内存暴涨；接收端通过 inflight 窗口暂停或恢复。生产环境应使用显式的 Executor 将流回调与业务线程隔离，避免阻塞默认的 EventLoop。
解析
背压的根源是"生产者快于消费者"时内存被无限积压。gRPC 用 HTTP/2 流控窗口把积压上移到协议层，配合应用层缓冲（如 StreamObserver 的队列）实现有限背压。正确理解四种模式与线程模型，才能在高吞吐流式场景避免内存溢出与线程饥饿。
示例代码
// server streaming 响应端
ServerCallStreamObserver<String> so = (ServerCallStreamObserver<String>) responseObserver;
so.setOnReadyHandler(() -> {
while (so.isReady() && !queue.isEmpty()) {
so.onNext(queue.poll());
}
});