SocketTimeoutException 到底是哪个超时触发的
它只管读超时（SO_TIMEOUT），和连接超时（connect() 的 timeout）完全无关。很多人一看到 SocketTimeoutException 就去调 setConnectTimeout()，结果毫无作用——那是 HttpURLConnection 或 OkHttpClient 里的方法，底层 Socket 自己根本不认这个。
常见错误现象：SocketTimeoutException: Read timed out 持续出现，但 setConnectTimeout(5000) 加了也没用；或者连接很快成功，但后续读响应卡住 30 秒才爆这个异常。
-
Socket实例需显式调用setSoTimeout(int)才生效，不设就是无限等待 -
HttpURLConnection默认不启用读超时，必须手动setReadTimeout(10000) - Apache HttpClient 4.x 里对应的是
RequestConfig.setSocketTimeout()，不是setConnectionTimeout()
OkHttpClient 怎么避免漏掉 socket timeout
OkHttpClient 默认 socket timeout 是 10 秒，但这个值容易被中间层覆盖。比如你用 new OkHttpClient.Builder().connectTimeout(30, TimeUnit.SECONDS) 却没设 readTimeout，那读超时还是沿用默认 10 秒——看似设了连接超时，实际读阶段仍可能在 10 秒后崩出 SocketTimeoutException。
使用场景：调第三方 HTTP 接口，对方响应慢但连接快，日志里反复出现 java.net.SocketTimeoutException: timeout（注意 OkHttp 报错信息没写 “Read timed out”，就一个 timeout）。
立即学习“Java免费学习笔记（深入）”；
- 务必显式设置
readTimeout(15, TimeUnit.SECONDS)，别依赖默认值 - 如果接口有长轮询或流式响应，
readTimeout要大于单次数据块间隔，否则会误杀 - 配合
call.timeout()可覆盖全局 readTimeout，适合单次请求特殊处理
Spring RestTemplate 的 timeout 配置陷阱
RestTemplate 本身不持超时配置，全靠底层 ClientHttpRequestFactory。用 HttpComponentsClientHttpRequestFactory 时，setConnectTimeout() 和 setReadTimeout() 看似直观，但一旦换成 SimpleClientHttpRequestFactory（默认），这两个方法直接被忽略——它底层用 HttpURLConnection，必须通过 setOutputStreaming(false) + 手动 cast 到 HttpURLConnection 去设，非常隐蔽。
性能影响：Apache HttpClient 默认开启连接池，setReadTimeout() 不影响复用；而 SimpleClientHttpRequestFactory 每次都新建连接，超时设太短会导致频繁重连。
- 生产环境一律用
HttpComponentsClientHttpRequestFactory，避免 Simple 工厂的 timeout 失效问题 - 检查是否误用了
new SimpleClientHttpRequestFactory()，尤其在 Spring Boot 2.6+ 默认切换过工厂实现 -
setReadTimeout()单位是毫秒，别传 30 当成 30 秒（应为 30000）
自定义 Socket 连接时怎么防住半开连接
单纯设 setSoTimeout() 只能解决“等响应等太久”，对服务端已断连但本地 TCP 状态还显示 ESTABLISHED 的半开连接无效。这种情况下 read() 可能一直阻塞，直到 OS TCP keepalive 触发（Linux 默认 2 小时），远超业务容忍范围。
容易踩的坑：以为 setSoTimeout(5000) 就万无一失，结果压测时大量连接卡在 READ 状态不释放，最终耗尽线程或文件描述符。
- 必须同时开启 TCP keepalive：
socket.setKeepAlive(true)，再配合系统级参数（如/proc/sys/net/ipv4/tcp_keepalive_time）缩短探测间隔 - 对关键长连接，应用层加心跳帧（如发送
"PING"并 expect"PONG"），超时未响应则主动 close -
SocketChannel场景下，用configureBlocking(false)+Selector可精细控制读超时，但复杂度陡增，普通 HTTP 客户端没必要
真正麻烦的从来不是设哪个 timeout 参数，而是搞清哪一层在管哪段耗时、以及连接断开后状态同步的延迟有多不可控。
