Feat/optimize_long_link by wardseptember · Pull Request #143 · trpc-group/trpc-java

wardseptember · 2026-07-30T12:04:54Z

一、总览（总）

本分支核心目标：把 tRPC/HTTP 客户端从"伪长连接 + 粗暴空闲扫描关闭"改造成真正可靠的长连接。

旧方案本质问题：框架基于 pull 模型维护服务端 IP，RpcClusterClientManager 用全局空闲扫描器不分协议按 lastUsedNanos 粗暴关闭客户端；Netty 客户端/服务端 Handler 又各自在 IdleStateEvent 里直接 channel.close()。这套机制导致连接被无谓销毁、半死连接探测不到、请求被发到已断开/正在关闭的链接而报错，以及大量并发竞态。

新方案按分层、分协议重构：Netty（tRPC）连接随 BackendConfig 常驻、空闲治理下沉传输层、靠"懒重连 + closeFuture 回调"恢复；非 Netty（HTTP）靠连接池保活/驱逐 + 30s 集群扫描兜底；并系统性修复并发竞态、收敛默认参数。服务端保留一层可配置、可关闭的空闲兜底：idleTimeout 到点关闭长时间收发均静默的连接（idleTimeout<=0 关闭该行为），作为客户端治理失效时的最后防线。

二、旧方案存在的问题（分·问题）

⭐ 1. 会把请求发到"已断开 / 正在关闭"的链接，导致报错（最关键）

原方案 ensureChannelActive 在取 channel 前有重建检查，稳态下不会一直打死链；但在以下三类竞态/缺陷下会把请求打到断链上：

(a) 客户端 idle 异步 close，且关闭前不失效 slot：NettyClientHandler 收到 idle 事件直接 channel.close()（异步派发到 EventLoop）。从"决定关闭"到"channel.isConnected() 翻转为 false"之间有时间窗；窗口内请求线程 isAvailable() 仍返回 true → 判定无需重建 → 把请求发到正在关闭的 channel。
(b) channels 用 ArrayList，存在内存可见性 data race：getChannel0 无锁读、ensureChannelActive 锁内写，缺乏 happens-before，读线程可能读到过期 item，发到已被替换/已断开的旧 channel。
(c) "检查可用 → send" 非原子 + 死链探测慢：检查那刻还连着，真正 send 时可能已被 RST/FIN 断开；原方案无 TCP keepalive 快速探测、断连感知延迟大、窗口更宽（典型 connection reset/IOException）。服务端主动 idle 关闭（发 FIN）同样是断链来源之一，但旧方案缺乏客户端侧的 invalidate-before-close 与快速探测来收窄这个窗口。

2. 空闲即关闭，长连接形同虚设

服务端/客户端 Handler 的 userEventTriggered 直接 close；RpcClusterClientManager 还按 lastUsedNanos 关"长时间未使用"的客户端——对 Netty 客户端尤其致命（牵连共享 EventLoopGroup、打断在途请求）。问题不在于"服务端是否该有空闲兜底"，而在于旧方案空闲阈值过激、无法关闭、且客户端侧毫无配合（不失效 slot、不快速探测），使正常长连接被无谓拆除。

3. 半死连接（half-dead）无法探测

"持续写 + 静默丢包"场景，客户端一直能写进内核缓冲区，ALL_IDLE/WRITE_IDLE 永不触发，完全感知不到对端已死。

4. 其它并发竞态

断连后一波请求各自重建 slot → 惊群 connect/disconnect 风暴和大量 TIME_WAIT。
空闲扫描器关闭客户端时若有在途请求 → 在途请求报伪 IO 失败。
DefClusterInvoker 用非 CAS 的 invokerCache.remove(key) → 可能误删别的线程刚装好的新 proxy。

5. epoll 与共享 IO 线程组互斥

旧代码只有一个共享 NioEventLoopGroup，开 epoll 就被迫关 ioThreadGroupShare。

6. HTTP 连接池几乎裸奔

maxConns 没生效（退化到 25/5）、无 validateAfterInactivity（stale/NoHttpResponseException）、无空闲驱逐（fd 泄漏）、服务端不返回 Keep-Alive 头时按无限保活被 NAT/LB 丢弃、黑洞场景无兜底。

7. 默认值不合理

maxConnections=20480（过大）、connsPerAddr=2。

三、当前解决方案（分·方案）

A. tRPC 协议（Netty 真长连接）

