Kotlin客户端中GRPC Future Stub与Blocking Stub的差异探讨

虽然最终调用CompletableFuture.get()会阻塞当前线程，但Future Stub和Blocking Stub在实际使用中还是有明显区别：

• 线程利用效率不同
  Blocking Stub是直接在当前线程发起请求并一直阻塞，直到服务端返回结果——这段时间当前线程完全闲置，无法执行其他任务。
  而Future Stub是先把请求提交给gRPC的后台线程池异步处理，提交后当前线程可以立刻去执行其他工作（比如处理UI事件、发起其他请求），直到你需要结果时才调用get()阻塞等待。

• 批量请求的并行能力不同
  如果要发起多个gRPC请求，用Future Stub可以一次性把所有请求异步发出去，让它们在后台并行执行，之后再逐个调用get()获取结果；而Blocking Stub只能串行执行，一个请求处理完才能发下一个，整体耗时会高很多。

• 异常与结果处理的灵活性不同
  Future Stub依托CompletableFuture，可以用链式API提前处理结果或异常——比如用thenApply()转换返回值、exceptionally()捕获异常，不用等到调用get()时才用try-catch包裹；Blocking Stub则只能在调用的地方用try-catch处理所有异常，灵活性差不少。

• 请求取消的便捷性不同
  Future Stub可以调用CompletableFuture.cancel()随时取消还在处理的请求；而Blocking Stub发起后，当前线程已经阻塞，要取消只能通过中断线程的方式，操作麻烦还容易引发其他问题。

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