企业官网建设流程全解析

1. 为什么说HTTP连接池这件事值得用Netty自己写

先聊个现象。大多数Java后端项目里，提到HTTP Client第一反应就是Apache HttpClient或者OkHttp，加连接池也就是几行配置的事。但真到了高并发、长连接、低延迟这组需求同时压上来的时候，现成方案反而容易成为瓶颈。尤其是在做网关、爬虫框架、异步RPC桥接层这一类偏底层的组件时，你会发现需要的不只是一个“能发请求的客户端”，而是一个能跟自己的线程模型、超时体系、监控体系完全打通的连接管理模块。

Netty作为异步事件驱动的网络框架，本身就是围绕Channel和EventLoop构建的，天然适合做长连接复用。用Netty做HTTP Client连接池，本质上是把这几个东西组合在一起：

• 用Netty的Bootstrap创建客户端Channel，每个Channel对应一条TCP连接
• 用一个池结构管理这些Channel，分发请求时“借”一条连接、用完后“还”回去
• 通过Netty的Future/Promise机制把异步收包和业务回调串起来，保证请求响应不串台
• 借用粘包处理、空闲检测、健康检查这些Netty原生能力，让连接池里的连接始终是“干净可用”的

适合读这篇文章的人，一种是团队里要自研网关或中间件、已经在用Netty但对连接池设计不太有把握的工程师，另一种是用过现成HTTP Client但被性能、超时、连接泄漏问题反复折磨、想搞清楚底层逻辑的人。我会把整体设计、数据结构选型、核心代码实现、生命周期管理、参数配置、常见坑全部摊开讲。

先说结论：如果你只是写个普通业务接口，OkHttp完全够用，别折腾。但如果你是做中间件、网关、高并发采集系统，或者已经有Netty技术栈沉淀，自研HTTP Client连接池带来的收益非常明显——线程模型统一、连接利用率可控、监控埋点随处可加。

2. 连接池设计的核心思路与数据结构选型

2.1 连接池到底在管理什么

连接池的本质不是“池”，而是“复用”。HTTP/1.1里一次TCP连接可以串行发送多个请求，前提是响应有序返回。HTTP/2支持多路复用，但连接池的思路仍然一致：减少频繁建连带来的三次握手开销、TLS握手开销，以及TIME_WAIT状态的堆积。

我的理解里，一个HTTP Client连接池需要管住三件事：

• 数量：最多允许建立多少条连接，超出之后新请求是排队等待还是直接失败
• 分配：并发请求来的时候，怎么从池里挑一条可用的连接，怎么避免同一连接被并发复用导致响应错乱
• 回收：连接空闲多久算无效、服务端主动断开后怎么感知、异常连接怎么淘汰

Netty里已经提供了一个基础实现叫SimpleChannelPool，实现了ChannelPool接口，支持acquire和release。但它只管“借”和“还”，不管“连接是不是干净状态”。所以实践中，我们通常基于SimpleChannelPool做一层封装，把HTTP协议层面的状态管理叠加进去。

2.2 为什么不用现成HTTP Client的连接池逻辑

有人问过：Apache HttpClient的连接池不是很成熟吗？直接拿来用不就行了。如果只是发HTTP请求，确实可以。但当你需要把HTTP调用编入Netty的EventLoop线程模型时，麻烦就来了——HttpClient有自己的一套连接管理器、线程池、超时调度，跟Netty的事件循环是两套体系。两套体系共存意味着两套线程、两套锁、两套超时机制，排查问题时你永远要问一句“这个等待到底阻塞在哪儿了”。

自研方案可以做到一个EventLoop线程里既处理TCP读写、又处理HTTP响应分发、还控制连接池的获取与释放，整个链路没有跨线程切换，也没有多余的锁竞争。这是自研最有价值的地方，不是“性能一定更高”，而是“行为完全可控”。

2.3 数据结构选型的关键考虑

连接池本身可以用ConcurrentLinkedQueue存储空闲连接，配合Semaphore控制最大连接数。但光有队列不够，分布式场景或线程池场景下需要知道每条连接当前的状态——是在空闲队列里、还是被某个请求借走了、还是已经半死不活。所以更可靠的结构是“池内队列 + 全局状态表”：

