Netty 4.2.x 源码深度解析 (十九)：ChannelPool 连接池 —— 连接复用与资源管理

在高并发客户端场景下，频繁创建与销毁 TCP 连接是一笔不菲的开销：每次建立连接都要经历三次握手与资源分配，关闭连接又要经历四次挥手与资源回收，而 Channel 从构造、注册到绑定 EventLoop 的整套初始化流程同样代价高昂。Netty 为此提供了连接池 ChannelPool 抽象，把已经建立好的连接缓存起来反复复用，从而把"建连"这个重操作从请求的关键路径中剥离出去。围绕它，Netty 设计了无界的基础实现 SimpleChannelPool，在其上叠加了 FixedChannelPool 的并发限流与获取超时，再通过 ChannelPoolMap 按远端地址路由组织，最终形成"获取、归还、健康检查、限流、路由"五位一体的连接复用体系。

围绕连接池的获取、归还、健康检查、限流与多后端路由五个维度，以下几个问题将贯穿本文的源码分析主线：

• ChannelPool 为何要设计成继承 Closeable 的极简接口，acquire() 返回 Future<Channel>、release() 返回 Future<Void> 的异步签名背后有哪些约定与考量？
• SimpleChannelPool 如何通过并发双端队列 deque 管理空闲连接，LIFO/FIFO 两种复用顺序如何影响连接复用效率？
• SimpleChannelPool 的 acquire() 在池内无可用连接时，如何通过 Bootstrap.clone() 与 connectChannel() 创建新连接，POOL_KEY 属性又如何标记 Channel 的归属？
• 健康检查 ChannelHealthChecker 如何在获取与归还两个时机拦截失效连接，不健康连接又如何在 acquireHealthyFromPoolOrNew 中递归重建？
• FixedChannelPool 如何用 acquiredChannelCount 与 maxConnections 实现并发上限，pendingAcquireQueue 与 maxPendingAcquires 如何承载等待请求，AcquireTimeoutAction 的 NEW/FAIL 又分别对应怎样的超时策略？

本文将沿着 ChannelPool 从获取到归还的完整生命周期，先剖析连接池的接口抽象与回调体系，再深入 SimpleChannelPool 的基础实现与健康检查机制，随后剖析 FixedChannelPool 的并发限流与超时控制，最后分析 ChannelPoolMap 的多后端路由能力。

一、连接池的设计动机与 ChannelPool 接口抽象

1.1 连接频建的开销与连接池的定位

在理解 ChannelPool 的源码之前，我们先要回答一个更根本的问题：为什么需要连接池？答案是连接本身的创建与销毁并不廉价。

一方面，从操作系统层面看，一条 TCP 连接的建立需要经历完整的三次握手，关闭则需要四次挥手，其间涉及内核协议栈的状态机切换与资源分配；在高并发的短连接场景下，握手与挥手的往返时延会直接摊薄在每一次请求上。另一方面，从 Netty 框架层面看，Channel 从 new 出来那一刻起，还要经历构造、注册 EventLoop、绑定 Pipeline、激活等一系列初始化动作，这些动作涉及对象分配与事件传播，同样是一笔不可忽视的固定开销。

连接池要做的就是把这笔开销从"每次请求都要付"变成"复用一次几乎不付"：提前建立一批连接放到池子里，请求来了直接复用，用完了再归还。Netty 把这一思想抽象成 io.netty.channel.pool 包下的一组接口与实现，其核心就是 ChannelPool 接口。

1.2 ChannelPool 接口：五个方法的极简抽象

ChannelPool 是这套体系的最顶层抽象，它的声明极其克制，仅继承 Closeable 并定义了五个方法：

io.netty.channel.pool.ChannelPool

public interface ChannelPool extends Closeable {

    Future<Channel> acquire();

    Future<Channel> acquire(Promise<Channel> promise);

    Future<Void> release(Channel channel);

    Future<Void> release(Channel channel, Promise<Void> promise);

    @Override
    void close();
}

这五个方法可以按"获取、归还、关闭"三个动作划分为三组：acquire() 负责从池中获取一个可用的 Channel，返回 Future<Channel>；release() 负责把 Channel 归还到池中，返回 Future<Void>；close() 负责关闭整个连接池并释放其中缓存的连接。

尤其需要注意的是，acquire 与 release 各有两个重载：无参版本与带 Promise 版本。有无 Promise 的区别在于，无参版本由连接池内部去创建一个 Promise，有参版本则由调用方传入自定义的 Promise。这条设计贯穿了整个 ChannelPool 家族，我们在后文会看到 SimpleChannelPool 的无参 acquire() 内部调用 bootstrap.config().group().next().newPromise() 创建 Promise，而无参 release() 内部调用 channel.eventLoop().newPromise() 创建 Promise，两条路径最终殊途同归。

异步签名的背后是一层重要的设计考量：无论是建连还是归还，都可能涉及 IO 线程切换与网络往返，这些操作都不应当在调用线程上阻塞。因此 acquire 与 release 统一返回 Future，成功与失败都通过 Future 异步通知，调用方只需注册监听器即可。

接口注释里还有一条必须牢记的约定：被 acquire 出去的 Channel 必须被 release 回池，即使这个 Channel 被显式关闭了也要归还 ；而当 release 失败时，该 Channel 会被自动关闭。这条约定是防止连接泄漏的基石，也是后面 SimpleChannelPool 中 POOL_KEY 归属校验出现的直接原因。

下图展示了整个 ChannelPool 家族的层级关系与职责划分：

可以看到，这套体系分为两条继承线：一条是 ChannelPool → SimpleChannelPool → FixedChannelPool 的"单池"线，另一条是 ChannelPoolMap → AbstractChannelPoolMap 的"多池路由"线。前者解决"一个池怎么复用连接"，后者解决"多个池怎么按地址组织"。

二、ChannelPoolHandler 与 ChannelHealthChecker：回调与健康检查

2.1 ChannelPoolHandler：连接生命周期的回调钩子

连接池在复用连接的过程中，需要在三个关键时刻通知业务方："连接刚创建""连接被拿走""连接还回来了"。这三个时刻分别对应 ChannelPoolHandler 接口的三个回调方法：

io.netty.channel.pool.ChannelPoolHandler

public interface ChannelPoolHandler {

    void channelReleased(Channel ch) throws Exception;

    void channelAcquired(Channel ch) throws Exception;

    void channelCreated(Channel ch) throws Exception;
}

