大连微信网站开发,网站建设学什么语言,携程的网站建设项目规划书,公司网站做的一样算不算侵权点击上方“占小狼的博客”#xff0c;选择“设为星标“本文阅读时间大约4分钟。来源#xff1a;https://dwz.cn/dLRLBZabJava虚拟机层面所暴露给我们的状态#xff0c;与操作系统底层的线程状态是两个不同层面的事。具体而言#xff0c;这里说的 Java 线程状态均来自于 Thr… 点击上方“占小狼的博客”选择“设为星标“本文阅读时间大约4分钟。来源https://dwz.cn/dLRLBZabJava虚拟机层面所暴露给我们的状态与操作系统底层的线程状态是两个不同层面的事。具体而言这里说的 Java 线程状态均来自于 Thread 类下的 State 这一内部枚举类中所定义的状态什么是 RUNNABLE直接看它的 Javadoc 中的说明一个在 JVM 中执行的线程处于这一状态中。(A thread executing in the Java virtual machine is in this state.)而传统的进(线)程状态一般划分如下注这里的进程指早期的单线程进程这里所谓进程状态实质就是线程状态。那么 runnable 与图中的 ready 与 running 区别在哪呢与传统的ready状态的区别更具体点javadoc 中是这样说的处于 runnable 状态下的线程正在 Java 虚拟机中执行但它可能正在等待来自于操作系统的其它资源比如处理器。A thread in the runnable state is executing in the Java virtual machine but it may be waiting for other resources from the operating system such as processor.显然runnable 状态实质上是包括了 ready 状态的。甚至还可能有包括上图中的 waiting 状态的部分细分状态在后面我们将会看到这一点。与传统的running状态的区别有人常觉得 Java 线程状态中还少了个 running 状态这其实是把两个不同层面的状态混淆了。对 Java 线程状态而言不存在所谓的running 状态它的 runnable 状态包含了 running 状态。我们可能会问为何 JVM 中没有去区分这两种状态呢现在的时分(time-sharing)多任务(multi-task)操作系统架构通常都是用所谓的“时间分片(time quantum or time slice)”方式进行抢占式(preemptive)轮转调度(round-robin式)。更复杂的可能还会加入优先级(priority)的机制。这个时间分片通常是很小的一个线程一次最多只能在 cpu 上运行比如10-20ms 的时间(此时处于 running 状态)也即大概只有0.01秒这一量级时间片用后就要被切换下来放入调度队列的末尾等待再次调度。(也即回到 ready 状态)注如果期间进行了 I/O 的操作还会导致提前释放时间分片并进入等待队列。又或者是时间分片没有用完就被抢占这时也是回到 ready 状态。这一切换的过程称为线程的上下文切换(context switch)当然 cpu 不是简单地把线程踢开就完了还需要把被相应的执行状态保存到内存中以便后续的恢复执行。显然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。我们也可以通过一些测试来验证这一点Testpublic 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。Testpublic 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状态首先还是前面说的注意分清两个层面虚拟机是骑在你操作系统上面的身下的操作系统是作为某种资源为满足虚拟机的需求而存在的当进行阻塞式的 IO 操作时或许底层的操作系统线程确实处在阻塞状态但我们关心的是 JVM 的线程状态。JVM 并不关心底层的实现细节什么时间分片也好什么 IO 时就要切换也好它并不关心。前面说到“处于 runnable 状态下的线程正在* Java 虚拟机中执行但它可能正在等待*来自于操作系统的其它资源比如处理器。”JVM 把那些都视作资源cpu 也好硬盘网卡也罢有东西在为线程服务它就认为线程在“执行”。你用嘴用手还是用什么鸟东西来满足它的需求它并不关心~处于 IO 阻塞只是说 cpu 不执行线程了但网卡可能还在监听呀虽然可能暂时没有收到数据就好比前台或保安坐在他们的位置上可能没有接待什么人但你能说他们没在工作吗所以 JVM 认为线程还在执行。而操作系统的线程状态是围绕着 cpu 这一核心去述说的这与 JVM 的侧重点是有所不同的。前面我们也强调了“Java 线程状态的改变通常只与自身显式引入的机制有关”如果 JVM 中的线程状态发生改变了通常是自身机制引发的。比如 synchronize 机制有可能让线程进入BLOCKED 状态sleepwait等方法则可能让其进入 WATING 之类的状态。它与传统的线程状态的对应可以如下来看RUNNABLE 状态对应了传统的 ready running 以及部分的 waiting 状态。近期热文 整理了一些 IDEA 中比较骚的技巧7年Java后端被淘汰一路北漂辛酸史Java8 的这个特性用起来真的很爽最后分享一份面试宝典《Java核心知识点整理.pdf》覆盖了JVM、锁、高并发、反射、Spring原理、微服务、Zookeeper、数据库、数据结构等等。获取方式点“在看”关注公众号并回复 666 领取更多内容陆续奉上。明天见(ω)♡
