说到Node.js的事件循环网上已经有了很多形形色色的文章来讲述其中的原理,说的大概都是一个意思,学习了一段时间,对Node.js事件循环有了一定的了解之后写一篇博客总结一下自己的学习成果。
在笔者看来事件与循环本身就是两个概念,事件是可以被控件识别的操作,如按下确定按钮,选择某个单选按钮或者复选框。每一种控件有自己可以识别的事件,如窗体的加载、单击、双击等事件,编辑框(文本框)的文本改变事件。
然而循环则是在GUI线程中包含有一个循环,然而这个循环对于开发者和用户来讲是看不见的,只有关闭了程序之后该循环才会结束。当用户触发了一个按钮事件之后,就会产生响应的事件,这些时间被加入到一个队列中,用户在前台不断的产生事件,然而后台也在不断的处理这些时间,在处理的时候被加入到一个队列中,由于主循环中循环的存在会挨个处理这些对应的事件。
而对于JavaScript来讲的话由于JavaScript是单线程的,对于一个比较耗时的操作则是使用异步的方法解决(Ajax...)。对于不同的异步事件来也是由不同的线程各司其职来处理的。
Node.js的事件循环与浏览器的事件循环还是有很大的区别的,当Node.js启动后,它会初始化事件轮询;处理已提供的输入脚本(或丢入REPL,本文不涉及到),它可能会调用一些异步的api函数调用,安排任务处理事件,或者调用process.nextTick(),然后开始处理事件循环。
有一点是非常明确的,事件循环同样运行在单线程环境下,JavaScript的事件循环是依靠于浏览器来实现的,然而Node.js则是依赖于Libuv来实现的。
根据Node.js官方介绍,每次事件循环都包含了6个阶段,对应到Libuv源码中的实现,如下图所示,图中显示了事件循环的概述以及执行顺序。
下面是Node.js事件循环源代码:
int uv_run(uv_loop_t* loop, uv_run_mode mode) {
int timeout;
int r;
int ran_pending;
r = uv__loop_alive(loop);
if (!r)
uv__update_time(loop);
while (r != 0 && loop->stop_flag == 0) {
uv__update_time(loop);
// timers阶段
uv__run_timers(loop);
// I/O callbacks阶段
ran_pending = uv__run_pending(loop);
// idle阶段
uv__run_idle(loop);
// prepare阶段
uv__run_prepare(loop);
timeout = 0;
if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT)
timeout = uv_backend_timeout(loop);
// poll阶段
uv__io_poll(loop, timeout);
// check阶段
uv__run_check(loop);
// close callbacks阶段
uv__run_closing_handles(loop);
if (mode == UV_RUN_ONCE) {
uv__update_time(loop);
uv__run_timers(loop);
}
r = uv__loop_alive(loop);
if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT)
break;
}
if (loop->stop_flag != 0)
loop->stop_flag = 0;
return r;
}
假设事件循环进入到某一个阶段,及时在这期间其他队列中的事件已经准备就绪,也会先将当前阶段对应队列中所有的回调方法执行完毕之后才会继续向下执行,结合代码也是能够很好的理解的。不难可以得出在事件循环系统中回调的执行顺序是有迹可循的,同样也会造成事件阻塞。
var fs = require("fs");
fs.readFile('input.txt', function (err, data) {
if (err){
console.log(err.stack);
return;
}
console.log(data.toString());
});
fs.readFile('test.txt', function (err, data) {
if (err){
console.log(err.stack);
return;
}
console.log(data.toString());
});
console.log("程序执行完毕");
对于整个事件循环有个一个大概的认知之后,接下来针对每个阶段进行详细的说明。
该阶段主要用来处理定时器相关的回调方法,当一个定时器超市后一个事件就会加入到该阶段的队列中,事件循环会跳转至这个阶段执行对应的回调方法。
定时器的回调会在触发后尽可能早的被调用,为什么要说尽可能早的呢?因为实际的触发事件可能要比预先设置的时间要长。Node.js并不能保证timer在预设时间到了就会立即执行,因为Node.js对timer的过期检查不一定靠谱,它会受机器上其它运行程序影响,或者那个时间点主线程不空闲。
在这个阶段中除了timers、setImmediate,以及close操作之外的大多数的回调方法都位于这个阶段执行。例一个TCP socket执行出现了一些错误,那么这个回调函数会在I/O callbacks阶段来执行。名字会让人误解为执行I/O回调处理程序,然而一些常见的回调则会再poll阶段进行处理。
I/O callbacks阶段主要经过如下过程:
对于Poll阶段其主要的功能主要有两点:
当事件循环到达poll阶段时,如果这时没有要处理的定时器的回调方法,则会进行如下判断:
如果poll队列为空则会再次进行判断
该阶段执行setImmediate()的回调函数。关于setImmediate是一个比较特殊的定时器方法,setImmediate的回调则会加入到check队列中,从事件循环的阶段图可以知道,check阶段的执行顺序是在poll之后的。
一般情况下,事件循环到达poll阶段后,就会检查当前代码是否调用了setImmediate方法,这个在叙述poll阶段的时候已经有提及了,如果一个回调函数是被setImmediate方法调用的,事件循环则会跳出poll阶段从而进入到check阶段。(这一段有点重复...)
close阶段是用来管理关闭事件,用于清理应用程序的状态。如程序中的socket关闭等都会加入到close队列中,当本轮事件结束后则会进入下一轮循环。
对于事件循环来说每个阶段都有一个任务队列,当事件循环到达某个阶段的时候,讲执行该阶段的任务队列,知道队列清空或执行的对调到达系统上限后,才会转入到下一个阶段。当所有的阶段被执行一次后,事件循环则就完成了一个tick。
这是Node.js特有的方法,它不存在于任何浏览器(以及进程对象)中,process.nextTick是一个异步的动作,并且让这个动作在事件循环中当前阶段执行完之后立即执行,也就是上面所说的tick。
process.nextTick(() => {
console.log("1")
})
console.log("2")
// 2
// 1
官方对于process.nextTick有一段很有意思的解释:从语义角度看,setImmediate(稍后会说到)应该比process.nextTick先执行才对,而事实相反,命名是历史原因也很难再变。
然而对于process.nextTick来说该方法并不是事件循环中的一部分,但是它的回调方法确是由事件循环调用的,该方法定义的回调方法会被加入到nextTickQueue的队列中。相反地,nextTickQueue将会在当前操作完成之后立即被处理,而不管当前处于事件循环的哪个阶段。
Node.js对process.nextTick进行了限制,若递归调用process.nextTick当倒带nextTickQueue最大限制之后则会抛出一个错误。
function nextTick (i){
while(i<9999){
process.nextTick(nextTick(i++));
}
}
// Maxmum call stack size exceeded
nextTick(0);
既然说process.nextTick也是存在于队列中,那么其执行顺序也是根据程序所编写顺序执行的。
process.nextTick(() => {
console.log(1)
});
process.nextTick(() => {
console.log(2)
});
// 1
// 2
和其它回调函数一样,process.nextTick定义的回调也是由事件循环执行的,如果process.nextTick的回调方法中出现了阻塞操作,后面的要执行的回调函数同样会被阻塞。process.nextTick会在各个事件阶段之间执行,一旦执行,要直到nextTickQueue被清空,才会进入到下一个事件阶段,所以如果递归调用process.nextTick,会导致出现I/O starving的问题,比如下面例子的readFile已经完成,但它的回调一直无法执行。
const fs = require('fs')
const starttime = Date.now()
let endtime;
fs.readFile('text.txt', () => {
endtime = Date.now()
console.log('finish reading time: ', endtime - starttime)
})
let index = 0
function handler () {
if (index++ >= 1000) return
console.log(`nextTick ${index}`)
process.nextTick(handler)
}
handler();
// nextTick 1
// nextTick 2
// ......
// nextTick 999
// nextTick 1000
// finish reading time: 170
seImmediate方法不属于ECMAScript标准,而是Node.js提出的新方法,它同样将一个回调函数加入到事件队列中,不同于setTimeout和setInterval,setImmediate并不接受一个时间作为参数,setImmediate的事件会在当前事件循环的结尾触发,对应的回调方法会在当前事件循环的末尾(check)执行。虽然它确实存在于某些浏览器中,但并未在所有浏览器中达到一致的行为,因此在浏览器中使用时,您需要非常小心。它类似于setTimeout(fn,0)代码,但有时会优先于它。这里的命名也不是最好的。
本质上,它们两个的名字应该互相调换一下。process.nextTick()的执行时机比setImmediate()要更及时(上面有提过)。实施这项改变将导致很多npm包无法使用。每天都有很多新模块被加入,这意味着每等待一天,就会有更多潜在的破坏发生。虽然他们的名字相互混淆,但将它们调换名字这种事是不会发生的(建议开发者在所有地方使用setImmediate,这样程序更容易让人理解)。
仍然使用上述例子,若把nextTick替换成setImmediate会怎样呢?
const fs = require('fs')
const starttime = Date.now()
let endtime;
fs.readFile('text.txt', () => {
endtime = Date.now()
console.log('finish reading time: ', endtime - starttime)
})
let index = 0
function handler () {
if (index++ >= 1000) return
console.log(`setImmediate ${index}`)
setImmediate(handler)
}
handler();
// setImmediate 1
// setImmediate 2
// finish reading time: 80
// ......
// setImmediate 999
// setImmediate 1000
这是因为嵌套调用的setImmediate()回调,被排到了下一次事件循环才执行,所以不会出现阻塞。
定时器在Node.js和浏览器中的表现形式是相同的。关于定时器的一个重要的事情是,我们提供的延迟不代表在这个时间之后回调就会被执行。它的真正含义是,一旦主线程完成所有操作(包括微任务)并且没有其它具有更高优先级的定时器,Node.js将在此时间之后执行回调。
setTimeout(function timeout () {
console.log('timeout');
},0);
setImmediate(function immediate () {
console.log('immediate');
});
// 结果一
// timeout
// immediate
/**--------华丽的分割线--------**/
// 结果二
// immediate
// timeout
why?为什么会有两个结果,笔者在研究这里的时候也是有些不太明白,于是又做了第二个例子:
var fs = require('fs')
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('timeout')
}, 0)
setImmediate(() => {
console.log('immediate')
})
});
// 运行N次
// immediate
// timeout
虽然结论得出来了,但是这又是为啥呢?回想一下文章上半段所叙述的事件循环。首先进入timer阶段,如果我们的机器性能一般,那么进入timer阶段时,1毫秒可能已经过去了(setTimeout(fn,0)等价于setTimeout(fn,1)),那么setTimeout的回调会首先执行。如果没到一毫秒,那么我们可以知道,在check阶段,setImmediate的回调会先执行。为什么fs.readFile回调里设置的,setImmediate始终先执行?因为fs.readFile的回调执行是在poll阶段,所以,接下来的check阶段会先执行setImmediate的回调。我们可以注意到,UV_RUN_ONCE模式下,事件循环会在开始和结束都去执行timer。
阅读完本文章有什么收获呢?不如看下下面的代码,预测一下输出结果是什么样的。先不要急着看答案额...
const fs = require('fs');
console.log('beginning of the program');
const promise = new Promise(resolve => {
console.log('I am in the promise function!');
resolve('resolved message');
});
promise.then(() => {
console.log('I am in the first resolved promise');
}).then(() => {
console.log('I am in the second resolved promise');
});
process.nextTick(() => {
console.log('I am in the process next tick now');
});
fs.readFile('index.html', () => {
console.log('==================');
setTimeout(() => {
console.log('I am in the callback from setTimeout with 0ms delay');
}, 0);
setImmediate(() => {
console.log('I am from setImmediate callback');
});
});
setTimeout(() => {
console.log('I am in the callback from setTimeout with 0ms delay');
}, 0);
setImmediate(() => {
console.log('I am from setImmediate callback');
});
// 输出结果
// beginning of the program
// I am in the promise function!
// I am in the process next tick now
// I am in the first resolved promise
// I am in the second resolved promise
// I am in the callback from setTimeout with 0ms delay
// I am from setImmediate callback
// ==================
// I am from setImmediate callback
// I am in the callback from setTimeout with 0ms delay
对于本文中一些知识点任然有些模糊,懵懵懂懂,一直都在学习中,通过学习事件循环也看了一些文献,在其中看到了这一句话:除了你的代码,一切都是同步的,我觉得很有道理,对于理解事件循环很有帮助。
原文:https://segmentfault.com/a/1190000020755312
使用for...in遍历对象时,会遍历原型链上的可枚举属性,这可能会导致一些意想不到的问题。所以你一定收到过这样的建议,使用数组的forEach来代替for...in循环。本文给大家总结了5种在forEach中跳出循环的变通之法
在进行业务开发的过程中,使用了数组的高级函数map,同时使用了ES6语法async/await,发现在map循环下任务是异步执行的,并不符合预期。Array的循环方法map、forEach、filter、reduce、some、every等是并行迭代,可以理解为async/await的效果是无效的
在使用for循环的时候可以使用break 或者return语句来结束for循环(return直接结束函数),但是如果使用forEach循环如何跳出循环呢?首先尝试一使用return语句----木有效果
如果您需要重复大量的代码数百次,这会变得非常笨拙。而且,它也不是很有用。例如,如果希望它重复X次呢?这就是循环的用武之地。次数通常由变量决定,但也可以由实际数字决定。
循环:就是一遍又一遍执行相同或者相似的代码,循环的两个要素:循环体:重复执行的代码;循环条件:控制循环的次数
创建一个新的数组,新的数组中的元素是通过检查指定数组中符合条件的元素;注意:1. filter()不会对空数组进行检测;2. filter()不会改变源是数组;
我在项目里面用到了的是全局守卫,beforeEach,方便管理 不过遇到了一个问题,就是在beforeEach()中设置好判断条件后出现了无限循环的问题 当时的代码如下:
我们先来简单了解一下setTimeout延时器的运行机制。setTimeout会先将回调函数放到等待队列中,等待区域内其他主程序执行完毕后,按时间顺序先进先出执行回调函数。本质上是作用域的问题
for 常用于循环数组 ,for in 常用来循环对象,不建议循环数组,因为i是字符串 可能会有隐患问题,for in 循环会找到 prototype 上去,所以最好在循环体内加一个判断
我们经常会用到全局前置守卫,如判断用户有没有登陆过,如果登陆过就直接跳到目的页面,如果没有登陆过,就跳转到登陆页。先看官网对全局前置守卫的介绍
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!