三个方法的职责泾渭分明：channelCreated 在一条新连接被 SimpleChannelPool 创建时触发，通常用于初始化该连接专属的 Pipeline 处理器；channelAcquired 在连接被某个请求获取时触发；channelReleased 在连接被归还时触发。这三个回调全部由 Channel 所属的 EventLoop 线程调用，业务方无需担心并发安全问题。

如果业务只需要其中的一两个回调，不必每次都实现完整的三个方法，Netty 提供了骨架抽象类 AbstractChannelPoolHandler：

io.netty.channel.pool.AbstractChannelPoolHandler

public abstract class AbstractChannelPoolHandler implements ChannelPoolHandler {

    @Override
    public void channelAcquired(Channel ch) throws Exception {
        // NOOP
    }

    @Override
    public void channelReleased(Channel ch) throws Exception {
        // NOOP
    }
}

AbstractChannelPoolHandler 把 channelAcquired 与 channelReleased 做成了空实现，只保留 channelCreated 抽象，子类按需覆写即可。这个骨架的作用是减少样板代码，让"连接池初始化 Pipeline"这一最常见诉求只需要写一个方法。

2.2 ChannelHealthChecker：连接可用性的判定关卡

一个连接从池子里拿出来时，它可能已经"死了"，对端断开了连接，或者连接在缓存期间被异常关闭。如果直接把这种连接交给业务使用，就会在写入时才发现失败。因此连接池需要一个健康检查机制，这就是 ChannelHealthChecker：

io.netty.channel.pool.ChannelHealthChecker

public interface ChannelHealthChecker {

    ChannelHealthChecker ACTIVE = new ChannelHealthChecker() {
        @Override
        public Future<Boolean> isHealthy(Channel channel) {
            EventLoop loop = channel.eventLoop();
            return channel.isActive()? loop.newSucceededFuture(Boolean.TRUE) : loop.newSucceededFuture(Boolean.FALSE);
        }
    };

    Future<Boolean> isHealthy(Channel channel);
}

ChannelHealthChecker 只有一个方法 isHealthy(Channel)，它返回 Future<Boolean> 而非直接的布尔值。这个异步设计的用意在于：健康检查不必是同步的，用户可以自定义基于心跳探测、PING-PONG 协议等需要异步往返的检查逻辑，检查完成后通过 Future 通知结果。

接口中最重要的是内置的单例 ACTIVE，它是 SimpleChannelPool 默认使用的健康检查实现。ACTIVE 的判定极度朴素：只要 channel.isActive() 返回 true，就认为连接健康。所谓"健康即可复用"，在默认实现里就等同于"连接仍然活跃"。isActive() 的判断已经涵盖了连接是否打开、是否已连接（或已绑定）等基础状态，足以拦住大部分失效连接。

值得注意的是 ACTIVE 返回 Future 的方式：它使用 channel.eventLoop() 创建一个已经完成的 Future（newSucceededFuture），而不是新建一个异步任务。因为 isActive() 本身是同步的、无阻塞的，用已完成 Future 包装可以让后续的 f.isDone() 判断直接走同步分支，减少一次不必要的线程切换。

三、SimpleChannelPool：连接池的基础实现

3.1 内部组件与 POOL_KEY 归属标记

SimpleChannelPool 是 ChannelPool 的基础实现，它实现了完整的获取与归还逻辑，但不限制最大并发连接数。它的类声明与核心字段如下：

io.netty.channel.pool.SimpleChannelPool

public class SimpleChannelPool implements ChannelPool {

    private static final AttributeKey<SimpleChannelPool> POOL_KEY =
        AttributeKey.newInstance("io.netty.channel.pool.SimpleChannelPool");

    private final Deque<Channel> deque = PlatformDependent.newConcurrentDeque();
    private final ChannelPoolHandler handler;
    private final ChannelHealthChecker healthCheck;
    private final Bootstrap bootstrap;
    private final boolean releaseHealthCheck;
    private final boolean lastRecentUsed;
}

逐一看这些字段的职责：

• deque：一个并发双端队列，通过 PlatformDependent.newConcurrentDeque() 创建，用来存放空闲的连接。之所以用双端队列，是为了同时支持 LIFO 与 FIFO 两种复用顺序。
• POOL_KEY：一个 AttributeKey，用来在 Channel 的 AttributeMap 上打标记，记录"这个连接属于哪个池"。它是归还时校验连接归属、防止误归还的关键凭据。
• handler：连接生命周期回调，即第二节的 ChannelPoolHandler。
• healthCheck：健康检查器，即第二节的 ChannelHealthChecker。
• bootstrap：建连模板，存储了连接目标地址、选项、处理器工厂等配置。
• releaseHealthCheck：控制"归还时是否做健康检查"的开关。
• lastRecentUsed：控制 LIFO/FIFO 的开关，默认 true 表示 LIFO（最近使用优先）。

SimpleChannelPool 对外提供了四个重载构造器，最终都会收敛到下面这个全参构造器：

io.netty.channel.pool.SimpleChannelPool

public SimpleChannelPool(Bootstrap bootstrap, final ChannelPoolHandler handler, ChannelHealthChecker healthCheck,
                         boolean releaseHealthCheck, boolean lastRecentUsed) {
    this.handler = checkNotNull(handler, "handler");
    this.healthCheck = checkNotNull(healthCheck, "healthCheck");
    this.releaseHealthCheck = releaseHealthCheck;
    // 克隆一份 Bootstrap，避免修改共享配置，并注入我们自己的 ChannelInitializer
    this.bootstrap = checkNotNull(bootstrap, "bootstrap").clone();
    this.bootstrap.handler(new ChannelInitializer<Channel>() {
        @Override
        protected void initChannel(Channel ch) throws Exception {
            assert ch.eventLoop().inEventLoop();
            handler.channelCreated(ch);
        }
    });
    this.lastRecentUsed = lastRecentUsed;
}

这个构造器隐藏了两处关键设计。

其一，它没有直接用 传入的 bootstrap，而是先 clone() 了一份。原因在于 SimpleChannelPool 要往 Bootstrap 上挂一个私有的 ChannelInitializer，如果直接修改原对象，就会污染调用方持有的 Bootstrap 配置。克隆之后，池子内部如何改都影响不到外部。

其二，克隆出来的 Bootstrap 被挂上了一个 ChannelInitializer，这个初始化器在连接建立的最后阶段执行 handler.channelCreated(ch)。也就是说，channelCreated 回调并非在 acquire 的调用栈里直接触发，而是借助 Netty 的 Pipeline 初始化机制、在连接真正建好之后由 EventLoop 线程触发。这既保证了回调运行在正确的线程，也统一了"新连接一定先经过 channelCreated 再交给业务"的时序。

