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

---

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在同一个锁内即可；