阻塞System.in.read导致Java进程退出耗时增加350ms的问题排查

我完全懂你遇到的这个头疼问题——明明主线程都跑完了，程序却拖着不退出，甚至用上System.exit()都好像没立刻生效，这背后其实是标准输入流的底层线程阻塞和资源清理逻辑在搞鬼。

为什么会出现延迟？ #

当你调用System.in.read()时，JVM会启动一个底层I/O线程来监听控制台输入。这个线程执行read()后会进入阻塞状态，等着用户输入内容。哪怕你的主线程已经执行完毕，JVM在退出前得先清理这些I/O资源，而这个清理过程会因为阻塞的I/O线程产生延迟——尤其在某些终端环境下，操作系统需要时间解绑和标准输入绑定的终端资源，这就是你看到那300ms左右耗时差的原因。

为什么interrupt/stop/System.exit没立刻起效？ #

• t.interrupt：阻塞的I/O线程是JVM底层创建的，你根本拿不到它的引用，没法直接中断；而且底层的read()属于不可中断的阻塞I/O，就算标记了线程中断，它也不会立刻退出阻塞状态。
• t.stop：这个方法早就被Java官方废弃了，而且同样，你找不到那个底层线程的引用，根本没法调用。
• System.exit(0)：理论上这个方法应该直接终止JVM，但实际中JVM退出前会执行关闭钩子（shutdown hooks），如果有钩子在等待I/O资源清理，就会拖慢退出速度；另外，操作系统层面的终端资源释放是JVM没法控制的，这部分也会产生延迟。

实用解决方案 #

这里有几个靠谱的解决方向：

• 主动关闭System.in流：在主线程结束前，手动调用System.in.close()，可以立刻中断底层的阻塞读取操作，让操作系统快速释放终端资源。示例代码：

  public class Foo {
      public static void main(String[] args) throws Exception {
          int input = System.in.read(); // 你的读取操作
          System.in.close(); // 提前关闭输入流，终止阻塞
          // 其他业务逻辑
      }
  }
  

  关闭流后，底层I/O线程会因为流关闭抛出IOException，进而快速终止，避免持续阻塞。

• 改用非阻塞方式读取输入：如果不需要同步等待用户输入，可以用NIO的非阻塞模式读取标准输入，这样线程不会长时间卡在等待上。示例代码：

  import java.nio.channels.Channels;
  import java.nio.channels.ReadableByteChannel;
  import java.nio.ByteBuffer;
  
  public class Foo {
      public static void main(String[] args) throws Exception {
          ReadableByteChannel channel = Channels.newChannel(System.in);
          ByteBuffer buffer = ByteBuffer.allocate(1024);
          channel.configureBlocking(false); // 设置非阻塞模式
          int bytesRead = channel.read(buffer); // 尝试读取，不会阻塞
          channel.close();
          // 后续业务逻辑
      }
  }
  

• 启动时重定向标准输入：如果你的程序根本不需要从控制台读取内容，可以启动时把标准输入重定向到空设备，让System.in.read()立刻返回-1，不会产生阻塞：

  # Linux/macOS 环境
  time java foo < /dev/null
  # Windows 环境
  time java foo < NUL
  

  这个方式适合不需要用户交互的批处理场景。

总结 #

核心问题就是阻塞式标准输入读取导致的操作系统终端资源释放延迟，只要从「中断阻塞读取」或者「避免阻塞读取」这两个方向入手，就能解决程序退出慢的问题。

内容的提问来源于stack exchange，提问作者Li Haoyi