我想这次我真的理解了 JavaScript 的单线程机制

今天面试的时候被问到一个问题,是关于 JS 异步的。当时我脑海中闪过了一个单线程的概念,但却没有把真正的原理阐述清楚。所以回来特意重新回顾了前面单线程和异步相关的一些知识点。

虽然之前学习的时候也接触了单线程模型相关的东西,但当时理解得并不是很清楚和明白。所以这道面试题也没有给出一语中的的答案。重新阅读阮一峰的 《JavaScript 运行机制详解》和我之前写的《setTimeout 异步与回调》之后。我决定重新写一篇博客来更加白话的总结 JS 的单线程机制和异步。

重演历史 - 为什么 JS 是单线程

当我们打开一个页面,页面的 JS 会去执行。从系统层面来说,他是单线程的去执行。换句话讲系统中只有一个线程去处理整个页面的渲染(代码的执行)。为什么会这样呢?因为简单,因为 JS 很早就被发明出来了,浏览器也是。那个时候考虑的第一件事,是功能简单。试想一下如果是多线程,一个处理页面渲染 DOM 操作,另外的线程也处理,就会出现混乱。因为搞不清楚谁做了什么,做到什么程度了。但如果只有一个线程单独处理这些操作,就非常好的能够管控。所以浏览器的模型就是单线程。

HTML5 提出 Web Worker 标准,允许 JavaScript 脚本创建多个线程,但是子线程完全受主线程控制,且不得操作 DOM。所以,这个新标准并没有改变 JavaScript 单线程的本质。

所以在早期,当使用大量同步的代码时,打开网页就会出现卡屏、卡页面的情况。因为在获取数据的时候,使用同步的代码,后面的数据还没到来之前,获取数据之后的代码都无法执行。只有等获取数据全部结束后,才会执行下面的代码。

所以后来,大家都知道了。开始使用异步。

同步队列 / 任务队列

既然是单线程,就意味着需要排队,即前面的任务结束,后面的任务才能执行。所以所有的任务被分成了两种,一种是同步任务,一种就是异步任务。同步任务指的就是在主线程上排队执行的任务,只有前一个任务执行完毕,才能继续执行后一个任务。而异步任务指的是,不进入主线程(同步队列 stack),而是进入任务队列(task queue)的任务。只有任务队列通知主线程,某个异步任务可以执行了,该任务才会进入主线程执行。

只要主线程空了,就会去读取 “任务队列” ,这就是 JavaScript 的运行机制。这个过程会不断重复。


重新理解这张图

例如我们有一段代码,这些代码是用来做一些操作。正常情况下,代码都是放置在栈(stack)中的,正常执行的时候是一个个去执行的。但是有些时候,比如给页面元素绑定一个事件,发了一条 ajax 请求,或者还有一些异步处理。这个时候,就不能够放置在 stack 中了。不然就会处于长久的等待之中,其他的代码就无法按顺序即使的执行。

所以在浏览器里面,还有一个可以被称之为任务队列的地方。对于一些异步的任务,都是放到任务队列里面。举例来说,当用户给一个元素绑定事件 onClick,绑定事件的操作在 stack 执行,但 onClick 回调本身是放到任务队列里面的。


重新理解 setTimeout

之前认识 setTimeout 时,就已经见过这段代码了,他的输出结果是先输出 2,后才输出 1。原理也是因为单线程机制。

1
2
3
4
5
setTimeout(function(){
console.log(1)
},0)

console.log(2)

console.log(2) 被放入到 stack 中执行,setTimeout() 被放入到 callback queue 了。换句话说,必须要等所有 stack 中的同步的代码全都执行完后,才会去执行异步的事件。所以不管 setTimeout() 里面的时间是 0 还是 1000 都会被排到后面。



所以下面这个例子,1 永远不会被输出,且 2 被循环多次后,会被卡死。因为永远都在执行 console.log(2) 这个同步代码。而整个 stack 栈都被堵死了。 setTimeout() 根本没办法执行。

1
2
3
4
5
6
7
8
9
var isOk = true
setTimeout(function(){
console.log(1)
isOk = false
},1000)

while(isOk){
console.log(2)
}


分析原生 Ajax

所以再去分析原生 Ajax 里面的代码,也能够更好的理解同步任务和异步任务。


这次,我想我真的理解了 JavaScript 的单线程机制。

本文结束  感谢您的阅读
0%