3.2 acquire()：获取连接的两个分支

获取连接的入口是 acquire()，它有两个重载，最终都汇聚到 acquireHealthyFromPoolOrNew 这条统一逻辑上：

io.netty.channel.pool.SimpleChannelPool#acquire

public final Future<Channel> acquire() {
    return acquire(bootstrap.config().group().next().<Channel>newPromise());
}

public Future<Channel> acquire(final Promise<Channel> promise) {
    return acquireHealthyFromPoolOrNew(checkNotNull(promise, "promise"));
}

无参 acquire() 首先通过 bootstrap.config().group().next() 从 EventLoopGroup 中轮询挑出一个 EventLoop，用它来创建一个 Promise，然后委托给带 Promise 的 acquire()。这样获取结果的回调就会在选中的 EventLoop 上执行。

acquireHealthyFromPoolOrNew 是获取逻辑的核心，它要处理"池里有连接"和"池里没连接"两种情况：

io.netty.channel.pool.SimpleChannelPool#acquireHealthyFromPoolOrNew

private Future<Channel> acquireHealthyFromPoolOrNew(final Promise<Channel> promise) {
    try {
        final Channel ch = pollChannel();
        if (ch == null) {
            // 池中无可用连接，克隆 Bootstrap 并新建一条连接
            Bootstrap bs = bootstrap.clone();
            bs.attr(POOL_KEY, this);
            ChannelFuture f = connectChannel(bs);
            if (f.isDone()) {
                notifyConnect(f, promise);
            } else {
                f.addListener((ChannelFutureListener) future -> notifyConnect(future, promise));
            }
        } else {
            // 池中有连接，切换到该连接的 EventLoop 上做健康检查
            EventLoop loop = ch.eventLoop();
            if (loop.inEventLoop()) {
                doHealthCheck(ch, promise);
            } else {
                loop.execute(new Runnable() {
                    public void run() {
                        doHealthCheck(ch, promise);
                    }
                });
            }
        }
    } catch (Throwable cause) {
        promise.tryFailure(cause);
    }
    return promise;
}

先看"池中无连接"的分支。当 pollChannel() 返回 null 时，说明当前没有空闲连接可复用，需要新建。此时会先 bootstrap.clone() 得到一份独立的 Bootstrap，再通过 bs.attr(POOL_KEY, this) 把当前池对象写入新建连接的属性表，然后调用 connectChannel(bs) 发起建连。

这里给连接打上 POOL_KEY 标记，就是为了将来归还时能判断"这条连接是不是从这个池拿出去的"。建连是异步的，所以代码先判断 f.isDone()：若连接已经同步完成，直接处理；否则注册一个监听器，等连接完成后再回溯 notifyConnect。

connectChannel 是一个受保护的方法，默认实现就是一行 bs.connect()，它是留给子类去扩展"如何建连"的钩子。notifyConnect 负责在建连完成后把连接交给调用方：

io.netty.channel.pool.SimpleChannelPool#notifyConnect

private void notifyConnect(ChannelFuture future, Promise<Channel> promise) {
    Channel channel = null;
    try {
        if (future.isSuccess()) {
            channel = future.channel();
            // 通知业务方：连接已被获取
            handler.channelAcquired(channel);
            if (!promise.trySuccess(channel)) {
                // promise 已被取消，立即把连接归还回池
                release(channel);
            }
        } else {
            promise.tryFailure(future.cause());
        }
    } catch (Throwable cause) {
        closeAndFail(channel, cause, promise);
    }
}

建连成功后，notifyConnect 先触发 handler.channelAcquired(channel) 通知业务方"连接被获取了"，再尝试 promise.trySuccess(channel) 完成获取。这里的 trySuccess 用得很讲究：它是"尽力而为"的完成，如果调用方在连接建好之前就取消了 promise，trySuccess 会返回 false，此时连接无人认领，代码会立刻 release(channel) 把它归池，避免泄漏。

再看"池中有连接"的分支。当 pollChannel() 取到连接后，并不能直接交给业务，必须先做健康检查。因为健康检查要求运行在连接的 EventLoop 上，所以代码判断 loop.inEventLoop()：如果当前线程已经在 EventLoop 上就直接执行，否则通过 loop.execute 切换到 EventLoop 线程再执行 doHealthCheck。doHealthCheck 及其回调 notifyHealthCheck 构成了健康检查的完整闭环：

io.netty.channel.pool.SimpleChannelPool#doHealthCheck / #notifyHealthCheck

private void doHealthCheck(final Channel channel, final Promise<Channel> promise) {
    try {
        assert channel.eventLoop().inEventLoop();
        Future<Boolean> f = healthCheck.isHealthy(channel);
        if (f.isDone()) {
            notifyHealthCheck(f, channel, promise);
        } else {
            f.addListener((FutureListener<Boolean>) future -> notifyHealthCheck(future, channel, promise));
        }
    } catch (Throwable cause) {
        closeAndFail(channel, cause, promise);
    }
}

private void notifyHealthCheck(Future<Boolean> future, Channel channel, Promise<Channel> promise) {
    try {
        assert channel.eventLoop().inEventLoop();
        if (future.isSuccess() && future.getNow()) {
            // 连接健康，打上归属标记后交付给业务
            channel.attr(POOL_KEY).set(this);
            handler.channelAcquired(channel);
            promise.setSuccess(channel);
        } else {
            // 连接不健康，关闭它并递归重取一条
            closeChannel(channel);
            acquireHealthyFromPoolOrNew(promise);
        }
    } catch (Throwable cause) {
        closeAndFail(channel, cause, promise);
    }
}

doHealthCheck 调用 healthCheck.isHealthy(channel) 得到结果 Future，同样先判断 f.isDone() 决定走同步还是异步路径。notifyHealthCheck 拿到结果后分两种处理：如果连接健康，就 channel.attr(POOL_KEY).set(this) 打上归属标记、触发 channelAcquired、完成 promise；如果连接不健康，就 closeChannel 把死连接关闭，然后递归调用 acquireHealthyFromPoolOrNew(promise) 重新获取一条。

这个递归是 SimpleChannelPool 获取逻辑的精髓：它把"取连接 → 发现不健康 → 关闭 → 再取连接"的循环收敛成了一个递归函数，直到拿到健康连接，或池中再无可取连接（此时转为新建一条）为止。

