所谓困难，则是激发个人抵制困难的机会，激发新能力的机会；

—

Java的gRPC没有没有Timeout机制，不过在其中增加了Deadline机制；但使用时容易出错，以下为我踩的几个坑；

引入gRPC超时机制的原因是因为其他服务请求gRPC所在服务，若gRPC一直执行不完，会导致任务堆积；

创建后持续报错：

io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: ClientCall started after deadline exceeded: -175.597476157s from now
这种超时时间特别长；观察我的实现是在init时添加了deadline，那么从init时就开始计时了，而当真正开始执行前，就已经超时了，因此导致了超时
于是进行了修改，修改为当开始执行的时候开始设置超时时间；
 
进行过上述修改后，依然会报错，但超时的时间缩短了，在日志中会出现io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: ClientCall started after deadline exceeded: -0.013832392s from now
但是添加StopWatch，真实操作时间并没有超时，这个问题是比较诡异的，尝试为设置时间和进行请求的过程加了一个锁，发现问题居然解决了；仔细看了代码，发现了问题所在，gRPC提供的deadline机制是非线程安全的；出现超时的原因也就呼之欲出了。、。。
 
展示代码：
初始化：
@PostConstruct
private void init() {
  tesseractServiceBlockingStub = initAuthGRCTesseractStub(tesseractGrpcUrl,
          tesseractToken);
}

////////
public TesseractServiceGrpc
        .TesseractServiceBlockingStub initAuthGRCTesseractStub(String url, String token) {
  log.info("oAuth GRPC Init url:{},interiorToken:{}", url, token);
  // 构建channel 单例
  ManagedChannel channel = genChannel(url);
  Metadata extraHeaders = genMetadata(token);
  TesseractServiceGrpc.TesseractServiceBlockingStub simpleStub = TesseractServiceGrpc
          .newBlockingStub(channel)
          .withInterceptors();
  TesseractServiceGrpc.TesseractServiceBlockingStub stub = MetadataUtils
          .attachHeaders(simpleStub, extraHeaders);
  log.info("Tesseract oAuth GRPC Init success");
  return stub;
}

注意：在初始化时不要设置超时时间

调用：（在调用时设置超时时间）

UserInfo userInfo;
synchronized(this.class){
   userInfo = stub
        .withDeadlineAfter(AUTH_MAX_TIMEOUT, TimeUnit.MICROSECONDS)
    .getUserInfo(token);
}

当然直接用synchronized不太优雅，同学们可以自行使用自认为更优雅的锁，只要保证在设置超时与进行gRPC在同一个锁内即可；

版权声明：本文为xiao1xuesheng原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/kongqueting/p/16414744.html