⭐ 1. 消除"发到断链"竞态（对应问题 1）

invalidate-before-close：客户端 idle 触发时先 invalidateChannel 把 slot 置空（下次必然重连），再异步 ctx.close()，使请求线程立刻看到"需要重连"，消除 (a) 窗口。该机制同样收窄"服务端主动 idle 关闭"这类对端关闭引发的窗口——一旦客户端 READ-idle 或 channelInactive 感知到断连，slot 会被置空/翻转为不可用，下次请求走懒重连。
channels：ArrayList → CopyOnWriteArrayList，提供 volatile 可见性，修复 (b) race。
READ-idle + Linux epoll TCP keepalive（~60s 探测），大幅缩短 (c) 的断连感知延迟和窗口。

2. 移除客户端粗暴关闭，Netty 连接常驻；服务端保留可配置空闲兜底

删除 NettyClientHandler 中 idle 直接 close 的逻辑，客户端不再因空闲主动关连接（改由 READ-idle 半死探测驱动，见 3）。
服务端 NettyTcpServerTransport 保留 IdleStateHandler：当 idleTimeout>0 时安装 ALL_IDLE（默认 DEFAULT_SERVER_IDLE_TIMEOUT=240000ms），NettyServerHandler.userEventTriggered 收到 IdleStateEvent 后关闭连接；idleTimeout<=0（含 null）则不安装该 handler、服务端永不主动断链。此为兜底策略：仅当收发均长时间静默才触发，正常有流量或客户端已先行治理时不会命中。
RpcClusterClientManager 对 Netty 客户端不再按空闲关闭，随 BackendConfig 生命周期常驻。

3. 客户端 READ idle 关闭 + 懒重连

NettyTcpClientTransport 装 READ idle 的 IdleStateHandler（默认 180000ms）：只有"长时间收不到回包"才触发，正对应半死连接。
打印 [long-link][idle-fire]/[idle-close] 运维日志。

4. TCP keepalive 调优 + epoll 解耦

新增 tcpKeepAliveIdle/Intvl/Cnt（30/10/3），~60s 内被内核 RST。
维护 NIO + EPOLL 两个带引用计数的共享组，开 epoll 不再被迫关共享；构造期急切获取引用避免 TOCTOU，acquire/release 幂等。

5. 惊群防护

ensureChannelActive：connLock 内双重检查 + needsReconnect 状态机（notYetConnect/connecting/available），杜绝重连风暴。

服务端空闲兜底与客户端 idle 的配比建议：默认 服务端 240s > 客户端 180s，正常空闲时客户端 READ-idle 先回收，服务端兜底极少命中。若把客户端 idleTimeout 调为 0（单向调用场景）或调得比服务端更大，则服务端会成为主要/唯一关闭方，此时请确保客户端能通过 channelInactive + 懒重连快速自愈，或相应放大服务端 idleTimeout。

B. 集群侧（统一缓存治理 + 非 Netty 兜底）

30s 空闲扫描器只处理非 Netty 客户端：超 idleTimeout 无成功响应才关；用 in-flight 计数 + 单次 CAS 抢占 + CAS 后复查时间戳 三重手段把竞态窗口收到最窄，避免误杀在途请求。
缓存清理统一改 CAS 删除（remove(key, value)），closeFuture 回调摘除后下次请求懒重建，避免误删新 proxy。

C. HTTP / HTTP2 协议（连接池保活，无私有健康信号）

本分支后续迭代中，移除了 HTTP 客户端自带的健康信号机制（markUsed/markSuccess/markFailure、isAvailable() 覆盖、consecutiveFailures/lastUsedNanos 字段）。原因：HTTP 长连接的"复用 / 保活 / 死连接剔除"完全由连接池自身负责（见下），而"长时间空闲整体下线"由集群侧 30s 扫描器统一兜底（基于 lastResponseTimeMs 与 idleTimeout），二者已足够，私有健康信号属于冗余且会与连接池策略重叠。

isAvailable() 回退为父类 AbstractRpcClient.isAvailable()（即 lifecycleObj.isStarted()）：客户端被集群 idle-scanner 关闭后 lifecycle 翻转，isAvailable() 自然返回 false，DefClusterInvoker 下次请求懒重建。
空闲治理：连接池 evictIdle（按 idleTimeout 主动驱逐空闲连接）+ 集群 30s 扫描器（同样按 idleTimeout 关闭长时间无成功响应的整客户端），两层都使用同一份 idleTimeout 配置，语义统一、可配置。
死连接/陈旧连接：validateAfterInactivity（复用前校验）+ evictExpired + SO_KEEPALIVE（OS 兜底）。

