Java NIO非阻塞连接需靠finishConnect()判断成败：connect()仅发起握手并立即返回false；OP_CONNECT就绪后必须调用finishConnect()，返回true才真正连通，否则持续等待或处理异常。
Java NIO 客户端在非阻塞模式下发起 TCP 连接，不能靠 connect() 返回 true 就认为连上了——它大概率会立刻返回 false，因为三次握手尚未完成。真正判断连接是否就绪、是否成功，靠的是 finishConnect() 方法，配合 SelectionKey.OP_CONNECT 事件轮询。
connect() 只是发起连接请求
SocketChannel.connect(SocketAddress) 在非阻塞模式下不会等待连接建立完成。它的作用只是：
- 向内核发送 SYN 包（触发 TCP 三次握手第一步）
- 立即返回
false（表示连接未完成），或true（极少见，仅当对端在同一台机器且内核快速返回 SYN+ACK） - 此时通道处于“正在连接中”（connecting）状态，但不可读、不可写
finishConnect() 才是连接成败的最终裁判
调用 finishConnect() 的前提，是该通道已注册到 Selector 并监听了 OP_CONNECT 事件，且 select() 返回该 key 处于就绪状态。此时必须调用 finishConnect() 来收尾：
- 若返回
true：说明三次握手已完成，连接成功，通道进入可读/可写状态 - 若返回
false：说明连接仍在进行中（比如只收到 SYN，还没等到 SYN+ACK），需继续等待下次 OP_CONNECT 就绪 - 若抛出
IOException（如 Connection refused、Timeout）：连接明确失败，应关闭通道并清理资源
典型处理流程不能漏掉三件事
实际编码中，一次非阻塞 connect 的完整闭环包含三个关键动作：
- 调用
channel.configureBlocking(false)，确保通道是非阻塞的 - 调用
channel.connect(addr)发起连接，并立即将其注册到Selector，关注OP_CONNECT - 在
select()循环中，一旦发现该 key 的isConnectable()为true，必须立刻调用finishConnect()判断结果，并根据返回值决定后续——成功则改注OP_READ，失败则关闭通道
为什么不能跳过 finishConnect() 直接读写？
即使 connect() 返回 true，也不代表应用层可以安全读写；而如果只等 OP_CONNECT 就绪却不调用 finishConnect()，Selector 会持续报告该 key 就绪（因为连接状态未被消费），造成 busy loop。只有 finishConnect() 被调用后，内核才真正将通道状态从 “connecting” 切换为 “connected”，Selector 才会停止重复通知 OP_CONNECT。
