面试官问：为什么 Java 线程没有 Running 状态？一下被问懵！

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

显然，10-20ms 对人而言是很快的，

不计切换开销（每次在1ms 以内），相当于1秒内有50-100次切换。

事实上时间片经常没用完，线程就因为各种原因被中断，实际发生的切换次数还会更多。

也这正是**单核 *CPU 上实现所谓的“**并发*（concurrent）”的基本原理，但其实是快速切换所带来的假象

这有点类似一个手脚非常快的杂耍演员可以让好多个球同时在空中运转那般。

时间分片也是可配置的，如果不追求在多个线程间很快的响应，也可以把这个时间配置得大一点，以减少切换带来的开销。

如果是多核CPU，才有可能实现真正意义上的并发，这种情况通常也叫并行（pararell），不过你可能也会看到这两词会被混着用，这里就不去纠结它们的区别了。

通常，Java的线程状态是服务于监控的，如果线程切换得是如此之快，那么区分 ready 与 running 就没什么太大意义了。

当你看到监控上显示是 running 时，对应的线程可能早就被切换下去了，甚至又再次地切换了上来，也许你只能看到 ready 与 running 两个状态在快速地闪烁。

当然，对于精确的性能评估而言，获得准确的 running 时间是有必要的。

现今主流的 JVM 实现都把 Java 线程一一映射到操作系统底层的线程上，把调度委托给了操作系统，我们在虚拟机层面看到的状态实质是对底层状态的映射及包装。

JVM 本身没有做什么实质的调度，把底层的 ready 及 running 状态映射上来也没多大意义，因此，统一成为runnable 状态是不错的选择。

我们将看到，Java 线程状态的改变通常只与自身显式引入的机制有关。

当I/O阻塞时

=======

我们知道传统的I/O都是阻塞式（blocked）的，原因是I/O操作比起cpu来实在是太慢了，可能差到好几个数量级都说不定。

如果让 cpu 去等I/O 的操作，很可能时间片都用完了，I/O 操作还没完成呢，不管怎样，它会导致 cpu 的利用率极低。

所以，解决办法就是：一旦线程中执行到 I/O 有关的代码，相应线程立马被切走，然后调度 ready 队列中另一个线程来运行。

这时执行了 I/O 的线程就不再运行，即所谓的被阻塞了。它也不会被放到调度队列中去，因为很可能再次调度到它时，I/O 可能仍没有完成。

线程会被放到所谓的等待队列中，处于上图中的 waiting 状态：

当然了，我们所谓阻塞只是指这段时间 cpu 暂时不会理它了，但另一个部件比如硬盘则在努力地为它服务。

cpu 与硬盘间是并发的，如果把线程视作为一个 job，这一 job 由 cpu 与硬盘交替协作完成，当在 cpu 上是 waiting 时，在硬盘上却处于 running，只是我们在操作系统层面讨论线程状态时通常是围绕着 cpu 这一中心去述说的。

而当 I/O 完成时，则用一种叫中断（interrupt）的机制来通知 cpu：

也即所谓的“中断驱动（interrupt-driven）”，现代操作系统基本都采用这一机制。

某种意义上，这也是控制反转（IoC）机制的一种体现，cpu不用反复去询问硬盘，这也是所谓的“好莱坞原则”—Don’t call us, we will call you.好莱坞的经纪人经常对演员们说：“别打电话给我，（有戏时）我们会打电话给你。”

在这里，硬盘与 cpu 的互动机制也是类似，硬盘对 cpu 说：”别老来问我 IO 做完了没有，完了我自然会通知你的“

当然了，cpu 还是要不断地检查中断，就好比演员们也要时刻注意接听电话，不过这总好过不断主动去询问，毕竟绝大多数的询问都将是徒劳的。

cpu 会收到一个比如说来自硬盘的中断信号，并进入中断处理例程，手头正在执行的线程因此被打断，回到 ready 队列。而先前因 I/O 而waiting 的线程随着 I/O 的完成也再次回到 ready 队列，这时 cpu 可能会选择它来执行。

另一方面，所谓的时间分片轮转本质上也是由一个定时器定时中断来驱动的，可以使线程从 running 回到 ready 状态：

比如设置一个10ms 的倒计时，时间一到就发一个中断，好像大限已到一样，然后重置倒计时，如此循环。

与 cpu 正打得火热的线程可能不情愿听到这一中断信号，因为它意味着这一次与 cpu 缠绵的时间又要到头了……奴为出来难，何日君再来？

现在我们再看一下 Java 中定义的线程状态，嘿，它也有 BLOCKED（阻塞），也有 WAITING（等待），甚至它还更细，还有TIMED_WAITING：

现在问题来了，进行阻塞式 I/O 操作时，Java 的线程状态究竟是什么？是 BLOCKED？还是 WAITING？

可能你已经猜到，既然放到 RUNNABLE 这一主题下讨论，其实状态还是 RUNNABLE。我们也可以通过一些测试来验证这一点：

@Test

public void testInBlockedIOState() throws InterruptedException {

Scanner in = new Scanner(System.in);

// 创建一个名为“输入输出”的线程t

Thread t = new Thread(new Runnable() {

@Override

public void run() {

try {

// 命令行中的阻塞读

String input = in.nextLine();

System.out.println(input);

} catch (Exception e) {

e.printStackTrace();

} finally {

IOUtils.closeQuietly(in);

}

}, “输入输出”); // 线程的名字

// 启动

t.start();

// 确保run已经得到执行

Thread.sleep(100);

// 状态为RUNNABLE

assertThat(t.getState()).isEqualTo(Thread.State.RUNNABLE);

}

在最后的语句上加一断点，监控上也反映了这一点：

网络阻塞时同理，比如socket.accept，我们说这是一个“阻塞式(blocked)”式方法，但线程状态还是 RUNNABLE。

@Test

public void testBlockedSocketState() throws Exception {

Thread serverThread = new Thread(new Runnable() {

@Override

public void run() {

ServerSocket serverSocket = null;

try {

serverSocket = new ServerSocket(10086);

while (true) {

// 阻塞的accept方法

Socket socket = serverSocket.accept();

// TODO

}

} catch (IOException e) {

e.printStackTrace();

} finally {

try {

serverSocket.close();

} catch (IOException e) {

e.printStackTrace();

}

}, “socket线程”); // 线程的名字

serverThread.start();

// 确保run已经得到执行

Thread.sleep(500);

// 状态为RUNNABLE

assertThat(serverThread.getState()).isEqualTo(Thread.State.RUNNABLE);

}

监控显示：

当然，Java 很早就引入了所谓 nio（新的IO）包，至于用 nio 时线程状态究竟是怎样的，这里就不再一一具体去分析了。

至少我们看到了，进行传统上的 IO 操作时，口语上我们也会说“阻塞”，但这个“阻塞”与线程的 BLOCKED 状态是两码事！

如何看待RUNNABLE状态？

===============

首先还是前面说的，注意分清两个层面：

最后：学习总结——MyBtis知识脑图（纯手绘xmind文档）

学完之后，若是想验收效果如何，其实最好的方法就是可自己去总结一下。比如我就会在学习完一个东西之后自己去手绘一份xmind文件的知识梳理大纲脑图，这样也可方便后续的复习，且都是自己的理解，相信随便瞟几眼就能迅速过完整个知识，脑补回来。下方即为我手绘的MyBtis知识脑图，由于是xmind文件，不好上传，所以小编将其以图片形式导出来传在此处，细节方面不是特别清晰。但可给感兴趣的朋友提供完整的MyBtis知识脑图原件（包括上方的面试解析xmind文档）