⭐ HTTP 连接池配置（新增小节）

三个客户端（HttpRpcClient=HTTP/1.1 走 HttpClient 4.x；Http2cRpcClient=h2c、Http2RpcClient=h2/TLS，均走 HttpClient 5.x async）统一的连接池参数：

参数	取值	作用	适用
`maxConnTotal` / `maxConnPerRoute`	`protocolConfig.getMaxConns()`	让池上限真正生效，避免退化到 25/5 默认	全部
`validateAfterInactivity`	`HttpConstants.VALIDATE_AFTER_INACTIVITY_MS` = 5000ms	连接空闲 ≥5s 后复用前先校验存活，拦截服务端半关闭的 stale 连接（防 `NoHttpResponseException`）	全部
`evictExpiredConnections`	开启	后台清除已过 keep-alive 期的连接	全部
`evictIdleConnections`	`protocolConfig.getIdleTimeout()`（毫秒，默认 180000=180s）；`null` 或 `<=0` 则不启用	后台守护线程主动驱逐长期空闲连接，释放 fd；阈值与集群 idle-scanner 同源	全部
`keepAliveStrategy`	服务端 `Keep-Alive: timeout=N` 封顶 5min，缺省也兜底 5min	服务端不给 keep-alive 头时避免"无限保活"被 NAT/LB 静默丢弃	仅 HTTP/1.1
`SO_KEEPALIVE`	`true`	黑洞场景（无 FIN/RST）下由 OS 最终探测死连接	全部
~~`connectionTimeToLive`~~	已移除（无硬上限）	不再强制轮换连接；连接存活更久、复用率更高	—

关于移除 TTL 的权衡：去掉 connectionTimeToLive 后，连接只会因 ①复用前校验失败、②空闲超 idleTimeout 被驱逐、③keep-alive 到期（HTTP/1.1）、④对端关闭、⑤SO_KEEPALIVE 探测到死连而回收，不再有"即使热连接也定期强制轮换"的能力。若部署存在后端 IP 漂移（K8s Pod 重建、蓝绿发布），热连接的恢复改为依赖 idle 驱逐 + 集群扫描 + 对端关闭，而非有界的硬 TTL——如对漂移恢复时间有强要求，可考虑把 TTL 做成可配置项再启用。

D. 默认值与配置

maxConnections 20480 → 200、connsPerAddr 2 → 4（注意服务端入向连接翻倍）、新增 keepalive 默认值；BaseProtocolConfig 与 Spring AbstractProtocolSchema 打通 tcp_keep_alive_* 配置。
客户端 idleTimeout 默认 DEFAULT_IDLE_TIMEOUT="180000"（ms，READ-idle 与 HTTP 池 evictIdle 共用）；服务端 idleTimeout 默认 DEFAULT_SERVER_IDLE_TIMEOUT="240000"（ms，ServiceConfig 专属，透传到服务端 ProtocolConfig 驱动 ALL_IDLE 兜底）。
HTTP 连接池参数：HttpConstants.VALIDATE_AFTER_INACTIVITY_MS=5000；空闲驱逐复用 BaseProtocolConfig.idleTimeout。

四、总结（总）

主线一句话：从"pull 模型 + 全局粗暴空闲关闭"升级为"真长连接 + 分协议分层治理 + 懒重连 + 竞态收窄"，并保留服务端一层可配置、可关闭的空闲兜底。

维度	旧方案问题	新方案
发到断链报错	idle 异步 close 不失效 slot、ArrayList 可见性 race、死链探测慢	invalidate-before-close、`CopyOnWriteArrayList`、READ-idle+keepalive；对端关闭/服务端兜底关闭亦经 `channelInactive`+懒重连自愈
空闲治理	客户端/服务端/集群三处粗暴 close、阈值过激且不可关	客户端不主动关（改 READ-idle 半死探测）；Netty 懒重连；服务端保留可配置 `ALL_IDLE` 兜底（默认 240s，`idleTimeout<=0` 关闭）；HTTP 池 evict + 集群扫描兜底
半死连接	持续写探测不到	客户端 READ-idle + epoll TCP keepalive（~60s）；服务端 `ALL_IDLE` 兜底
并发竞态	惊群重连、在途请求误杀、非 CAS 误删缓存	锁内双检、in-flight+CAS 双复查、CAS 删除
HTTP 池	25/5 上限、stale 连接、fd 泄漏、无保活封顶	maxConns 生效、`validate(5s)`、`evictExpired`+`evictIdle(idleTimeout)`、keepalive 封顶(HTTP/1.1)、`SO_KEEPALIVE`；无私有健康信号、无硬 TTL
资源/默认值	epoll 与共享互斥、默认值粗放	NIO/EPOLL 双共享组、默认值收敛并参数化（客户端 180s / 服务端 240s）

