Micronaut声明式客户端偶发Read Timeout异常咨询

最常见根因：Netty连接池僵死连接复用
Micronaut声明式HTTP客户端底层基于Netty实现，默认开启TCP连接复用。如果请求链路中间存在负载均衡、防火墙、API网关这类节点，这类节点通常会配置比客户端更短的连接空闲超时，会单方面切断长时间无流量的TCP连接，而客户端侧没有感知到连接已经被半关闭，下次请求拿到这个僵死连接发送数据时，根本不会收到服务端的响应包，一直等到配置的读超时阈值就抛出异常。这个场景完全匹配你描述的特征：服务端本身处理速度快、超时随机出现在任意客户端、低概率偶发，和业务代码逻辑无关。

第二常见根因：IO线程被阻塞导致响应处理不及时
你配置的cached类型IO执行器是给Netty EventLoop线程用的，这类线程绝对不能执行阻塞逻辑。如果thenApply里的parseResponse方法存在CPU密集计算、同步IO调用、大对象序列化这类阻塞操作，会占住EventLoop线程，导致已经到达网卡的响应没法被及时读取，超时检测任务先触发就会误报读超时——这种情况不是请求没发出去或者服务端没返回，是客户端自身线程被堵，没来得及处理已收到的响应。

第三类根因：@Async线程池排队耗时占满超时窗口
你给方法加了@Async注解但没有单独配置async专用执行器的话，Micronaut默认使用的调度线程池核心线程数非常有限，请求峰值时线程被占满，新提交的任务会在队列中排队，排队时间会被算在读超时统计窗口内，排队+实际请求耗时超过5s就会触发超时，这类超时通常和流量高峰正相关。

• 先开启Netty和HTTP客户端的debug日志，添加如下配置：

logger:
  levels:
    io.netty.handler.timeout: DEBUG
    io.micronaut.http.client: DEBUG

超时发生时如果对应请求的channel日志中能看到之前收到过RST包、或者连接空闲时间超过中间节点的超时时间，即可确认是僵死连接问题。

• 给parseResponse方法添加简单的耗时统计日志，只要出现单次执行耗时超过100ms的情况，就说明IO线程存在阻塞。
• 监控打印IO执行器、async执行器的活跃线程数和队列积压长度，超时发生时如果队列存在堆积，就是线程池资源不足导致的排队超时。
• 必要时在客户端侧和服务端侧同时抓包，对比超时请求的发送时间、服务端接收时间、服务端回包时间，排除中间链路丢包的问题。

• 首先修正HTTP客户端连接池配置，主动回收空闲连接，避免拿到僵死连接：

micronaut:
  http:
    client:
      read-timeout: 5s
      pool:
        enabled: true
        max-connections: 50 # 根据实际业务并发调整
        idle-timeout: 10s # 必须配置得比链路中间所有节点的连接空闲超时短，比如网关配30s超时这里就设10s
        acquire-timeout: 3s # 连接获取超时单独配置，不要和读超时混淆
        health-check: true # 开启连接取用时的活性检测，进一步过滤僵死连接

快速验证的话可以临时把pool.max-idle-connections设为0，完全禁用连接复用，每次请求新建连接，如果改完之后超时完全消失，即可100%确认是连接复用导致的问题。

• 把响应处理链里的阻塞逻辑从IO线程挪走，将thenApply换成thenApplyAsync，指定专门的业务线程池执行parseResponse这类非IO逻辑，不要占用Netty EventLoop线程：

// 提前注入自定义的业务线程池businessExecutor
return serviceClient.get().getDataAsync(request)
        .thenApplyAsync(this::parseResponse, businessExecutor)
        .exceptionally(
                ex -> {
                    LOG.error("Failed to connect to service", ex);
                    return someDefaultMap;
                }
        );

• 给@Async注解配置专用的独立线程池，不要和IO线程池混用，避免线程资源争抢：

micronaut:
  executors:
    async:
      type: fixed
      n-threads: 20 # 根据业务异步任务并发量调整
      queue-capacity: 100
    io:
      type: cached

• 如果你当前使用的Micronaut版本低于3.8.x，建议升级到最新稳定版，旧版本存在数个已知的连接池泄漏、超时计数错误的bug，也会触发偶发读超时。

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