javascript事件循环

js单线程

js是单线程的，这样更有利与用户交互以及DOM操作;有关进程与线程的详细解释可以点击传送门；尽管webworker可以实现多线程，但本质上他还属于单线程，由webworker创建的线程都由主线程控制并且只能进行计算而已;

js同步、异步

同步执行：即js主线程按顺序执行任务，如遇操作webAPI/ajax等代码时会等待其响应后面代码得不到执行，也就是下一个任务必须等到前一个任务执行完成；

异步执行：js是单线程的本身不具备异步能力，但浏览器可以;当js执行时遇到webAPI(如setTimeout/ajax等)，会立即返回一个值，从而不阻塞主线程，而真正的异步由浏览器执行，待完成后讲其回调函数推入js主线程的消息队列中等待主线程调用;

事件循环机制[Event-loop]

js执行时其主线程拥有一个执行栈[个人习惯叫调用栈](stack)和一个消息列队[也叫任务列队或事件列队](Event-queue)；当js执行时遇到函数function时会将其入栈待函数执行完在出栈，主线程调用执行栈并执行，如果遇到webAPI会异步执行;当执行栈中没有任务时，主线程会查询消息列队，如查询成功，则将查询的任务入栈执行，直到执行栈为空，再次查询消息列队，这样形成一个循环就是大名鼎鼎的事件循环[Event-loop]；由于异步执行是浏览器完成的这也就好理解为什么js线程阻塞时操作dom事件会在线程恢复后依次执行,[js主线程的任务列队是浏览器推入的，js线程阻塞!==浏览器线程阻塞，换言之即是主线程阻塞也不妨碍向任务列队推入任务]；画个草图;

再来段代码:

　　　　　　// 主线程执行fn1任务  1
            function fn1(){
                console.log("任务1执行")
                // 遇到webAPI立即返回 这里是undefined值 并交给浏览器对应线程处理 2
                // 浏览器收到后 0 毫秒将回调函数推入消息列队; 异步执行
                setTimeout(function(){// 查询到一个回调任务 入栈执行    5
                console.log("回调1执行")
                    // 遇到webAPI立即返回 这里是undefined值 并交给浏览器对应线程处理  6
                    // 浏览器收到后 500   毫秒将回调函数推入消息列队; 异步执行
                    setTimeout(function(){// 查询到一个回调任务 入栈执行    7
                        console.log("回调2执行")
                    },500)
                },0)
            }
            // 主线程执行fn2任务 3
            function fn2(){console.log("任务2执行")}
            // 执行栈没有可执行任务 开始查询消息列队 4

Macrotasks 和 Microtasks

消息列队分为两种即Macrotasks[Task Queue]与Microtasks[Microtasks Queue ]；

• macrotasks: setTimeout, setInterval, setImmediate, I/O, UI rendering

• microtasks: process.nextTick, Promises, Object.MutationObserver

这就引发一个问题他俩到底该谁先执行呢？Promise/A+规范指出：

Here “platform code” means engine, environment, and promise implementation code. In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. This can be implemented with either a “macro-task” mechanism such as setTimeout or setImmediate, or with a “micro-task” mechanism such as MutationObserver or process.nextTick. Since the promise implementation is considered platform code, it may itself contain a task-scheduling queue or “trampoline” in which the handlers are called.

其实执行过程也是很好理解的也是一个循环查询，在前面的基础上查询消息列队时 会先查询 microtasks将其所有任务执行完毕后在查询macrotasks如果执行macrotasks中有microtasks任务则下次查询依旧会先执行完microtasks列队任务在查询macrotasks 如此反复 直到消息列队[两个 Queue]无任务;

ok我们上段代码[promise特性为es6 故用node环境]

console.log(1);
setTimeout(function(){
    console.log(7)
},0);
setTimeout(function(){
    new Promise(function(resolve){
        resolve();
    }).then(function(){
        console.log(8)
    }).then(function(){
        console.log(9)
    }).then(function(){
        console.log(10);
    })
},0);
new Promise(function(resolve){
    resolve();
}).then(function(){
    console.log(3)
}).then(function(){
    console.log(4)
}).then(function(){
    console.log(5)
}).then(function(){
    console.log(6)
})
console.log(2);
// 1 2 3 4 5 6 7 8 9 10

上边代码执行过程：

js执行console 1 遇到setTimeout改为异步执行，又遇setTimeout再次异步执行，接着执行遇到promise 被推入microtasks型任务列队之后执行console 2 至此执行栈为空开始查询消息列队，先去查询microtasks发现有个 有任务可以执行，接着会将任务入栈执行并相应打印 3 4 5 6【只要发现microtasks不为空就执行到为空为止】； 再次查询消息列队 此时microtasks列队已无任务可执行，接着查询macrotasks列队发现一个setTimeout回调等待执行，接着入栈执行并出栈，打印 7 ；再次查询列队 此时microtasks列队依然无任务，接着查询macrotasks列队又发现一个setTimeou回调等待执行，入栈执行 发现promise推入microtasks列队 出栈，执行栈又空了。查询消息列队 此时发现microtasks有任务可以执行，入栈 执行 出栈;打印响应 8 9 10；至此执行结束主线程处于等待状态；