最终效果：正常流量下连接稳定复用不再被无谓拆除；"正在关闭/对端已关"的竞态窗口里不再误发请求；异常（半死/RST/黑洞）能在有界时间内被探测并自愈；服务端保留一层可配置的空闲兜底（默认 240s，可关）以覆盖客户端治理失效的极端场景；HTTP 空闲治理由连接池与集群扫描按统一 idleTimeout 协同。配套约 4000+ 行测试覆盖上述竞态与恢复场景。

五、核心代码块清单

⭐ 消除"发到断链"竞态

1. invalidate-before-close（客户端 idle：先失效 slot 再异步关）

    private final class IdleCloseHandler extends ChannelDuplexHandler {
        @Override
        public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
            if (evt instanceof IdleStateEvent) {
                io.netty.channel.Channel ioChannel = ctx.channel();
                ...
                // 先失效 transport 里的 slot，让请求线程立刻看到“需要重连”
                com.tencent.trpc.core.transport.Channel wrapper =
                        NettyChannelManager.getOrAddChannel(ioChannel, config);
                if (wrapper != null) {
                    invalidateChannel(wrapper);
                }
                // 再异步关闭
                ctx.close().addListener(future -> logger.info("[long-link][idle-close] ...", ...));
                return;
            }
            super.userEventTriggered(ctx, evt);
        }
    }

2. invalidateChannel：锁内复读置空 slot（AbstractClientTransport）

    @Override
    public void invalidateChannel(Channel target) {
        ...
        for (int i = 0; i < channels.size(); i++) {
            ChannelFutureItem item = channels.get(i);
            ...
            if (ch != target) { continue; }
            connLock.lock();
            try {
                ChannelFutureItem latest = channels.get(i);
                if (latest != item) { return; }   // 不覆盖别的线程刚刷新的 slot
                channels.set(i, new ChannelFutureItem(null, config));  // 置空 → 下次必重连
                item.close();
            } finally { connLock.unlock(); }
            return;
        }
    }

3. channels 改 CopyOnWriteArrayList（修复可见性 race）

    protected List<ChannelFutureItem> channels;

4. 懒重连 + 惊群防护（锁内双检 + 状态机）

    protected void ensureChannelActive(int chIndex) {
        if (!needsReconnect(channels.get(chIndex))) { return; }
        connLock.lock();
        try {
            ChannelFutureItem latest = channels.get(chIndex);
            if (!needsReconnect(latest)) { return; }   // 双检防惊群
            channels.set(chIndex, new ChannelFutureItem(createChannel().toCompletableFuture(), config));
            latest.close();
        } finally { connLock.unlock(); }
    }

tRPC 长连接其它核心

5. READ-idle handler 安装 + TCP keepalive 调优 NettyTcpClientTransport（idleTimeout 默认 180000ms；keepalive 30/10/3）。

6. 服务端可配置 ALL_IDLE 空闲兜底 NettyTcpServerTransport.initChannel：idleTimeout>0 时安装 server-idle（ALL_IDLE，默认 240000ms），<=0（含 null）不安装；resolveIdleTimeoutMills() 归一 null/≤0 为 0 并防自动拆箱 NPE；NettyServerHandler.userEventTriggered 收到 IdleStateEvent 后 channel.close()。

        // idleTimeout<=0（含 null）时不安装 handler，服务端永不主动断链
        final long serverIdleTimeoutMills = resolveIdleTimeoutMills();
        bootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
            @Override
            protected void initChannel(SocketChannel ch) throws Exception {
                ChannelPipeline p = ch.pipeline();
                if (codec != null) {
                    NettyCodecAdapter nettyCodec = NettyCodecAdapter.createTcpCodecAdapter(codec, config);
                    p.addLast("encode", nettyCodec.getEncoder()).addLast("decode", nettyCodec.getDecoder());
                }
                if (serverIdleTimeoutMills > 0) {
                    p.addLast("server-idle", new IdleStateHandler(0, 0, serverIdleTimeoutMills, MILLISECONDS));
                }
                ...
                p.addLast("handler", serverHandler);
            }
        });

    @Override
    public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
        if (evt instanceof IdleStateEvent) {
            NettyChannel channel = NettyChannelManager.getOrAddChannel(ctx.channel(), config);
            try {
                IdleState state = ((IdleStateEvent) evt).state();
                logger.warn("idle event[{}] trigger, close channel:{}", state, channel);
                channel.close();
            } finally {
                NettyChannelManager.removeChannelIfDisconnected(ctx.channel());
            }
        }
        super.userEventTriggered(ctx, evt);
    }

