HBase 1.4.x客户端batch get卡在AsyncProcess的waitUntilDone如何解决？

这是HBase跨大版本兼容性触发的已知问题，核心原因如下：

• HBase 1.x系列客户端和2.x系列服务端的RPC协议、响应编码、异常定义存在大量不兼容点，服务端返回的部分响应报文无法被1.4.13客户端正确解析，导致请求回调逻辑异常中断。
• 你提供的栈信息中线程卡在AsyncProcess$AsyncRequestFutureImpl.waitUntilDone方法，该方法依赖内部的AtomicLong计数器判断请求是否全部完成，当请求响应解析失败时，计数器更新逻辑不会被触发，即使TCP连接处于ESTABLISHED状态，等待线程也永远收不到完成信号，最终大量线程阻塞在TIMED_WAITING状态，耗尽业务线程池后节点完全无法处理新的HBase请求。
• 1.4.10/1.4.13版本的AsyncProcess存在未修复的边界bug：当服务端返回2.x新增的异常类型时，客户端的失败回调逻辑会直接跳过计数器更新步骤，直接触发上述永久等待问题。

• 检查HBase客户端配置，确认是否配置了明确的操作超时参数，hbase.client.operation.timeout默认值为1200000ms（20分钟），过长的超时时间会放大该问题的影响。
• 开启HBase客户端DEBUG级别日志，过滤AsyncProcess、HTable相关日志，确认卡住的请求是否有抛出未捕获的解析异常、是否存在重试次数耗尽但未触发完成回调的情况。
• 可使用Arthas等Java诊断工具，抓取阻塞线程对应的AsyncRequestFutureImpl实例，对比实例内已完成请求计数器和总请求数的数值，确认是否为计数器未更新导致的永久等待。

• 最彻底的修复方案是对齐客户端与服务端版本：将HBase客户端升级到与服务端同大版本的2.x系列，避免跨版本兼容性问题。
• 若暂时无法完成版本升级，可先做以下临时防护：
  • 调整客户端超时参数，将hbase.client.operation.timeout、hbase.client.retries.number设置为合理值（比如操作超时设为30s，重试次数设为3次），避免线程长时间阻塞。
  • 针对AsyncProcess的bug打自定义补丁，在waitUntilDone方法中增加兜底超时判断，即使计数器未更新，到达最大等待时间后也主动抛出超时异常，避免线程永久挂起。
  • 优化现有Hystrix熔断配置，将Hystrix命令的超时时间设置为短于HBase客户端操作超时，请求卡住时由熔断层主动中断，防止业务线程池被耗尽。

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