下面这张时序图完整展示了 acquire() 的两种分支走向：

上面的时序图清晰地展示了获取连接的完整链路：无论走"池空建连"还是"命中健康检查"两个分支，最终都会经过 channelAcquired 回调、以 promise.success(channel) 收尾；而唯一的分岔点是健康检查失败时，会关闭死连接并递归重取。

3.3 release()：归还连接与 POOL_KEY 归属校验

归还连接的入口是 release()，它与 acquire() 一样提供无参和带 Promise 两个重载：

io.netty.channel.pool.SimpleChannelPool#release

public final Future<Void> release(Channel channel) {
    return release(channel, channel.eventLoop().<Void>newPromise());
}

public Future<Void> release(final Channel channel, final Promise<Void> promise) {
    try {
        checkNotNull(channel, "channel");
        checkNotNull(promise, "promise");
        EventLoop loop = channel.eventLoop();
        if (loop.inEventLoop()) {
            doReleaseChannel(channel, promise);
        } else {
            loop.execute(new Runnable() {
                public void run() {
                    doReleaseChannel(channel, promise);
                }
            });
        }
    } catch (Throwable cause) {
        closeAndFail(channel, cause, promise);
    }
    return promise;
}

无参 release() 通过 channel.eventLoop().newPromise() 创建一个挂在连接 EventLoop 上的 Promise，然后委托给带 Promise 重载。带 Promise 版本在完成参数校验后立即做线程切换：归还动作必须运行在连接的 EventLoop 上，因为 doReleaseChannel 内部要读写连接的属性表，跨线程读写不安全。

doReleaseChannel 是归还逻辑的核心，它的第一道关卡就是归属校验：

io.netty.channel.pool.SimpleChannelPool#doReleaseChannel

private void doReleaseChannel(Channel channel, Promise<Void> promise) {
    try {
        assert channel.eventLoop().inEventLoop();
        // 取出并清空 POOL_KEY 属性，校验连接是否真的来自当前池
        if (channel.attr(POOL_KEY).getAndSet(null) != this) {
            closeAndFail(channel,
                    new IllegalArgumentException(
                            "Channel " + channel + " was not acquired from this ChannelPool"),
                    promise);
        } else {
            if (releaseHealthCheck) {
                doHealthCheckOnRelease(channel, promise);
            } else {
                releaseAndOffer(channel, promise);
            }
        }
    } catch (Throwable cause) {
        closeAndFail(channel, cause, promise);
    }
}

getAndSet(null) 是一个"读取并清空"的原子操作：它先读出连接上当前的 POOL_KEY 值，再把它置空。如果读出来的值不是当前池对象 this，说明这条连接不是从这个池获取的（或者是重复归还），此时直接关闭连接并让 promise 失败。这个设计用一条属性就同时实现了"归属校验"和"防止重复归还"两个目的，是本类里最反直觉却也最精妙的细节之一。

通过了归属校验之后，就进入了归还的正式流程。根据 releaseHealthCheck 开关，归还路径会分叉：若开关关闭，直接走 releaseAndOffer 放回队列；若开关开启，则先经 doHealthCheckOnRelease 做一次健康检查，健康连接才走 releaseAndOffer，不健康连接则只触发 channelReleased 回调而不再放回队列。无论走哪条路径，releaseAndOffer 都是健康连接归队的最后一站：

io.netty.channel.pool.SimpleChannelPool#releaseAndOffer / #pollChannel / #offerChannel

private void releaseAndOffer(Channel channel, Promise<Void> promise) throws Exception {
    if (offerChannel(channel)) {
        handler.channelReleased(channel);
        promise.setSuccess(null);
    } else {
        closeAndFail(channel, new ChannelPoolFullException(), promise);
    }
}

protected Channel pollChannel() {
    return lastRecentUsed ? deque.pollLast() : deque.pollFirst();
}

protected boolean offerChannel(Channel channel) {
    return deque.offer(channel);
}

releaseAndOffer 尝试把连接放回队列：offerChannel 默认实现是 deque.offer(channel)，成功后再回调 handler.channelReleased(channel) 并完成 promise；如果 offerChannel 返回 false（子类实现了容量上限，入队失败），就以 ChannelPoolFullException 失败并关闭连接。这里补一句，ChannelPoolFullException 是 SimpleChannelPool 的私有静态内部类，继承自 IllegalStateException，而且默认的 deque.offer 恒返回 true，所以这条失败分支实际上是留给覆写了 offerChannel 的子类的。

归还路径还有一个容易被忽略的边角：releaseAndOfferIfHealthy 判定健康时直接用了 future.getNow()，并没有先判断 future.isSuccess()。如果健康检查本身以失败收场，getNow() 会返回 null，紧跟的布尔拆箱就会抛出 NullPointerException，被外层 catch 接住后走 closeAndFail，结果是连接被关闭、promise 以该异常失败。也就是说归还除了"健康入队""不健康只回调"这两种常态收尾，还存在"检查本身失败即关闭连接"这第三种兜底。

pollChannel 与 offerChannel 是 SimpleChannelPool 提供给子类扩展的两个受保护方法。默认情况下，pollChannel 根据 lastRecentUsed 决定是 pollLast（LIFO）还是 pollFirst（FIFO），offerChannel 则统一从队尾入队。SimpleChannelPool 的类注释明确说明其采用 LIFO 顺序，也就是优先复用最近归还的连接，这样做的直觉是：刚归还的连接是"热"的，对端状态最新鲜，复用成功率更高，同时也能让闲置较久的连接尽早被关闭回收。

下面这张时序图展示了 release() 的完整链路：

上面的时序图清晰地展示了归还连接的两个关节点：先是 POOL_KEY 的归属校验拦截"误归还"与"重复归还"，再是可选的健康检查决定连接是放回队列复用还是不再缓存。无论健康与否，channelReleased 回调都会触发；区别在于，只有健康的连接才会真正通过 offerChannel 重新入队。

3.4 close() 与 closeAsync()：清空连接池

连接池持有连接资源，因此必须提供关闭入口。SimpleChannelPool 提供了同步的 close() 与异步的 closeAsync()：

io.netty.channel.pool.SimpleChannelPool#close / #closeAsync

public void close() {
    for (;;) {
        Channel channel = pollChannel();
        if (channel == null) {
            break;
        }
        // 忽略关闭返回的错误，逐个关闭并等待完成
        channel.close().awaitUninterruptibly();
    }
}

