serversocket.accept()卡住且一个连接占一个线程，是因为bio模型中accept()和read()默认阻塞，需为每个连接单独启线程；setsotimeout()仅实现限时阻塞，不解决线程模型缺陷；高并发应选nio。
为什么 ServerSocket.accept() 会卡住，且一个连接就占一个线程？
因为这是 BIO 的本质：每个客户端连接都必须由一个独立线程调用 socket.getInputStream().read() 或 serverSocket.accept()，而这两个操作默认都是阻塞的。线程在没数据可读、没新连接来时，就停在那不动，CPU 不会轮询，也不让出执行权。
常见错误现象：accept() 长时间不返回；加了 100 个客户端后服务直接 OOM（堆外内存或线程数超限）；read() 在客户端断连但未发 FIN 时无限等待。
- 必须手动为每个
Socket启一个线程，否则后续连接无法被接收 -
ServerSocket构造时传入的backlog参数（如new ServerSocket(8080, 50)）只控制内核等待队列长度，不是最大连接数 - 没有超时机制的话，
read()可能永远等下去——哪怕客户端已拔网线 - Java 早期（JDK 1.4 前）没 NIO，BIO 是唯一选择；现在纯用它写高并发服务，基本等于给自己挖坑
setSoTimeout() 能解决阻塞问题吗？
能，但只解一半：它让 read() 和 accept() 从“永久阻塞”变成“限时阻塞”，抛出 SocketTimeoutException 而不是卡死。但它不改变“一个连接一个线程”的模型，也无法避免线程创建开销和上下文切换成本。
使用场景：内部低频管理端口（如健康检查接口）、调试工具、教学演示——对吞吐和连接数没要求时可用。
立即学习“Java免费学习笔记（深入）”；
-
serverSocket.setSoTimeout(5000)对accept()生效，超时后抛SocketTimeoutException -
socket.setSoTimeout(10000)对后续所有inputStream.read()生效，每次读超过 10 秒就中断 - 注意：超时重试逻辑得自己写，
read()返回 -1 表示流结束，返回 0 不代表没数据，可能是缓冲区空，得继续读 - Windows 下
setSoTimeout()对accept()支持不稳定，某些 JDK 版本会忽略
BIO 模型下，怎么判断客户端是不是真断开了？
不能只靠 read() 返回 -1。TCP 连接关闭有四次挥手，但网络异常（如客户端崩溃、NAT 超时、防火墙静默丢包）会导致连接处于半开状态：服务端还认为连着，但客户端早已失联。
真实表现：read() 一直阻塞或返回 0；write() 突然抛 IOException: Broken pipe；心跳包无响应但 isConnected() 仍返回 true。
-
socket.isClosed()和socket.isConnected()都是本地状态标记，不发起网络探测，不可信 - 唯一可靠方式是开启 TCP keepalive：
socket.setKeepAlive(true)，但 OS 层默认探测间隔长（Linux 通常 2 小时），业务等不起 - 更实用的是应用层心跳：固定间隔发小包（如
"PING"），对方回"PONG"，连续几次无响应就主动close() - 别在
read()阻塞时等心跳——得用单独线程或Selector配合，BIO 本身不支持多路复用
什么时候还值得用 BIO？
当连接数稳定、低频、生命周期长，且你明确不需要横向扩展时。比如公司内网的配置下发服务，每天就几十次请求，运维人员手动 telnet 调试，代码越直白越好维护。
但只要出现以下任一情况，就该换方案：maxThreads > 200、需要支撑移动端长连接、部署在容器里受内存限制、要对接 Prometheus 做连接数监控。
- Spring Boot 默认内嵌 Tomcat，其
protocol="HTTP/1.1"在低版本中就是 BIO，高并发下容易线程耗尽，需显式切到org.apache.coyote.http11.Http11NioProtocol - Netty、Undertow、Jetty 的 NIO 实现，底层都绕过了
ServerSocket.accept()的线性阻塞，这才是现代 Java 网络服务的起点 - BIO 不是“过时技术”，而是“特定约束下的合理选择”——问题不在它本身，而在人忘了问：我的连接规模、延迟容忍、运维能力，真的匹配这个模型吗？