• ChannelPool内部维护一个Deque<Channel>作为空闲连接集合，获取时从队头取，释放时从队尾放，避免一条连接被频繁使用导致热点
• 用一个ConcurrentHashMap<Channel, ConnectionState>记录每条连接的存活状态和归属信息
• 用一个Semaphore或者自定义计数器约束总连接数，超过上限时阻塞或抛异常

但请记得：Netty的Channel不是普通对象，它绑定在某个EventLoop上。如果从非EventLoop线程调用channel.writeAndFlush，Netty会把这个操作封装成Task丢进EventLoop的任务队列。连接池在跨线程借还连接时，要在两个层面上保证安全——池结构本身的线程安全，以及Channel写入操作的线程安全。这一点在后面的代码里会体现。

2.4 为什么粘包处理必须在连接池设计里提前考虑

热词里有“netty粘包处理”，这和HTTP Client连接池的关系非常直接。TCP是流协议，消息之间没有天然边界。服务端返回的HTTP响应可能分多个包到达，也可能多个响应拼在一个包里到达。Netty的HttpObjectDecoder已经做了HTTP协议层的粘包拆包，它会根据Content-Length或者chunked编码自动判断消息边界。

但这里有个容易踩的坑：HttpObjectDecoder产生的对象不只是一个HttpResponse，后面还跟着HttpContent、LastHttpContent。如果没有用HttpObjectAggregator聚合，你拿到的就是零散的碎包。所以用Netty做HTTP Client连接池时，Pipeline里聚合器几乎是标配，把一组HttpResponse + HttpContent拼成一个完整的FullHttpResponse，连接池才能明确知道“这条连接上的这次请求已经结束，可以释放回池子”。

3. 代码级实现：从Handler到获取与释放的完整流程

3.1 定义连接池Handler

Netty的ChannelPoolHandler接口是连接池和Channel初始化之间的桥梁，它负责三个动作：channel创建时初始化、channel被获取时检查、channel被释放时清理。

