Java HttpClient长耗时请求响应后无限挂起问题排查修复

• 客户端配置存在致命缺陷：代码中HttpRequest.newBuilder(uri).timeout()未传入任何超时参数，JDK内置HttpClient默认请求无超时上限，会无限等待响应；且每次请求新建独立HttpClient实例，未开启TCP keepalive探测，无法感知半开连接状态。
• K8s网络连接跟踪表项老化：K8s节点默认conntrack（连接跟踪）表项的空闲超时为1200秒（20分钟），长请求处理期间没有任何数据包传输，刚好达到超时阈值时conntrack条目会被静默删除，此时TCP连接变成半开状态：API B返回的响应经过Nginx转发时会被网络丢弃，若连接断开的RST/FIN报文也丢失，API A侧完全收不到连接关闭通知，就会永久阻塞。
• Nginx Ingress配置不全：仅配置了应用层代理读写超时，未开启TCP keepalive探测，无法在长请求空闲期间主动发送探测包刷新conntrack表项，也无法及时感知断开的连接。
• 业务模型适配性差：单同步HTTP请求阻塞20分钟以上本身就不符合HTTP协议的常规使用场景，中间任意一跳网络设备的静默丢包、连接回收都会导致两端状态不一致。

1. 紧急修复客户端代码（最快生效） #

• 所有HTTP请求显式配置合理超时，禁止空参调用timeout方法：

  // 根据业务最大处理时长预留冗余，比如配置总超时3600秒
  var requestBuilder = HttpRequest.newBuilder(uri)
          .timeout(Duration.ofSeconds(3600))
          .POST(HttpRequest.BodyPublishers.ofString(Serializer.serialize(body)));
  

• 全局复用单例HttpClient实例，开启TCP keepalive，单独配置连接超时：

  // 应用启动时初始化一次，全局复用
  HttpClient client = HttpClient.newBuilder()
          .sslContext(context)
          .version(HttpClient.Version.HTTP_1_1)
          .connectTimeout(Duration.ofSeconds(30)) // 连接建立超时设30秒即可
          .option(StandardSocketOptions.SO_KEEPALIVE, true) // 开启操作系统级TCP keepalive探测
          .build();
  

  配置后若连接出现半开，操作系统会在多次探测失败后主动断开连接，抛出IO异常，不会无限挂起线程。

2. 补全Nginx Ingress配置 #

在现有超时配置基础上，补充TCP keepalive相关参数，主动刷新conntrack表项：

kubernetes.io/ingress.class: nginx
# 原有超时配置适当调大预留冗余
nginx.ingress.kubernetes.io/proxy-connect-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/send-timeout: "3600"
# 新增keepalive配置
nginx.ingress.kubernetes.io/proxy-socket-keepalive: "on"
nginx.ingress.kubernetes.io/proxy-tcp-keepalive-time: "600" # 空闲10分钟开始发探测包，小于20分钟的conntrack默认超时
nginx.ingress.kubernetes.io/proxy-tcp-keepalive-interval: "60"
nginx.ingress.kubernetes.io/proxy-tcp-keepalive-probes: "3"
nginx.ingress.kubernetes.io/upstream-keepalive-connections: "100"
nginx.ingress.kubernetes.io/upstream-keepalive-timeout: "3600"

3. 架构层面彻底解决 #

对于处理时长超过1分钟的接口，禁止使用同步阻塞等待模式，改为异步任务模型：

• API A调用API B的任务提交接口，API B校验参数通过后立即返回全局唯一任务ID，后台异步执行业务逻辑
• API A拿到任务ID后，按固定间隔（比如10秒）轮询任务状态接口查询结果，或者由API B处理完成后主动回调API A的通知接口
  这种模式下所有HTTP请求都是秒级以内的短请求，从根本上规避长连接被网络设备静默回收的问题，也更方便做重试、熔断、降级处理。

内容的提问来源于stack exchange，提问作者Gustavo Cesário