InputStream.read() 会阻塞是因为它是同步阻塞调用，需等待有数据可读、流被关闭或到达末尾才返回；在TCP或串口等无明确EOF的场景中，若对端不关闭输出，read()将一直挂起。
InputStream.read() 为什么会阻塞
InputStream 的 read() 方法本质是同步阻塞调用。它不会主动轮询或超时退出，而是等待三种情况之一发生才返回：有数据可读、流被明确关闭（如调用 shutdownOutput() 或对方进程退出）、或到达流末尾（如文件读完）。在 TCP 或串口这类无明确“结束信号”的通信场景中，只要对端不关闭输出、不发 EOF、也不抛异常，read() 就会一直挂起，线程卡住不动。
常见阻塞场景与对应解法
不同输入源的阻塞逻辑差异大，需分类处理：
-
文件读取（FileInputStream）：天然带 EOF，读到末尾自动返回 -1，一般不阻塞；但若误用
while ((len = in.read(buf)) != -1)且未正确关闭流，可能因异常掩盖导致逻辑卡死。 -
TCP Socket 输入流：没有隐式结束标记。客户端写完数据后若不调用
socket.shutdownOutput()，服务端read()会持续等待，永不返回 -1。 -
串口通信（SerialPort.getInputStream）：数据分批到达、速率不稳定，
read(buf)可能只读到部分帧，甚至等不到完整协议包就陷入阻塞。 - HTTP 响应流（HttpURLConnection.getInputStream）：服务器未发送 Content-Length 或 Transfer-Encoding: chunked 时，客户端无法预判长度，容易在最后几字节处阻塞。
绕过阻塞的实用策略
不依赖“等 -1”这种被动判断，改为主动控制读取行为：
-
设置 socket 超时：调用
socket.setSoTimeout(5000)，让read()在 5 秒无数据时抛出SocketTimeoutException，捕获后可重试、跳过或断连处理。 -
结合 available() 预判：在串口或低速设备中，先调
in.available() > 0再读，避免盲目调用read()；注意该方法仅表示当前缓冲区有多少字节，不能替代协议解析。 - 按协议约定长度读取：例如前 4 字节为 int 表示后续数据长度，先读够 4 字节再循环读满指定字节数，避免无限等待。
-
用独立线程 + 中断机制：将
read()放入子线程，在主线程可控超时后调用thread.interrupt()，并在 read 前检查Thread.interrupted()提前退出。
典型错误写法与修正对比
错误写法（服务器端易卡死）：
while ((len = in.read(buf)) != -1) { process(buf, len); }
问题：TCP 场景下，客户端未 shutdownOutput，read() 永不返回 -1，循环卡住。
修正方向（三选一）：
- 客户端发送完立即执行
socket.shutdownOutput()； - 服务端加超时：
socket.setSoTimeout(15000)，并用 try-catch 捕获超时异常； - 改用定长/帧头帧尾协议，读到完整帧即处理，不依赖 -1 判断流结束。