public class HttpClientChannelPoolHandler implements ChannelPoolHandler { private final String host; private final int port; @Override public void channelCreated(Channel ch) { ChannelPipeline pipeline = ch.pipeline(); // HTTP编码器和解码器是基础 pipeline.addLast("httpCodec", new HttpClientCodec()); // 聚合器把碎片包拼成FullHttpResponse，才能安全复用连接 pipeline.addLast("httpAggregator", new HttpObjectAggregator(10 * 1024 * 1024)); // 空闲检测：读空闲15秒、写空闲15秒、全空闲0代表不关心 pipeline.addLast("idleHandler", new IdleStateHandler(15, 15, 0)); // 业务侧的响应处理Handler，下面会展开 pipeline.addLast("httpClientHandler", new HttpClientChannelHandler()); } @Override public void channelAcquired(Channel ch) { // 从池里取出来的时候，通常要校验一下这条连接还能不能用 if (!ch.isActive()) { throw new IllegalStateException("Channel is not active"); } } @Override public void channelReleased(Channel ch) { // 释放回池子之前，把可能残留的读取状态清掉 // 比如清掉Pipeline里的临时Attribute，确保下个请求拿到的是干净连接 ch.attr(AttributeKey.valueOf("requestInfo")).set(null); } }

这里的核心设计思路是：池里的Channel是“通用零件”，每次被借出去执行一次HTTP请求，回来之后必须恢复到出厂状态。channelReleased里做的状态清理是最容易忽略但对稳定性至关重要的动作。

3.2 连接获取与真正的HTTP请求发送

我用的是SimpleChannelPool作为基础池，再包一层公开的服务类。关键代码如下：

public class NettyHttpClient { private final EventLoopGroup workerGroup; private final SimpleChannelPool pool; public NettyHttpClient(String host, int port, int maxConnections) throws Exception { this.workerGroup = new NioEventLoopGroup(4); Bootstrap bootstrap = new Bootstrap(); bootstrap.group(workerGroup) .channel(NioSocketChannel.class) .remoteAddress(host, port) .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 3000) .option(ChannelOption.TCP_NODELAY, true) .option(ChannelOption.SO_KEEPALIVE, true); HttpClientChannelPoolHandler handler = new HttpClientChannelPoolHandler(); this.pool = new SimpleChannelPool(bootstrap, handler, new FixedChannelPool.AcquireTimeoutAction.FAIL(), maxConnections, maxConnections * 100); } public CompletableFuture<String> sendRequest(HttpRequest request) { CompletableFuture<String> result = new CompletableFuture<>(); // acquire是异步的，返回Future，这一步不会阻塞调用线程 pool.acquire().addListener((Future<Channel> future) -> { if (future.isSuccess()) { Channel channel = future.getNow(); // 把这次请求的上下文绑到Channel上，响应回来才能对应上 RequestContext ctx = new RequestContext(request, result); channel.attr(AttributeKey.valueOf("requestInfo")).set(ctx); channel.writeAndFlush(request); } else { result.completeExceptionally(future.cause()); } }); return result; } public void releaseChannel(Channel channel) { pool.release(channel); } }

这里有点绕的是FixedChannelPool的构造参数，第四个参数是最大连接数，第五个参数是pending acquire的队列容量。简单说就是池子里最多同时保持maxConnections条连接，超出后新来的请求会进入等待队列，等待队列满就直接失败。

关于获取连接，我实际项目中的心得是：pool.acquire()返回的Future里，回调代码是在EventLoop线程里执行的——具体是连接创建时绑定的那个EventLoop。所以你在回调里写channel.writeAndFlush(request)是线程安全的，根本不需要加锁。这是使用Netty连接池比自研连接管理省心太多的地方。

3.3 响应回调与请求关联

HTTP是请求-响应一一对应的协议，连接池里连接被并发借走后，回到的响应必须能找到当初发出的请求。Netty里最自然的做法是用AttributeKey在Channel上挂一个上下文对象：

public class HttpClientChannelHandler extends SimpleChannelInboundHandler<FullHttpResponse> { @Override protected void channelRead0(ChannelHandlerContext ctx, FullHttpResponse msg) { RequestContext context = ctx.channel().attr(AttributeKey.valueOf("requestInfo")).get(); if (context == null) { // 没有请求上下文就来响应，要么是服务端主动推送，要么是解析有问题，直接关连接 ctx.close(); return; } try { String body = msg.content().toString(CharsetUtil.UTF_8); context.getResult().complete(body); } finally { // 响应处理完，把上下文清了，连接释放回池子 ctx.channel().attr(AttributeKey.valueOf("requestInfo")).set(null); // 实际项目中，连接池的引用通过外部传入或者工厂方式持有 NettyHttpClient.this.releaseChannel(ctx.channel()); } } @Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { RequestContext context = ctx.channel().attr(AttributeKey.valueOf("requestInfo")).get(); if (context != null && !context.getResult().isDone()) { context.getResult().completeExceptionally(cause); } // 连接已经出异常，释放回池子没有意义，直接关掉 ctx.close(); } }

这里有个细微但很重要的设计：channelRead0里拿到的FullHttpResponse，其content()对应的ByteBuf归Handler管。如果同步转成字符串并且不再引用，就不用担心泄漏；但如果要异步传递，必须retain()或者拷贝一份。否则连接释放回池子时，ByteBuf已经被Release了，异步拿到的是一块已被回收的内存。

3.4 超时控制与释放的连接顺序

HTTP请求发出后，如果服务端一直不返回，不能无限等下去。我的做法是给每个请求设置独立的超时时间，用ctx.executor().schedule()在EventLoop上挂一个定时任务：

public class RequestContext { private final ScheduledFuture<?> timeoutFuture; public RequestContext(FullHttpRequest request, CompletableFuture<String> result, ChannelHandlerContext ctx, long timeoutMillis) { this.result = result; this.timeoutFuture = ctx.executor().schedule(() -> { if (!result.isDone()) { result.completeExceptionally(new TimeoutException("HTTP request timeout")); ctx.close(); // 超时后连接状态不可控，宁可关闭重建 } }, timeoutMillis, TimeUnit.MILLISECONDS); } public void cancelTimeout() { if (timeoutFuture != null) { timeoutFuture.cancel(false); } } }

超时处理的原则是：宁可关连接、也不要复用。因为超时发生时，服务端可能还在返回数据，这条连接上的字节流时序已经完全不可知了，复用只会让下个请求收到上个请求的残留响应。

4. 连接生命周期管理：空闲淘汰、健康检查与粘包边界

4.1 空闲连接怎么判定和淘汰

连接池里的连接如果长时间没人用，占着文件描述符和内存，对于高并发系统来说也是浪费。更糟的是，很多服务端网关（Nginx、云负载均衡器）会主动断开空闲连接，但客户端感知不到——直到下次真正写入数据时才发现连接已经死了，白白多了一次失败重试。

Netty的IdleStateHandler可以帮我们感知空闲事件。在HttpClientChannelPoolHandler的channelCreated里已经加了IdleStateHandler(15, 15, 0)，意思是读空闲15秒触发、写空闲15秒触发。我在自定义Handler的userEventTriggered里处理这个事件：

@Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent event = (IdleStateEvent) evt; switch (event.state()) { case READER_IDLE: case WRITER_IDLE: // 空闲了，判断这个Channel是否还在池里闲置着 if (ctx.channel().attr(AttributeKey.valueOf("requestInfo")).get() == null) { ctx.close(); // 空闲连接直接关掉，池子会淘汰掉它 } break; case ALL_IDLE: break; } } else { super.userEventTriggered(ctx, evt); } }

注意这里我只关“没有请求上下文”的Channel。如果一条连接上正好有请求在处理，读空闲15秒可能是因为服务端处理慢，直接关掉反而误杀了正在工作的连接。所以空闲淘汰必须结合“是否空闲”和“是否被借用”两个条件来判断。

4.2 服务端断开连接的感知与半死连接剔除

服务端断开连接时，客户端会收到channelInactive事件。在这个回调里要做的事是：把对应Channel从池里移除，而不是让它留在空闲队列里继续被后续请求拿走使用。

@Override public void channelInactive(ChannelHandlerContext ctx) { RequestContext context = ctx.channel().attr(AttributeKey.valueOf("requestInfo")).get(); if (context != null && !context.getResult().isDone()) { context.getResult().completeExceptionally(new IOException("Remote server closed the connection")); } // 通知连接池移除该Channel // 如果用的是FixedChannelPool，可以通过反射或者一层包装调removeChannel // 更推荐在池外维护一个ConcurrentHashMap<Channel, Boolean>做在线状态记录 }

最容易被忽略的情况是：服务端正常关闭时，如果客户端恰好没有写操作，TCP层不会立即感知，连接就停留在“半开”状态。这时候连接池里还存着它，下次acquire后写入数据，第一次写操作会触发异常或者直接超时。所以健康检查不能只靠被动事件，还要有主动探测。

4.3 主动健康检查的两种姿势

我的经验里，主动健康检查和请求分发有两条路线可以走。

第一条是“获取时检查”，连接被acquire出来之后、真正发请求之前，先发一个轻量的探测请求（比如HEAD请求或者一个极简GET），等到响应回来再发真实请求。缺点很明显：多一次RTT，相当于每个请求变慢了一拍。这个方案只适合低频低延迟要求的场景。

第二条是“定时巡检”，起一个后台线程或利用Netty的HashedWheelTimer，周期性地从空闲队列里拿连接，发送一个探测请求，成功就放回队列，失败就关闭并创建新连接。这个方案可以保持连接池里大部分连接都是活的，代价是有少量额外探测流量。

我个人更推荐第二条。实际配置时，巡检周期设在30秒到60秒之间比较稳妥，探测请求为GET /healthz这类轻量接口，超时设短一点，比如3秒。如果服务端没有健康检查接口，也可以直接做TCP层的探活——用Channel.isActive()判断加ctx.writeAndFlush一个HTTP的HEAD请求。其实isActive()只能判断本地socket状态，对网络中间设备断开的情况无能为力，真正有效的还是发一个字节看会不会触发异常。

4.4 再谈粘包拆包与响应错乱的关系

前面提到，Netty的HttpClientCodec会自动处理HTTP协议消息的粘包拆包。它的原理是：解析到\r\n\r\n即HTTP头部结束，然后根据Content-Length或Transfer-Encoding判断body边界，只有完整一个请求或响应才会向后传递。

这里想补充一个容易被忽略的细节。HttpClientCodec只能保证“HTTP消息边界正确”，但如果你的Pipeline里没加聚合器，后面的Handler一次可能只收到HttpResponse对象，还没收到完整的HttpContent，这时如果你把连接释放回池子，HttpContent剩余的字节还留在解码器缓冲区里，下一个请求复用这条连接后，解码器会先吐出上一次的残余数据——响应就串台了。

所以规则很简单：用Netty做HTTP Client连接池，Pipeline必须加HttpObjectAggregator，并且释放连接前必须确保FullHttpResponse已经处理完整。聚合器本质上就是把HttpResponse和后续的多个HttpContent拼装成一个完整的FullHttpResponse，这样连接上单次请求的语义边界非常清晰，粘包问题在协议解析层就解决了。

4.5 MySQL连接池热词带来的联想

热词里还有“mysql的数据库连接池”。MySQL连接池和HTTP连接池在思想上一脉相承：复用连接、控制并发、检测失效。但实现上差异很大：MySQL连接池管理的是一条“会话状态”的连接，跟事务、prepared statement绑定；HTTP连接池管理的是无状态或应用层自管理状态的TCP连接。所以HTTP连接池复用起来要大胆得多，不需要像数据库连接池那样做事务回滚、状态重置。

有个值得借鉴的点：数据库连接池里常用“最小空闲连接数”这个概念，HTTP连接池也可以做类似设计，维持最少N条空闲连接，避免流量洪峰来时瞬间建连导致延迟升高。Netty的FixedChannelPool本身没有这个能力，需要自己在release时检查空闲队列长度，低于阈值就预创建连接。

5. 完整参数配置与压测复盘

5.1 连接池参数配置明细

拿一个实际网关项目举例，服务端是单域名下的Nginx集群，客户端需要支撑峰值2万QPS。连接池参数我最终定成这样：

连接数配置有个经验值：Netty客户端线程数（EventLoop线程）通常设为核心线程数或者核心线程数×2，每条EventLoop线程绑定的连接数控制在100到200条，这样单线程上处理的事件循环不会被过多连接拖垮。上面2万QPS的场景，4个EventLoop线程、500条连接，平均每条连接每秒处理40个请求，HTTP/1.1串行下这个负载是合理的。

5.2 压测结果数据复盘

这个结果里最有价值的指标其实是“连接复用率”。压测开始时先预热连接池，请求全部走复用连接，新建连接只发生在连接被服务端断开后的补偿场景。对比Apache HttpClient的压测数据，相同条件下连接复用率能做到95%就很不错，差距主要来自:现成方案会在空闲淘汰、连接重建上做更多保守操作。Netty自研方案把连接状态的判定逻辑收敛在自定义Handler里，没有多余的状态机切换开销。

5.3 参数调优的“为什么”

很多人在配连接池时凭感觉拍脑袋。实际上每个参数背后都有明确的权衡逻辑。

最大连接数定太高，服务端负载增加且连接闲置率高，浪费资源；定太低，请求全部堆积在pending队列里，排队时间拉长。这里实际压过的数据是：连接数从500降到300后，TP99从21ms飙升到78ms，原因就是大量请求等acquire超时后直接失败重试。而连接数升到1000后，TP99反而涨到35ms，原因是新连接建立握手开销抵消了并发收益。

acquire超时时间定太短，流量毛刺期间请求容易直接失败；定太长，用户侧体验就是卡顿，且占着业务线程不放。我用3秒作为默认值，核心逻辑是最长请求RT是2秒，超时3秒可以判断为连接获取异常而非服务端慢。

6. 常见问题与排查实操

6.1 连接池耗尽导致请求大量超时

现象：QPS平稳但运行一段时间后突然大量超时，日志里出现“Failed to acquire a channel within timeout”。原因：连接池里的连接被泄漏了，或者服务端主动断开后客户端没有及时感知。acquire得到一条连接，发完请求后忘了release，池里的可用连接越来越少。排查思路：

• 第一步，把pool.acquire()和pool.release()两处代码打上日志，看借出和归还次数是否一致
• 第二步，看连接是否集中在少数EventLoop上，因为Channel绑定EventLoop后，release回池也是在那个EventLoop上执行
• 第三步，检查异常路径：exceptionCaught里如果只complete异常没有close连接，这条连接等于再也回不到池子

一个我在生产环境踩过的坑：exceptionCaught里确实调用了ctx.close()，但忘了在channelInactive里把Channel从池中移除。结果池子里存了一堆已经关闭的Channel，每次acquire都拿到一个半死连接，写入就报错。

6.2 ByteBuf泄漏问题

现象：Netty控制台输出LEAK: ByteBuf.release() was not called before it's garbage-collected。原因：FullHttpResponse的content()持有ByteBuf，如果只取字符串不释放，或者异步传递后没有release，就会泄漏。排查步骤：

• 启动参数加-Dio.netty.leakDetection.level=PARANOID，泄露检测级别调到最高
• 用ReferenceCountUtil.release(msg)或者在finally块里释放
• 确认HttpClientChannelPoolHandler.channelReleased里没有对ByteBuf的引用残留

实践中我习惯在channelRead0里立刻把ByteBuf转成字节数组或字符串，并释放原对象。如果业务必须异步使用响应体，就复制一份独立的ByteBuf并给新对象加引用计数。

6.3 服务端主动断开，客户端长时间无感知

现象：连接池里连接数量正常，请求偶发失败，错误是Connection reset by peer。原因：服务端或中间网络设备（Nginx、云LB）按自己的空闲策略关闭了连接，客户端没有及时收到FIN消息，连接处于半开状态。解决：靠前面说的定时健康巡检兜底。巡检周期不要设太长，30秒比较合适。另外ChannelOption.SO_KEEPALIVE虽然开启，但TCP KeepAlive默认探测周期是2小时，对HTTP层来说太慢了，不能作为空闲淘汰的主要手段。

6.4 粘包引起的响应解析错乱

现象：请求A返回的响应中混入了请求B的JSON内容，或者HttpObjectDecoder报Premature end of chunked coded message body。原因：Pipeline没加聚合器就直接把连接释放回池；或者聚合器设置的maxContentLength太小导致响应被截断。排查：

• 确认Pipeline顺序：HttpClientCodec→HttpObjectAggregator→ 自定义Handler
• 用日志把所有经过聚合器后的FullHttpResponse的headers()和byteBuf长度打印出来，对照服务端返回体确认边界
• 如果用的是HTTP/2，需要通过Http2FrameCodec+Http2MultiplexHandler处理，连接池的设计会复杂一层，本文的场景默认HTTP/1.1

NETTY本身协议层的粘包拆包相当可靠，只要结构正确，问题大概率出在业务代码对连接生命周期的破坏上，别太早怀疑Netty解析错了。

6.5 连接池中Channel意外变慢

现象：连接池整体QPS明明不高，但某些请求RT特别高，抓包发现客户端发出的请求迟迟没到服务端。原因：EventLoop线程被阻塞了。可能是自定义Handler里做了同步IO操作，比如在channelRead0里查数据库，这一个线程堵塞导致绑定在它上面的几十条连接全部排队。排查：在Handler里统计每个方法耗时，超过几十毫秒就要警惕。Netty事件循环线程绝不干重活，同步的IO都挪到业务线程池里执行。这也是为什么连接池配置时，EventLoop线程数和连接数一定要匹配——EventLoop线程数太少，连接再多也是排队串行处理。

最后，说一些实际的个人体会

搞HTTP Client连接池这件事，技术难度没有想象中那么大，最磨人的全在细节里。用Netty做客户端时，你既要把它当成网络框架——关注ByteBuf、关注Pipeline、关注事件循环，又要把它当成连接管理器——关注连接借用状态、关注异常路径、关注释放时机。早期版本我在release连接上吃过亏，一条连接里的响应没读完就还回池子，下个请求拿到串包数据，排查了很久才定位到是聚合器缺失导致的粒度问题。

后来我把这几条原则刻在脑门上：第一，连接池里的Channel必须是“干净状态”，凡是被复用前读取过任何残留数据的，一律淘汰重建。第二，异常路径和正常路径一样重要，错误回调里忘记关连接等于慢性泄漏。第三，任何超时设计都要比业务毛刺长一个量级，但不能长到让调用方失去耐心。按这套设计做下来的连接池模块，一直运行到现在都比较稳定，只在服务端大规模扩缩容时偶发重新建连的波动。

如果你也在做类似的事情，建议先别急着写完整实现，把一条连接的完整生命周期画出来，从创建、借用、发送请求、接收响应、释放、空闲淘汰到异常销毁，每一个状态都写清触发条件和动作。状态机理清楚了，连接池就成功了一半。剩下的，就是对Netty事件循环模型的敬畏和尊重了。