System.in.read()是阻塞式字节输入，线程会挂起直至用户按回车或流关闭；它不处理缓冲区残留、不支持多字节字符，需手动清空回车符等残留字节，且不可在GUI或服务端主线程直接使用。
System.in.read() 会一直等待用户输入，直到按下回车（或流被关闭），这是它最核心的阻塞表现。 它底层调用的是操作系统级别的输入流，没有输入数据时线程就停在那，不往下走，也不抛异常，更不会返回默认值。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
为什么 read() 看似“卡住”？
因为 System.in 是一个面向字节的阻塞式输入流，其 read() 方法在缓冲区为空且无 EOF 信号时，会挂起当前线程，交出 CPU 控制权，直到： • 键盘敲入内容并按回车（多数终端会行缓冲，即回车才把整行提交给 JVM） • 输入流被外部关闭（如重定向时管道断开） • 发生 I/O 异常（如底层设备故障，极少见）
nextLine()、nextInt() 等 Scanner 方法也阻塞吗？
是的，但阻塞逻辑略有不同： • Scanner.nextLine() 阻塞到读到换行符（\n 或 \r\n）为止，包括空行 • Scanner.nextInt() 阻塞到能解析出一个合法整数——它会跳过前面空白，但若输入是 "abc"，它不会消费该字符，而是留着，下次调用仍会卡在这儿 • 所有 Scanner 的 nextXxx() 方法都依赖 underlying stream（即 System.in）的阻塞行为，只是加了缓存和解析逻辑
如何避免“假死”？实际开发中要注意什么
• 不要在 GUI 或服务端主线程直接用 System.in —— 它会让整个界面或请求线程停摆 • 若必须交互式读取，建议单独起线程，并配合 BufferedReader + InputStreamReader 提升效率（比 Scanner 轻量） • 测试时注意 IDE 终端行为差异：IntelliJ 默认支持回车触发，Eclipse 某些版本需手动启用“Console input”选项 • 用 try-with-resources 包裹 Scanner 或 BufferedReader，防止资源泄漏；但别对 System.in 调用 close()，否则后续读取全失效