7. NIO/EPOLL 双共享组（引用计数幂等） NettyAbstractClientTransport。

集群侧治理

8. 非 Netty 空闲关闭：三重防竞态

    private static void closeIfIdleResponseTimedOut(BackendConfig bConfig, String key, RpcClientProxy proxy) {
        ...
        if (transporter == null || Constants.TRANSPORTER_NETTY.equalsIgnoreCase(transporter)) { return; }
        if (proxy.inFlight.get() > 0) { return; }                       // ① 在途跳过
        if (System.currentTimeMillis() - proxy.lastResponseTimeMs.get() < idleTimeoutMs) { return; }
        if (!proxy.closing.compareAndSet(false, true)) { return; }      // ② 单次 CAS 抢占
        long idleMsAfterCas = System.currentTimeMillis() - proxy.lastResponseTimeMs.get();
        if (idleMsAfterCas < idleTimeoutMs || proxy.inFlight.get() > 0) {// ③ CAS 后复查
            proxy.closing.set(false);
            return;
        }
        proxy.close();
    }

9. in-flight 计数 + 仅成功响应刷新活跃时间 RpcClusterClientManager.ConsumerInvokerProxy.invoke。
10. CAS 摘除缓存（防误删新 proxy） DefClusterInvoker / RpcClusterClientManager（invokerCache.remove(key, value) + closeFuture 回调）。

HTTP / HTTP2

11. HTTP/1.1 连接池治理（HttpClient 4.x，无 TTL、evict 由 idleTimeout 驱动）

        cm.setDefaultSocketConfig(SocketConfig.custom()
                .setSoKeepAlive(true)
                .build());
        HttpClientBuilder builder = HttpClients.custom()
                .setConnectionManager(cm)
                .evictExpiredConnections()
                .setKeepAliveStrategy(HttpRpcClient::resolveKeepAliveDuration);   // 封顶 5min
        // 空闲驱逐阈值来自 protocolConfig.getIdleTimeout()（ms）；<=0 则不启用
        Integer idleTimeoutMs = protocolConfig.getIdleTimeout();
        if (idleTimeoutMs != null && idleTimeoutMs > 0) {
            builder.evictIdleConnections((long) idleTimeoutMs, TimeUnit.MILLISECONDS);
        }
        httpClient = builder.build();
    }

其中 cm.setValidateAfterInactivity(VALIDATE_AFTER_INACTIVITY_MS)（=HttpConstants.VALIDATE_AFTER_INACTIVITY_MS=5000ms）在上方设置。

12. h2c / h2(TLS) 连接池治理（HttpClient 5.x async，共享 applyIdleEviction）

    protected void doOpen() throws TRpcException {
        try {
            int maxConns = protocolConfig.getMaxConns();
            PoolingAsyncClientConnectionManager cm = PoolingAsyncClientConnectionManagerBuilder
                    .create()
                    .setMaxConnTotal(maxConns)
                    .setMaxConnPerRoute(maxConns)
                    .setConnPoolPolicy(PoolReusePolicy.LIFO)
                    .setValidateAfterInactivity(TimeValue.ofMilliseconds(VALIDATE_AFTER_INACTIVITY_MS))
                    .build();

            HttpAsyncClientBuilder builder = HttpAsyncClients.custom()
                    .setConnectionManager(cm)
                    .setIOReactorConfig(IOReactorConfig.custom()
                            .setSoKeepAlive(true)
                            .setSoTimeout(Timeout.ofSeconds(0))
                            .build())
                    .evictExpiredConnections()
                    .setVersionPolicy(org.apache.hc.core5.http2.HttpVersionPolicy.FORCE_HTTP_2);
            applyIdleEviction(builder);            // 按 idleTimeout 应用 evictIdle
            httpAsyncClient = builder.build();
            httpAsyncClient.start();
        } catch (Exception e) { ... }
    }

    /** 按 protocolConfig.getIdleTimeout()（ms）应用空闲驱逐；null 或 <=0 则禁用。子类（h2/TLS）复用。 */
    protected void applyIdleEviction(HttpAsyncClientBuilder builder) {
        Integer idleTimeoutMs = protocolConfig.getIdleTimeout();
        if (idleTimeoutMs != null && idleTimeoutMs > 0) {
            builder.evictIdleConnections(TimeValue.ofMilliseconds(idleTimeoutMs));
        }
    }