public Future<Void> closeAsync() {
    // 避免在 EventLoop 上阻塞，把关闭任务提交到全局执行器
    return GlobalEventExecutor.INSTANCE.submit(new Callable<Void>() {
        public Void call() throws Exception {
            close();
            return null;
        }
    });
}

close() 的逻辑很直接：循环 pollChannel() 把队列里的连接一个个取出来，逐个调用 channel.close().awaitUninterruptibly() 同步关闭并等待完成，直到队列为空。closeAsync() 则是把 close() 包装成任务提交给 GlobalEventExecutor 异步执行，注释特别说明这是为了避免在 EventLoop 上阻塞调用方线程。

四、FixedChannelPool：并发限流与等待队列

4.1 构造器：并发上限与超时参数

SimpleChannelPool 没有连接数上限，意味着在高并发下，如果请求到达速度快于归还速度，池子会无限制地创建新连接，最终耗尽系统资源。FixedChannelPool 正是为这个问题而生，它继承 SimpleChannelPool，强制约束最大并发连接数。

FixedChannelPool 的核心字段如下：

• executor（EventExecutor）：单线程执行器，acquire()/release() 的状态变更全部串行在它上面
• maxConnections（int）：最大并发连接数
• maxPendingAcquires（int）：最大等待请求数，默认 Integer.MAX_VALUE
• acquiredChannelCount（AtomicInteger）：已获取连接计数
• pendingAcquireCount（int）：等待中请求计数，只在 executor 线程内读写
• pendingAcquireQueue（Queue<AcquireTask>）：等待请求队列，实现为 ArrayDeque
• acquireTimeoutNanos（long）：获取超时，-1 表示不超时
• timeoutTask（Runnable）：超时任务
• AcquireTimeoutAction（嵌套枚举）：NEW 表示超时后新建一条连接，FAIL 表示超时后让本次获取失败并抛出 AcquireTimeoutException

理解这些字段的分工，是读懂限流逻辑的前提。其中最重要的两个计数是 acquiredChannelCount（已获取连接数，用 AtomicInteger 保证可见性）与 pendingAcquireCount（等待中请求数，只在 executor 单线程内读写，无需并发控制）。executor 取自 bootstrap.config().group().next()，它保证所有对这两个计数与等待队列的读写都串行化在同一个线程上，从而避免了加锁。

FixedChannelPool 的构造器链较长，全参构造器除了调用父类构造器，还负责校验并发上限与解析超时参数：

io.netty.channel.pool.FixedChannelPool

public FixedChannelPool(Bootstrap bootstrap, ChannelPoolHandler handler,
                        ChannelHealthChecker healthCheck, AcquireTimeoutAction action,
                        final long acquireTimeoutMillis,
                        int maxConnections, int maxPendingAcquires,
                        boolean releaseHealthCheck, boolean lastRecentUsed) {
    super(bootstrap, handler, healthCheck, releaseHealthCheck, lastRecentUsed);
    checkPositive(maxConnections, "maxConnections");
    checkPositive(maxPendingAcquires, "maxPendingAcquires");
    if (action == null && acquireTimeoutMillis == -1) {
        // 不启用超时
        timeoutTask = null;
        acquireTimeoutNanos = -1;
    } else if (action == null && acquireTimeoutMillis != -1) {
        throw new NullPointerException("action");
    } else if (action != null && acquireTimeoutMillis < 0) {
        throw new IllegalArgumentException("acquireTimeoutMillis: " + acquireTimeoutMillis + " (expected: >= 0)");
    } else {
        acquireTimeoutNanos = TimeUnit.MILLISECONDS.toNanos(acquireTimeoutMillis);
        switch (action) {
        case FAIL:
            // 超时后让本次获取失败
            timeoutTask = new TimeoutTask() {
                public void onTimeout(AcquireTask task) {
                    task.promise.setFailure(new AcquireTimeoutException());
                }
            };
            break;
        case NEW:
            // 超时后绕过上限，直接建一条新连接
            timeoutTask = new TimeoutTask() {
                public void onTimeout(AcquireTask task) {
                    task.acquired();
                    FixedChannelPool.super.acquire(task.promise);
                }
            };
            break;
        default:
            throw new Error("Unexpected AcquireTimeoutAction: " + action);
        }
    }
    executor = bootstrap.config().group().next();
    this.maxConnections = maxConnections;
    this.maxPendingAcquires = maxPendingAcquires;
}

checkPositive 强制 maxConnections 与 maxPendingAcquires 为正数，这是限流参数的合法性边界。紧跟着的超时参数解析是一段值得细读的分支逻辑，它定义了 AcquireTimeoutAction（枚举 NEW/FAIL）与 acquireTimeoutMillis 的组合语义：

• action == null && acquireTimeoutMillis == -1：不启用超时，timeoutTask 与 acquireTimeoutNanos 都置为"未启用"。
• action == null && acquireTimeoutMillis != -1：只给超时不给动作，属于参数缺失，直接抛 NullPointerException("action")。
• action != null && acquireTimeoutMillis < 0：有动作但超时为负数，属于非法，抛 IllegalArgumentException。
• 其余情况：把毫秒换算成纳秒，并按动作生成对应的 timeoutTask。

FAIL 动作生成的任务在超时后直接让 task.promise.setFailure(AcquireTimeoutException)，即"等太久就失败"；NEW 动作则调用 task.acquired() 增加计数，然后 FixedChannelPool.super.acquire(task.promise) 绕过上限直接建连接，即"等太久就新建一条"。这两种策略分别对应了严格限流与弹性扩容两种业务诉求。

4.2 acquire：限流与等待队列

FixedChannelPool 覆写了父类的 acquire(Promise)，它做的第一件事是把执行切到 executor 线程上：

io.netty.channel.pool.FixedChannelPool#acquire / #acquire0

public Future<Channel> acquire(final Promise<Channel> promise) {
    try {
        if (executor.inEventLoop()) {
            acquire0(promise);
        } else {
            executor.execute(new Runnable() {
                public void run() {
                    acquire0(promise);
                }
            });
        }
    } catch (Throwable cause) {
        promise.tryFailure(cause);
    }
    return promise;
}

