必须等op_connect就绪后调用finishconnect()，因为它是selector通知应用层“内核已完成tcp握手或给出明确失败结论”的唯一可靠信号；此前调用会返回false或异常，无法获取真实连接结果。
在使用 Java NIO 的 SocketChannel 进行非阻塞连接时，finishConnect() 必须在 OP_CONNECT 就绪事件触发后调用，且仅调用一次；它不负责发起连接，而是确认内核已完成 TCP 三次握手，并返回连接结果（成功或失败）。
为什么必须等 OP_CONNECT 事件才能调用 finishConnect()
SocketChannel.connect() 在非阻塞模式下会立即返回 false，表示连接尚未完成，此时操作系统正在后台进行 SYN 发送与握手流程。JVM 不会主动轮询连接状态，而是依赖 Selector 通过 OP_CONNECT 通知应用层“连接尝试已有结论”。若在无该事件时提前调用 finishConnect()，它会直接返回 false（未完成），既无意义，也可能掩盖真实错误。
- 只有当 Selector 检测到底层 socket 的连接状态发生变化（如收到 SYN-ACK 或 RST），才会将该 channel 的
OP_CONNECT标记为就绪 - 这是唯一可靠的信号：内核已更新 socket 状态，可安全查询结果
- 过早调用相当于“问一个还没收到回音的人结果”，必然得不到有效反馈
finishConnect() 实际做了什么
它本质是封装了系统调用 getsockopt(..., SO_ERROR)，用于读取 socket 的错误码（errno）。若为 0，说明三次握手成功；否则返回对应异常（如 Connection refused、Timeout 等）。
- 成功时返回
true，channel 进入可读/可写状态，后续可注册OP_READ/OP_WRITE - 失败时返回
false，但需捕获IOException（例如调用后立刻getRemoteAddress()可能抛出 ClosedChannelException） - 它不重试、不重连、不修改 socket 状态，只是“查看结果”的原子操作
典型使用模式与常见陷阱
标准流程是：注册 OP_CONNECT → Selector.select() → 遍历 selectedKeys → 对就绪的 connect channel 调用 finishConnect() → 根据返回值处理成功或失败分支。
- 不要在每次 select 循环中对所有已 connect 的 channel 反复调用
finishConnect()；一旦成功，再次调用会抛NotYetConnectedException - 不要忽略失败后的清理：调用
close()并移除 key，否则该 channel 会持续触发OP_CONNECT就绪（因 socket 处于 error 状态） - 注意 Linux 下的“快速失败”行为：若目标端口关闭，SYN 后很快收到 RST，
OP_CONNECT会迅速就绪，finishConnect()返回false并抛异常
如何验证三次握手是否真正完成
finishConnect() 返回 true 是 JVM 层面对“连接建立成功”的最终确认，但它本身不抓包。如需验证底层是否完成三次握手，需结合网络工具：
- 用
netstat -an | grep :port查看本地 socket 是否处于ESTABLISHED状态 - 用
tcpdump抓包观察是否有完整的 SYN → SYN-ACK → ACK 流程 - 注意：
finishConnect()返回 true 与ESTABLISHED状态严格对应，二者是同一内核事件的两种表现
