future模式通过分离发起操作与获取结果实现非阻塞等待：connect()立即返回future并异步注册系统调用，get()仅阻塞等待结果而非系统调用完成。
AsynchronousSocketChannel 的 connect() 方法返回 Future
Future 模式如何实现“非阻塞等待”
所谓“非阻塞等待”，本质是分离“发起操作”与“获取结果”两个阶段：
- 调用 connect(socketAddress) 时，底层向操作系统注册连接请求（如 Linux 的 aio_connect 或 epoll/kqueue 事件注册），然后立刻返回一个 Future 实例；
- 该 Future 封装了尚未发生的异步操作状态，内部由 AsynchronousChannelGroup 关联的线程池（如 DefaultThreadPool）在连接就绪或失败后设置结果；
- 调用 future.get() 才真正阻塞当前线程——但此时阻塞的是“等待结果”，而非“等待系统调用完成”，系统调用早已异步启动并交由内核/本地线程处理。
connect() 返回的 Future 的行为细节
Future
- get() 成功返回：说明 TCP 三次握手已完成，通道已进入 connected 状态，可立即调用 read()/write()；
- get(long, TimeUnit) 带超时：若指定时间内未连接成功（如目标不可达、防火墙拦截、SYN 超时），抛出 TimeoutException；
- get() 抛出 ExecutionException：包裹底层异常，如 UnresolvedAddressException（DNS 解析失败）、ConnectionRefusedException（目标端口无服务）、ClosedChannelException（通道被提前关闭）；
- Future 状态不可逆：一旦 completed 或 failed，多次调用 get() 均返回相同结果，不会重复触发连接过程。
与 CompletionHandler 模式的对比差异
Future 模式是同步等待风格，而 CompletionHandler 是纯异步回调风格。二者在 connect 阶段的核心区别在于控制流归属：
- Future：调用方主动拉取结果，适合逻辑线性、需顺序执行后续步骤的场景（如建立连接 → 发送登录包 → 等待响应）；
- CompletionHandler：由 AIO 线程池回调 completed() 或 failed()，调用方无需等待，适合高吞吐、事件驱动架构（如网关中批量发起连接并统一处理）；
- 注意：Future.get() 若在 IO 线程（如 AsynchronousChannelGroup 的工作线程）中调用，会造成该线程阻塞，影响整体吞吐，应避免在回调上下文中调用 get()。
实际使用中的关键注意事项
直接依赖 Future.get() 看似简单，但容易忽略几个隐含约束：
- 通道必须保持 open 状态：若在 future.get() 前调用了 channel.close()，Future 将以 ClosedChannelException 完成；
- 连接失败不自动重试：Future 只反映单次 connect 调用结果，重连需手动捕获异常后重新 open + connect；
- 超时判断依赖系统级连接超时：Future 超时仅限制等待时间，底层 TCP 连接本身的超时（如 75 秒 SYN 重传）仍由 OS 控制，Future 不会提前中断内核连接过程；
- 不建议在主线程长期阻塞等待：尤其在服务端，应结合 CompletableFuture 或反应式封装（如 Mono.fromFuture）提升响应性。
