【笔记】 你不知道的JS读书笔记——异步

基础：
浏览器 -- 多进程，每一个tab页独立一个浏览器渲染进程（浏览器内核）

每一个浏览器渲染进程是多线程的，主要包括：
GUI渲染线程

JS引擎线程

• 也称为JS内核，负责处理Javascript脚本程序。（例如V8引擎）
• JS引擎线程负责解析Javascript脚本，运行代码。
• JS引擎一直等待着事件循环队列中任务的到来，而后加以处理，一个Tab页（renderer进程）中不管何时都只有一个JS线程在运行JS程序

注意，GUI渲染线程与JS引擎线程是互斥的，因此若是JS执行的时间过长，这样就会形成页面的渲染不连贯，致使页面渲染加载阻塞。

事件触发线程

• 归属于浏览器而不是JS引擎，用来控制事件循环（能够理解，JS引擎本身都忙不过来，须要浏览器另开线程协助）
• 当JS引擎执行代码块如setTimeOut时（也可来自浏览器内核的其余线程,如鼠标点击、AJAX异步请求等），会将对应任务添加到事件线程中
• 当对应的事件符合触发条件被触发时，该线程会把事件添加到事件循环队列的队尾，等待JS引擎的处理

注意，因为JS的单线程关系，因此这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）

定时器触发线程

• setInterval与setTimeout所在线程
• 浏览器定时计数器并非由JavaScript引擎计数的,（由于JavaScript引擎是单线程的, 若是处于阻塞线程状态就会影响记计时的准确）
• 所以经过单独线程来计时并触发定时（计时完毕后，添加到事件循环队列中，等待JS引擎空闲后执行）

注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms。

异步HTTP请求线程

• 在XMLHttpRequest在链接后是经过浏览器新开一个线程请求
• 将检测到状态变动时，若是设置有回调函数，异步线程就产生状态变动事件，将这个回调再放入事件循环队列中。再由JavaScript引擎执行。

正文：

异步

分块程序、事件循环、并行

程序中如今运行的部分和未来运行的部分之间的关系就是异步编程的核心

ajax请求的异步：发出请求时，未来才能得到请求返回结果
—— 应该避免同步ajax请求，浏览器UI会被锁定并阻塞全部用户交互

异步基于事件循环机制 —— JavaScript引擎只是一个按需执行代码片断的环境，而这个需求是由其运行环境决定的：当遇到须要等待某些条件（网络数据、定时器计时到期等），条件知足后，运行环境才会把回调函数插入到事件循环队列中（参考基础资料 事件触发线程、定时器线程）

书中提到：ES6精确指定了事件循环的工做细节，在技术上将其归入了javascript引擎的势力范围，不是只由宿主环境管理，怎么理解？？ 和前文基础部分对于浏览器渲染进程包含的多个线程之间关系有必定出入么？

异步和并行意义彻底不一样！！
并行 —— 同步执行 ，对于多线程编程，内存的共享提高了复杂度
异步 —— 交替调度

Javascript是单线程执行，从不跨线程共享数据

var a = 1,b=2

function foo(){
  a = a + 1;
  b = b*2
}

function bar(){
  a = a * 2;
  b = b + 1;
}

// ajax(...)是某个库中提供的函数
ajax( 'http://some.url.1', foo );
ajax( 'http://some.url.2', bar );

因为js的单线程执行特性，foo() bar()函数内部的代码具备原子性
虽然foo() bar()存在竞态致使 a,b的最终值并不肯定
但这种不肯定性是在函数执行顺序上的（两个ajax返回的顺序）

1.4 并发（让人有点懵）

旨在说明 “并发” 的几种状况，在js中看似并发实际是由单线程事件循环机制实现的
均以两个ajax请求的回调函数内执行不一样代码为例：

• 非交互： 两个并发任务间彼此独立不相关，这时不肯定性是彻底能够接受的
• 交互： 并发任务间彼此经过做用域或者DOM间接交互，好比都向数组中插入一条数据，这时数组中条目的顺序就和并发任务执行顺序有关了，在须要保证正确交互顺序的场景须要加入协调代码
• 协做： 并发协做，将一个会长期执行的任务分割为多个步骤或多批任务执行，以便占领事件循环队列过久时间，如setTimeout(...0)进行异步调度

任务队列

ES6引入，任务队列(job queue) —— 挂在事件循环队列的每一个tick以后的一个队列， 在事件循环的每一个tick中，可能出现的异步动做不会添加一个完整的新事件到事件循环队列中，而是会在当前tick的任务队列末尾添加一个项目(一个任务)

理论上说，任务队列可能致使无限任务循环

回调

回调函数是javascript异步的基本单元

这章主要讨论回调这种自javascript诞生以来就存在的异步方式存在什么问题（思惟上的（大脑搞不定）、写法上的（嵌套、硬编码）、信任问题（控制反转）等），以引出下一章对新的异步方式Promise的讨论

• 给异步方法async传入continuation，当异步方法async结束时主动调用continuation执行
• 事实上async并不关心其结束对其余模块有什么影响，但使用回调的方式，async在结束时必须主动调用全部传入的continuation
• 若是有数个异步任务须要链式执行，代码写法上很容易造成callback hell，但这不是重点，即便把嵌套写法解开写成多个函数调用的方式，也一样不易于阅读；并且还有另外一个问题，当链式回调中一个断掉时，如何处理错误状况？须要硬编码在各个函数中进行处理，代码复杂度大大增长
• 另外还有一个信任问题，有些状况下异步任务是第三方提供，使用回调其实就是将代码控制器交给了第三方处理——控制反转

调用回调过早
调用回调过晚（或不被调用）
调用回调次数过少或过多
未能传递所需的环境和参数
吞掉可能出现的错误和异常

针对回调的问题能够用一些特定逻辑来解决：
好比回调传入两种：正确、错误 或 error-first模式
针对回调过早问题：强制回调封装

但这些解决方案并不通用、且须要每次重复编写、难以复用

几个问题

• 为何setTimeout(...)定时器可能精度不高？

setTimeout(...)只是保证了回调函数不会在指定时间间隔以前执行，时间间隔以后插入到事件循环队列中，但此时队列中可能有多个项目

• 任务队列和事件循环队列是不一样的概念，怎么区分？

我的理解：

事件循环 -> 基于事件循环队列，其维护者不是js引擎，当js引擎执行到须要等待某个条件完成的代码时（ajax，setTimeout等），会交给当前运行环境执行并提供一个回调函数（运行环境可能使用其余线程），js引擎继续执行接下来的代码；条件知足后，运行环境将回调函数插入到事件循环队列的末尾，js引擎会从事件循环队列中获取代码执行

任务队列 -> 首先明确任务队列的位置：挂在事件循环队列的每一个tick以后的一个队列，当出现一个新的任务时，老是挂到当前事件循环tick结尾处！搞清楚如下代码的执行顺序就能初步了解任务队列与事件循环队列的关系了：

console.log('A');
setTimeout( function(){
  console.log('B');
},0)
var p = new Promise((resolve, reject)=>{
  console.log('C');
  return Promise.resolve(console.log('D'));  // 嵌套promise
})


输出顺序： A C D B

另外，任务队列是由js引擎本身控制的 @TODO 了解具体实现方式