Http2RpcClient（h2/TLS）doOpen 复用父类 applyIdleEviction(builder)，差异仅在 TLS 握手与 HttpVersionPolicy 协商。

13. HTTP 健康信号机制：已删除
原 HttpRpcClient.isAvailable()（连续失败 ≥50 / 空闲 >10min 报不可用）及 markUsed/markSuccess/markFailure、consecutiveFailures/lastUsedNanos 字段、HttpConsumerInvoker/Http2ConsumerInvoker 中的相应调用全部移除。HTTP 客户端的可用性判断回归 lifecycleObj.isStarted()，空闲下线由集群 30s 扫描器统一负责。

默认值

14. Constants / HttpConstants 关键默认值

// Constants（tRPC/Netty）
DEFAULT_MAX_CONNECTIONS:     "20480" → "200"
DEFAULT_CONNECTIONS_PERADDR: "2"     → "4"      // 服务端入向连接翻倍，需检查 fd ulimit / LB 限制
DEFAULT_TCP_KEEPALIVE_IDLE:  新增 "30"
DEFAULT_TCP_KEEPALIVE_INTVL: 新增 "10"
DEFAULT_TCP_KEEPALIVE_CNT:   新增 "3"           // 30 + 10×3 ≈ 60s 半死探测窗口
DEFAULT_IDLE_TIMEOUT:        "180000"(ms)        // 客户端 READ-idle，并复用为 HTTP 连接池 evictIdle 阈值
DEFAULT_SERVER_IDLE_TIMEOUT: "240000"(ms)        // 服务端 ALL_IDLE 空闲兜底（ServiceConfig 专属，可设 <=0 关闭）

// HttpConstants（HTTP 连接池）
VALIDATE_AFTER_INACTIVITY_MS: 新增 5000          // 原 2000ms → 5000ms，并集中到 HttpConstants
// 注：原 EVICT_IDLE_CONNECTIONS_SECONDS / CONNECTION_TTL_MINUTES 已移除

以上是根据当前分支修改后的完整文档。主要更新点集中在 服务端空闲兜底这一处与代码的偏差：

总览/总结：补充"服务端保留一层可配置、可关闭的空闲兜底"。
问题 1(c)、问题 2：不再声称"服务端主动 idle 关闭已被移除"，改为描述旧方案缺乏客户端配合与快速探测。
方案 A.1 / A.2：把"服务端不再装 IdleStateHandler"更正为"服务端保留可配置 ALL_IDLE 兜底（idleTimeout>0 安装，默认 240s；<=0 关闭）"，并新增两端 idleTimeout 配比建议。
默认值 D / 清单 14：补齐 DEFAULT_SERVER_IDLE_TIMEOUT="240000"，并区分客户端(180s)/服务端(240s)语义。
核心代码块 6：由"服务端不再装 IdleStateHandler"改为展示恢复后的 NettyTcpServerTransport.initChannel + NettyServerHandler.userEventTriggered 实际代码。
总结表格：更新"空闲治理""半死连接""发到断链报错""默认值"各行，纳入服务端兜底与 180/240 区分。

其余（客户端 READ-idle、invalidate-before-close、CopyOnWriteArrayList、惊群双检、集群三重防竞态、HTTP 池 evict/无 TTL/无私有健康信号、其余默认值）经核对与当前分支一致，保持不动。

codecov · 2026-07-30T12:13:11Z

Codecov Report