private void acquire0(final Promise<Channel> promise) {
    try {
        assert executor.inEventLoop();
        if (closed) {
            promise.setFailure(new IllegalStateException("FixedChannelPool was closed"));
            return;
        }
        if (acquiredChannelCount.get() < maxConnections) {
            // 未达上限，直接创建连接，并通过 AcquireListener 计数
            Promise<Channel> p = executor.newPromise();
            AcquireListener l = new AcquireListener(promise);
            l.acquired();
            p.addListener(l);
            super.acquire(p);
        } else {
            // 已达上限，进入等待队列
            if (pendingAcquireCount >= maxPendingAcquires) {
                tooManyOutstanding(promise);
            } else {
                AcquireTask task = new AcquireTask(promise);
                if (pendingAcquireQueue.offer(task)) {
                    ++pendingAcquireCount;
                    if (timeoutTask != null) {
                        task.timeoutFuture = executor.schedule(timeoutTask, acquireTimeoutNanos,
                              TimeUnit.NANOSECONDS);
                    }
                } else {
                    tooManyOutstanding(promise);
                }
            }
            assert pendingAcquireCount > 0;
        }
    } catch (Throwable cause) {
        promise.tryFailure(cause);
    }
}

acquire0 先做一次 closed 检查，池已关闭则直接失败。随后进入真正的限流判断，分两条路：

当 acquiredChannelCount.get() < maxConnections 时，说明还有连接额度，可以放行。此时创建一个新的内部 Promise p 和一个 AcquireListener l，先调用 l.acquired() 把 acquiredChannelCount 加一，再把监听器挂到 p 上，最后 super.acquire(p) 走父类的建连逻辑。这里多包一层 AcquireListener 的用意是：成功时保留计数（连接保持被占用状态），失败时回滚计数并唤醒等待队列，让 acquiredChannelCount 始终与实际占用的连接数保持一致。

当连接数已达上限时，请求不能立即放行，需要进入等待队列。此时先判断 pendingAcquireCount >= maxPendingAcquires，如果等待的请求也已经堆满，就直接以 tooManyOutstanding 失败，避免等待队列无限膨胀；否则构造一个 AcquireTask 入队、pendingAcquireCount 加一，并在启用了超时的情况下调度一个超时任务。

AcquireListener 与它的 acquired() 方法实现了计数与回调的两阶段处理：

io.netty.channel.pool.FixedChannelPool$AcquireListener

private class AcquireListener implements FutureListener<Channel> {
    private final Promise<Channel> originalPromise;
    protected boolean acquired;

    AcquireListener(Promise<Channel> originalPromise) {
        this.originalPromise = originalPromise;
    }

    @Override
    public void operationComplete(Future<Channel> future) throws Exception {
        try {
            assert executor.inEventLoop();

            if (closed) {
                if (future.isSuccess()) {
                    // 池已关闭，只能把连接关掉
                    future.getNow().close();
                }
                originalPromise.setFailure(new IllegalStateException("FixedChannelPool was closed"));
                return;
            }
            if (future.isSuccess()) {
                originalPromise.setSuccess(future.getNow());
            } else {
                // 获取失败，返还计数并唤醒等待队列中的下一个请求
                if (acquired) {
                    decrementAndRunTaskQueue();
                } else {
                    runTaskQueue();
                }
                originalPromise.setFailure(future.cause());
            }
        } catch (Throwable cause) {
            originalPromise.tryFailure(cause);
        }
    }

    public void acquired() {
        // 防止重复计数
        if (acquired) {
            return;
        }
        acquiredChannelCount.incrementAndGet();
        acquired = true;
    }
}

operationComplete 在父类获取完成时被回调：成功则把结果透传给原始的 promise；失败则根据 acquired 标志决定是 decrementAndRunTaskQueue（本次计数已加，需要减一）还是 runTaskQueue（本次计数未加，直接唤醒等待队列），最后让原始 promise 失败。

acquired() 方法用 acquired 标志保证幂等：无论被调用多少次，acquiredChannelCount 只加一次。这个幂等设计很重要，因为在超时任务的 NEW 动作里也会调用 task.acquired()，而这条计数路径在"正常唤醒"（runTaskQueue）与"超时建新连接"（onTimeout 的 NEW 动作）两条互斥分支中都可能被调用，幂等标志可防御潜在的重复计数。

下面这张时序图展示了 FixedChannelPool 获取时的限流分支：

上面的时序图清晰地展示了 FixedChannelPool 的限流逻辑：额度充足时直接建连并计数，额度不足时要么因等待队列满而失败，要么进入 pendingAcquireQueue 等待并挂起超时任务。这种"有额度就放行、没额度就排队、队满才拒绝"的三级策略，正是固定连接池限流的经典形态。

4.3 release：归还唤醒等待队列

FixedChannelPool 的归还逻辑与父类最大的不同在于：归还一个连接后，要唤醒等待队列中的下一个请求。它覆写了 release(Channel, Promise)：

io.netty.channel.pool.FixedChannelPool#release

public Future<Void> release(final Channel channel, final Promise<Void> promise) {
    ObjectUtil.checkNotNull(promise, "promise");
    final Promise<Void> p = executor.newPromise();
    super.release(channel, p.addListener((FutureListener<Void>) future -> {
        try {
            assert executor.inEventLoop();

            if (closed) {
                // 池已关闭，只能把连接关掉
                channel.close();
                promise.setFailure(new IllegalStateException("FixedChannelPool was closed"));
                return;
            }
            if (future.isSuccess()) {
                decrementAndRunTaskQueue();
                promise.setSuccess(null);
            } else {
                Throwable cause = future.cause();
                // 只有失败原因不是"连接不属于本池"时才需要减计数
                if (!(cause instanceof IllegalArgumentException)) {
                    decrementAndRunTaskQueue();
                }
                promise.setFailure(future.cause());
            }
        } catch (Throwable cause) {
            promise.tryFailure(cause);
        }
    }));
    return promise;
}

release 创建了一个内部 Promise p 交给父类的 super.release，并在 p 上挂监听器。当父类的归还动作完成后，监听器被回调：如果池已关闭，直接关闭连接并失败；如果归还成功，调用 decrementAndRunTaskQueue() 把计数减一并唤醒等待队列；如果归还失败，则只在失败原因不是 IllegalArgumentException 时才减计数，因为 IllegalArgumentException 对应父类里的"连接不是本池的"误归还，这种失败本就不该消耗计数。

减计数与唤醒的逻辑在 decrementAndRunTaskQueue 与 runTaskQueue 两个方法里：

io.netty.channel.pool.FixedChannelPool#decrementAndRunTaskQueue / #runTaskQueue

private void decrementAndRunTaskQueue() {
    int currentCount = acquiredChannelCount.decrementAndGet();
    assert currentCount >= 0;
    runTaskQueue();
}

