setSoTimeout() 不控制 connect() 超时，仅作用于 read()/write()；连接超时需用 connect(addr, timeout) 或构造函数；SO_KEEPALIVE 响应慢且依赖系统配置；缓冲区设置受内核限制且须在 connect 前调用；Windows 与 Linux 在 SO_LINGER、SO_RCVBUF 等行为上存在关键差异。
Socket.setSoTimeout() 为什么没让 connect() 超时
setSoTimeout() 只控制 read() 和 write() 阻塞，对 connect() 完全无效。很多人配了它却发现连接卡死几十秒，就是因为混淆了“读写超时”和“连接超时”两个概念。
- 连接阶段必须用
Socket(int, int)构造函数或connect(SocketAddress, int)的 timeout 参数，比如socket.connect(addr, 3000) -
setSoTimeout(3000)是告诉系统：后续每次inputStream.read()最多等 3 秒，超时抛SocketTimeoutException - 如果服务端 SYN 包丢了、防火墙拦截、路由黑洞，
connect()会走系统默认重传逻辑（Linux 通常 21 秒），setSoTimeout()压根不参与
SO_KEEPALIVE 真的能及时发现断连吗
开了 setKeepAlive(true) 不代表 5 秒就能检测到对端宕机。它依赖操作系统底层的保活机制，默认间隔长、响应慢，且无法覆盖所有断连场景。
- Linux 默认 keepalive 起始时间是 7200 秒（2 小时），之后每 75 秒探测一次，连续 9 次失败才判定断连 —— 整个过程可能耗时 18 分钟
- Java 层无法直接设置 keepalive 时间，得靠系统级配置（如
/proc/sys/net/ipv4/tcp_keepalive_time），容器环境还常被隔离掉 - 它只在连接空闲时触发；如果应用层还在持续发数据，keepalive 探测根本不会启动
- 更可靠的做法是应用层加心跳包 +
setSoTimeout()配合，而不是只依赖SO_KEEPALIVE
SO_RCVBUF 和 SO_SNDBUF 设置后为啥没生效
调用 setReceiveBufferSize() 或 setSendBufferSize() 后，实际缓冲区大小可能被系统截断、放大或忽略，尤其在 Linux 上受内核参数强约束。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- Linux 有硬限制：
/proc/sys/net/core/rmem_max和/proc/sys/net/core/wmem_max，超过就自动降为该值 - 设置太小（如
setReceiveBufferSize(1024)）可能被内核向上对齐到最小页大小（通常 4KB） - 必须在
connect()之前调用，连接建立后再设会被忽略（部分 JDK 版本静默失败） - UDP
DatagramSocket同样适用这些规则，但 TCP 的SO_RCVBUF还会影响滑动窗口通告值，间接影响吞吐
Windows 和 Linux 在 SocketOptions 上的关键差异
同一段设置 SO_KEEPALIVE 或 SO_LINGER 的代码，在 Windows 和 Linux 上行为可能完全不同，尤其是超时表现和错误码。
立即学习“Java免费学习笔记（深入）”；
- Windows 的
SO_LINGER默认开启强制关闭（linger.l_onoff = 1, l_linger = 0），而 Linux 默认是优雅关闭；这会导致close()后立即发 RST，对方收不到 FIN - Linux 对
SO_RCVBUF有自动调优（net.ipv4.tcp_rmem），Windows 则基本按你设的值来，但上限更低 -
connect()超时在 Windows 上更接近设定值，Linux 因 TCP 重传策略更保守，实际耗时浮动大，尤其在网络抖动时 - 跨平台部署时，别假设
setSoTimeout(5000)就真等于“5 秒必断”，得结合 OS 网络栈实测
