gRPC中onClose与onCancel的区别及场景触发疑问

定义的gRPC服务 #

service EventService {
  rpc Subscribe (stream Subscription) returns (stream Event) {}
}

服务端Handler实现 #

public StreamObserver<Subscription> subscribe(StreamObserver<Event> responseObserver) {
    ((ServerCallStreamObserver) responseObserver).setOnCloseHandler(() -> /* something */);
    return new StreamObserver<Subscription>() {
        @Override
        public void onNext(Subscription value) { /* something */ }
    
        @Override
        public void onError(Throwable t) { /* something */ }
    
        @Override
        public void onCompleted() { /* something */ }

        @Override
        public void onCancel() { /* something */ }
    };
}

疑问解答 #

1. onCancel回调是否必要？onComplete/onError是否总能触发？ #

• onCancel不是强制要求，但最好加上。当调用被取消（比如客户端主动取消、心跳超时、网络断连）时，onCancel会被触发，而onError和onComplete不会执行。如果只实现后两者，取消场景下的资源清理逻辑就没机会运行，很容易出现资源泄漏。
• 要是你在取消和错误场景下的清理逻辑完全一致，可以把公共逻辑抽成一个单独的方法，在onCancel和onError里都调用；onComplete则看情况——正常结束订阅时如果需要释放资源，也可以调用这个方法，不然单独处理正常结束的逻辑就行。

2. setOnCloseHandler与setOnCancelHandler的差异 #

• setOnCancelHandler：仅当调用被主动取消时触发（不管是客户端发起取消，还是服务端因超时等原因主动取消调用），触发时机早于关闭逻辑。
• setOnCloseHandler：不管调用是正常结束（onComplete）、错误结束（onError）还是被取消（onCancel），最终都会触发这个回调，是整个调用生命周期的最后一步，适合做最终的资源清理兜底。
• 仅触发其中一个的场景：
  • 仅触发setOnCancelHandler：理论上存在调用被取消但还没走到关闭阶段就触发的情况，但实际中一般都会走到onClose，只是触发顺序有先后；
  • 仅触发setOnCloseHandler：当调用正常完成（onCompleted）或者因错误结束（onError），没有触发取消逻辑时，只会触发onCloseHandler。

重点场景下的Handler触发情况 #

客户端因心跳超时关闭 #

• 服务端会触发：onCancel（客户端超时后会向服务端发送取消请求） + setOnCloseHandler（整个调用生命周期收尾）
• 不会触发onError或onCompleted

服务端因心跳超时关闭 #

• 服务端会主动取消这个调用，触发：onCancel + setOnCloseHandler
• 少数情况下如果服务端在超时后主动抛出错误，可能会触发onError，但心跳超时本质属于取消场景，通常会先走onCancel

底层TCP套接字异常或操作系统报错 #

• 这种网络异常场景下，服务端一般会触发：onError（异常会作为参数传入） + setOnCloseHandler
• 极端情况（比如套接字直接被重置且没收到错误信号）可能会触发onCancel + setOnCloseHandler，但绝大多数情况是触发onError

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