private void runTaskQueue() {
    while (acquiredChannelCount.get() < maxConnections) {
        AcquireTask task = pendingAcquireQueue.poll();
        if (task == null) {
            break;
        }
        // 取消该任务挂起的超时，因为它马上要被放行了
        ScheduledFuture<?> timeoutFuture = task.timeoutFuture;
        if (timeoutFuture != null) {
            timeoutFuture.cancel(false);
        }
        --pendingAcquireCount;
        task.acquired();
        super.acquire(task.promise);
    }
}

decrementAndRunTaskQueue 先把 acquiredChannelCount 减一，表示"有一个连接被归还了、额度空出来一个"，然后调用 runTaskQueue 去消化等待队列。

runTaskQueue 用一个 while 循环实现了"归还一个、唤醒一个"的联动：只要 acquiredChannelCount 还小于 maxConnections 且队列非空，就从队头 poll 出一个等待任务，先取消它身上可能挂着的超时任务，再把 pendingAcquireCount 减一、task.acquired() 把连接数加一，最后 super.acquire(task.promise) 用父类逻辑真正为这个等待者建连。当连接数再次触顶或队列清空时，循环自然终止。

这条设计的精妙之处在于：归还与唤醒被串成了同一条链路，一个连接归还释放出的额度，会立刻被队列头部的等待请求接住，从而保证额度始终被充分利用，不会出现"有空额却无人建连"的浪费。

下面这张时序图展示了归还后唤醒等待队列的完整链路：

上面的时序图清晰地展示了归还连接的涟漪效应：一次 release 不仅完成了一次归还，还通过 runTaskQueue 的循环把释放出的额度逐一分发给等待队列里的请求，直到队列清空或额度再次用尽。

4.4 TimeoutTask 与关闭

当等待队列里的请求迟迟等不到额度时，就需要超时任务来兜底。TimeoutTask 是一个抽象内部类，定义了超时扫描的骨架：

io.netty.channel.pool.FixedChannelPool$TimeoutTask

private abstract class TimeoutTask implements Runnable {
    public final void run() {
        assert executor.inEventLoop();
        long nanoTime = System.nanoTime();
        for (;;) {
            AcquireTask task = pendingAcquireQueue.peek();
            // 队头任务尚未超时，或队列已空，停止扫描
            if (task == null || nanoTime - task.expireNanoTime < 0) {
                break;
            }
            pendingAcquireQueue.remove();
            --pendingAcquireCount;
            onTimeout(task);
        }
    }

    public abstract void onTimeout(AcquireTask task);
}

每个 AcquireTask 在构造时就记录了自己的截止时间 expireNanoTime = System.nanoTime() + acquireTimeoutNanos，也就是入队那一刻往后推一个超时窗口，作为它被判定超时的基准。run() 的关键在于它只扫描队头 ：因为等待队列是按入队时间线性排列的，入队越早的请求其超时时间越早，只要队头还没超时，后面的任务必然也没超时，于是可以安全地 break 提前退出。一旦队头超时，就把它 remove 出队、pendingAcquireCount 减一，然后调用抽象的 onTimeout 交给子类处理，而 onTimeout 的两种实现（FAIL 失败 / NEW 建新连接）正是上一节构造器里按 AcquireTimeoutAction 生成的。

FixedChannelPool 的关闭同样要处理那个额外的等待队列，close0 是它的核心：

io.netty.channel.pool.FixedChannelPool#close0

private Future<Void> close0() {
    assert executor.inEventLoop();
    if (!closed) {
        closed = true;
        // 清空等待队列：取消超时任务，并让所有等待者失败
        for (;;) {
            AcquireTask task = pendingAcquireQueue.poll();
            if (task == null) {
                break;
            }
            ScheduledFuture<?> f = task.timeoutFuture;
            if (f != null) {
                f.cancel(false);
            }
            task.promise.setFailure(new ClosedChannelException());
        }
        acquiredChannelCount.set(0);
        pendingAcquireCount = 0;
        // 把实际关闭连接的阻塞操作提交到全局执行器，避免阻塞 EventLoop
        return GlobalEventExecutor.INSTANCE.submit(new Callable<Void>() {
            public Void call() throws Exception {
                FixedChannelPool.super.close();
                return null;
            }
        });
    }
    return GlobalEventExecutor.INSTANCE.newSucceededFuture(null);
}

close0 先把 closed 置为 true，随后清空整个等待队列：逐个 poll 出任务、取消其超时 ScheduledFuture、让对应的 promise（AcquireTask 内部创建的 Promise）以 ClosedChannelException 失败，这一失败会经 AcquireListener 的 closed 分支改写成对外的 IllegalStateException，让所有还在等待的调用方立刻感知到"池已经关了"。接着把两个计数清零，最后把真正关闭连接的 super.close() 提交到 GlobalEventExecutor 异步执行，避免在 EventLoop 上做阻塞的关闭操作。

五、ChannelPoolMap 与 AbstractChannelPoolMap：多后端路由

5.1 ChannelPoolMap 接口：按 key 的路由抽象

前四章讨论的都是"一个连接池如何工作"，但在真实的客户端场景里，我们往往需要同时连接多个后端：例如一个 HTTP 客户端要访问多个上游服务，或者一个数据库代理要连接多个数据库实例。此时就需要把连接池按地址组织 起来，ChannelPoolMap 正是这个职责的抽象：

io.netty.channel.pool.ChannelPoolMap

public interface ChannelPoolMap<K, P extends ChannelPool> {
    P get(K key);
    boolean contains(K key);
}

ChannelPoolMap 只有两个方法：get(K key) 返回给定 key 对应的连接池，如果不存在就创建一个；contains(K key) 判断某个 key 的连接池是否已存在。它的典型用法是以 InetSocketAddress 为 key，把不同的远端地址映射到各自独立的 ChannelPool，实现"一地址一池"的连接复用。

5.2 AbstractChannelPoolMap：ConcurrentHashMap 缓存与并发安全

AbstractChannelPoolMap 是 ChannelPoolMap 的骨架实现，它内部持有一个 ConcurrentHashMap 作为连接池缓存，并实现了并发安全的 get：

io.netty.channel.pool.AbstractChannelPoolMap#get

public final P get(K key) {
    P pool = map.get(checkNotNull(key, "key"));
    if (pool == null) {
        pool = newPool(key);
        P old = map.putIfAbsent(key, pool);
        if (old != null) {
            // 并发竞争：另一个线程先建好了池，关闭我们多建的这份
            poolCloseAsyncIfSupported(pool);
            pool = old;
        }
    }
    return pool;
}