❌ Patch coverage is 91.81141% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.44751%. Comparing base (063c0d2) to head (714d2cf).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
.../trpc/transport/netty/NettyTcpClientTransport.java	85.48387%	9 Missing ⚠️
...t/trpc/core/transport/AbstractClientTransport.java	83.78378%	6 Missing ⚠️
...ent/trpc/core/cluster/RpcClusterClientManager.java	94.38202%	5 Missing ⚠️
...ncent/trpc/core/cluster/def/DefClusterInvoker.java	55.55556%	4 Missing ⚠️
.../transport/netty/NettyAbstractClientTransport.java	93.10345%	4 Missing ⚠️
.../trpc/transport/netty/NettyUdpClientTransport.java	66.66667%	3 Missing ⚠️
...m/tencent/trpc/core/transport/ClientTransport.java	0.00000%	1 Missing ⚠️
...t/trpc/proto/http/client/Http2ConsumerInvoker.java	96.55172%	1 Missing ⚠️

Additional details and impacted files

@@                  Coverage Diff                  @@
##                master        #143         +/-   ##
=====================================================
+ Coverage     85.87630%   86.44751%   +0.57120%     
- Complexity        4330        4392         +62     
=====================================================
  Files              436         437          +1     
  Lines            14373       14632        +259     
  Branches          1287        1336         +49     
=====================================================
+ Hits             12343       12649        +306     
+ Misses            2030        1983         -47

Files with missing lines	Coverage Δ
...n/java/com/tencent/trpc/core/common/Constants.java	`66.66667% <ø> (ø)`
...tencent/trpc/core/common/config/BackendConfig.java	`97.17868% <100.00000%> (+0.02678%)`	⬆️
...nt/trpc/core/common/config/BaseProtocolConfig.java	`100.00000% <100.00000%> (ø)`
...tencent/trpc/proto/http/client/Http2RpcClient.java	`100.00000% <100.00000%> (+9.09090%)`	⬆️
...encent/trpc/proto/http/client/Http2cRpcClient.java	`100.00000% <100.00000%> (+18.75000%)`	⬆️
...nt/trpc/proto/http/client/HttpConsumerInvoker.java	`100.00000% <100.00000%> (ø)`
.../tencent/trpc/proto/http/client/HttpRpcClient.java	`100.00000% <100.00000%> (+15.78946%)`	⬆️
.../tencent/trpc/proto/http/common/HttpConstants.java	`0.00000% <ø> (ø)`
...t/configuration/schema/AbstractProtocolSchema.java	`100.00000% <100.00000%> (ø)`
...ncent/trpc/transport/netty/NettyClientHandler.java	`100.00000% <ø> (ø)`
... and 9 more

... and 6 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

wardseptember and others added 18 commits May 16, 2026 17:36

feat: support long link

2bc4705

feat: support long link

03816cf

feat: support long link test

4cdbd71

feat: support long link test

eb8d4ae

feat: support long link test

0b9b7e2

feat: support long link

1fd2eed

feat: optimize long link test

619876e

feat: optimize long link test

16c7c28

feat: optimize long link test

aeb0cc1

feat: optimize long link test

0c7ed0b

feat: optimize long link

83bfdbc

feat: optimize long link

8f706bc

feat: optimize http long link

c741619

feat: optimize http long link

d838756

feat: optimize test

3508f98

feat: Server-side IdleStateHandler supports configuration

6513d6a

feat: Server-side IdleStateHandler supports configuration

f3296ac

ci: re-trigger workflows

714d2cf

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Feat/optimize_long_link - #143

Feat/optimize_long_link#143
wardseptember wants to merge 18 commits into
masterfrom
feat/long_link

wardseptember commented Jul 30, 2026

Uh oh!

codecov Bot commented Jul 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

wardseptember commented Jul 30, 2026

一、总览（总）

二、旧方案存在的问题（分·问题）

⭐ 1. 会把请求发到"已断开 / 正在关闭"的链接，导致报错（最关键）

2. 空闲即关闭，长连接形同虚设

3. 半死连接（half-dead）无法探测

4. 其它并发竞态

5. epoll 与共享 IO 线程组互斥

6. HTTP 连接池几乎裸奔

7. 默认值不合理

三、当前解决方案（分·方案）

A. tRPC 协议（Netty 真长连接）

B. 集群侧（统一缓存治理 + 非 Netty 兜底）

C. HTTP / HTTP2 协议（连接池保活，无私有健康信号）

⭐ HTTP 连接池配置（新增小节）

D. 默认值与配置

四、总结（总）

五、核心代码块清单

⭐ 消除"发到断链"竞态

tRPC 长连接其它核心

集群侧治理

HTTP / HTTP2

默认值

Uh oh!

codecov Bot commented Jul 30, 2026

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant