应避免使用Scanner处理低延迟网络流，因其内置缓冲、同步阻塞、编码转换和行解析导致不可控延迟；推荐改用BufferedReader（封装超时读）或InputStream/SocketChannel字节级读取，并精简解码链路、控制缓冲大小、设置超时与禁用Nagle算法。
Scanner 本身不是为低延迟网络流读取设计的，它内置缓冲、同步阻塞、字符编码转换和行解析逻辑，这些都会引入不可控的延迟，尤其在实时性要求高的场景（如游戏指令流、传感器数据流、音视频控制信令）中容易成为瓶颈。
避免 Scanner 用于实时网络流
Scanner 的 nextLine()、nextInt() 等方法会等待完整分隔符（如换行符）到达才返回，期间可能阻塞数毫秒到数百毫秒；其内部缓冲区大小不可控，且不支持超时中断。一旦网络抖动或发送端未及时刷缓存，读取就会挂起。
- 改用
BufferedReader配合readLine(timeout)（需自行封装带超时的非阻塞读） - 更推荐直接使用
InputStream.read(byte[])或SocketChannel+Selector实现零拷贝、无缓冲、可中断的字节级读取 - 若协议是固定长度或含帧头（如 4 字节长度字段），应按字节流解析，而非依赖行分割
精简字符解码链路
网络流通常是原始字节，Scanner 默认用平台编码（如 GBK/UTF-8）做 InputStreamReader 转换，每轮读取都触发解码——这既耗时又易出错（乱码导致解析失败）。延迟常来自解码器等待完整字符边界。
- 明确指定编码：构造
InputStreamReader(in, StandardCharsets.UTF_8)，避免隐式查表 - 如变量值为纯 ASCII（数字、字母、下划线），可跳过解码，直接用
in.read()读字节后转(char)，省去 CharsetDecoder 开销 - 禁用自动 flush 检测：不要用
new Scanner(socket.getInputStream())，而应包装已配置好的BufferedInputStream
控制缓冲与超时行为
默认 Socket 输入流有操作系统级缓冲（通常 64KB），加上 Java 层 BufferedInputStream（默认 8KB），两层缓冲叠加会导致“已收到但未送达应用”的隐形延迟。
- 创建 Socket 后立即调用
socket.setSoTimeout(50)（单位毫秒），防止无限阻塞 - 用
new BufferedInputStream(socket.getInputStream(), 256)将缓冲设为小值（如 256 字节），减少滞留 - 对关键控制指令流，可关闭 TCP Nagle 算法：
socket.setTcpNoDelay(true)，强制小包即时发出
协议层优化建议
延迟不仅在读取端，更藏在协议设计里。例如用换行符分隔的文本协议，在高频率下发时极易因粘包/半包造成 Scanner 卡顿。
- 改用二进制协议：前 2 字节表示长度，后续为原始内容，解析快且确定
- 加入心跳帧或时间戳字段，便于客户端识别是否丢帧或延迟超标
- 服务端发送后主动调用
out.flush()，确保 Java 层缓冲不积压