get 先用 map.get 查缓存，命中就直接返回。未命中时，调用抽象的 newPool(key) 新建一个池，再用 putIfAbsent 原子地写入缓存。这里 putIfAbsent 是并发安全的精髓：如果两个线程同时请求同一个 key，都发现缓存为空，都会各自 newPool 出一个池，但 putIfAbsent 只允许第一个写入成功，后到者拿到的 old 是已存在的那份，于是关闭自己多建的那份并返回已有的池。这样既保证了"同一个 key 只有一个池"，又避免了用锁带来的性能损耗。

newPool(key) 是留给子类实现的抽象工厂方法，它决定"如何为某个 key 创建一个连接池"，是模板方法模式的核心扩展点。使用方继承 AbstractChannelPoolMap，只需实现这一个方法即可获得整套并发安全的路由能力。

下面这张时序图展示了 get 的并发安全路由逻辑：

上面的时序图清晰地展示了 get 的两层处理：缓存命中时直接返回，未命中时通过 putIfAbsent 原子写入，并在并发竞争时优雅地丢弃多建的池、返回已有的那一份。

5.3 关闭与异步关闭适配

AbstractChannelPoolMap 还需要在移除和关闭时正确释放池资源，这里最关键的是对"异步关闭"的适配：

io.netty.channel.pool.AbstractChannelPoolMap#poolCloseAsyncIfSupported / #close

private static Future<Void> poolCloseAsyncIfSupported(ChannelPool pool) {
    if (pool instanceof SimpleChannelPool) {
        return ((SimpleChannelPool) pool).closeAsync();
    } else {
        try {
            pool.close();
            return GlobalEventExecutor.INSTANCE.newSucceededFuture(null);
        } catch (Exception e) {
            return GlobalEventExecutor.INSTANCE.newFailedFuture(e);
        }
    }
}

public final void close() {
    for (K key: map.keySet()) {
        // 逐个移除并等待关闭完成，确保返回前资源已全部释放
        removeAsyncIfSupported(key).syncUninterruptibly();
    }
}

poolCloseAsyncIfSupported 做了一个类型适配：如果池是 SimpleChannelPool（FixedChannelPool 也继承自它），就调用其 closeAsync() 走异步关闭；否则调用同步的 close() 并把结果包装成 Future。这样做的目的是统一的，关闭连接涉及网络 IO，如果 ChannelPoolMap 的操作恰好发生在 EventLoop 线程上，同步关闭会阻塞 EventLoop，异步关闭则能避免这一点。

close() 遍历 map.keySet()，对每个 key 执行 removeAsyncIfSupported(key).syncUninterruptibly()，逐个移除并阻塞等待关闭完成，确保 close() 返回时所有池资源都已被释放。

六、整体链路串联

把前面各章节的内容串联起来，就能看清 ChannelPool 连接复用体系的完整闭环。它由五条相互咬合的线索构成，最终收敛为"获取、归还、健康检查、限流、路由"五位一体的机制。

获取链路：acquire() → acquireHealthyFromPoolOrNew → pollChannel，池空时经 Bootstrap.clone() 与 connectChannel() 建连，命中时做健康检查，最终回调 channelAcquired 并完成 promise。归还链路：release() → doReleaseChannel → POOL_KEY 归属校验 → 可选健康检查 → offerChannel 入队，回调 channelReleased 并完成 promise。

健康检查闭环：获取与归还两个时机都经 ChannelHealthChecker.isHealthy 把关，不健康连接一律关闭而非回池，获取时还会触发 acquireHealthyFromPoolOrNew 的递归重建。限流与唤醒闭环：FixedChannelPool 用 acquiredChannelCount 限制并发，超出时请求进入 pendingAcquireQueue 等待，归还一个连接就 decrementAndRunTaskQueue 唤醒下一个，超时任务按 AcquireTimeoutAction 决定失败或建新连接。多后端路由闭环：AbstractChannelPoolMap 用 ConcurrentHashMap 缓存连接池，get 经 putIfAbsent 保证并发安全，newPool 抽象工厂按 key 建池。

可以说，Netty 连接池管理机制的关键在于**"获取 + 归还 + 健康检查 + 限流 + 路由"**：SimpleChannelPool 提供了无界复用与健康检查的基础，FixedChannelPool 叠加了并发限流与超时控制，ChannelPoolMap 完成了多后端的组织路由，三者层层递进，共同构成了一套完整的连接复用与资源管理体系。

全文小结

本文聚焦 Netty 连接池 ChannelPool 的连接复用与资源管理，从接口抽象与限流增强两个维度，深入分析了连接获取、归还、健康检查、并发限流与多后端路由的完整机制。

在接口抽象层面，ChannelPool 继承 Closeable 且仅有获取、归还、关闭五个方法，acquire 返回 Future<Channel>、release 返回 Future<Void> 的异步签名将建连重操作移出调用线程，并隐含"获取后必须归还"的约定。在回调与健康检查层面，ChannelPoolHandler 以 channelCreated/channelAcquired/channelReleased 三个回调覆盖连接生命周期，ChannelHealthChecker 以 ACTIVE 默认实现与 Future<Boolean> 异步签名把关连接可用性。在基础实现层面，SimpleChannelPool 用并发双端队列 deque 存放空闲连接、以 lastRecentUsed 支持 LIFO/FIFO 复用，POOL_KEY 属性标记归属并校验误归还，池空时经 Bootstrap.clone() 与 connectChannel() 建连，不健康连接在 acquireHealthyFromPoolOrNew 中递归重建。在限流增强层面，FixedChannelPool 用 acquiredChannelCount 与 maxConnections 限制并发，pendingAcquireQueue 承载等待请求，runTaskQueue 在归还时逐个唤醒，AcquireTimeoutAction 的 FAIL/NEW 分别对应超时失败与超时建新连接。在多后端路由层面，AbstractChannelPoolMap 以 ConcurrentHashMap 缓存连接池、putIfAbsent 保证并发安全、newPool 抽象工厂按 key 建池，poolCloseAsyncIfSupported 让关闭动作支持异步语义。

---

原创不易，如果本文对您有帮助，带来了些许灵感或启发，烦请动动小手点赞、关注、转发、收藏。这是作者持续更新的动力源泉，衷心感谢您的支持。我会尽量在工作之余，为大家带来更高品质的内容，努力保持周更。