node中的require和exports
发布于 4年前 作者 leexiaosi 6628 次浏览 最后一次编辑是 3年前

题记:


有一天去面试,面试官问我,nodejs中的require是阻塞还是非阻塞。我心想,模块的引用都是先require之后再使用,应该是阻塞,但是对require的实现机制并不了解,就坦诚说不知道了。回来之后,我就翻了一遍node的源码,就简单写一下自己对node中模块的实现理解,纰漏之处,望大家指正。

js模块的实现


其实早先时候在cnodejs问答中已经有人提到,模块中module,exports是怎么实现的,什么含义。当时是我回答的说是一个开发的接口,其实这是不对的。node中模块的实现,其实是依赖于闭包的,也就是说,module,exports其实都是外部传入的参数,这个简化形式如下:
function NativeModule(id){

this.id=id;
this.filename=id+".js";
this.exports={};
}
NativeModule.require=function(id){
var module=new NativeModule(id);
module.compile();
return module.exports();
};
NativeModule.prototype.compile = function() {  
  (function(exports, require, module, __filename, __dirname){
        exports=module.exports=function(){alert(“leexiaosi”)};
}(this.exports, NativeModule.require, this, this.filename));
};
NativeModule.require(“leexiaosi”)

(附:上面的代码可以复制出来直接运行)
通过上面的代码我们惊奇的发现,其实我们看见的模块文件的代码,一般而言都是类似
exports=module.exports=function(){alert(“leexiaosi”)};

同时我们也就明白,为什么在模块文件中用var定义的变量都是私有的了。这里关键点就是
NativeModule.prototype.compile

这个函数的实现。为了方便理解,我们设
var fnImport=function(exports, require, module, __filename, __dirname)

那么,根据闭包的原理,这个函数在执行时,其[[scope]]会记录fnImport这个函数定义的作用域的各个变量,

  • fnImport函数中的形参值,即this.exports, NativeModule.require, this, this.filename

  • fnImport函数中function声明的函数

  • fnImport函数中通过var声明的变量

  • fnImport函数的父函数的作用域[[scope]]


fnImport这个函数对其fnImport.[[scope]]的操作都是有权限的。故this.exports会被更改,尽管在NativeModule的构造函数中this.exports的定义是空对象。
当然,事实上的NativeModule的实现要比这个复杂得多,尽管一般而言,非核心模块加载都是依赖于module这个模块,但是,module的实现模块加载的基本思想也是这样,只是module中增加了模块的检索功能。而模块文件中,require正是NativeModule.require这个函数。从return module.exports()来看,require初次加载模块时候必然是阻塞的(初次加载之后会被缓存,所以加载之后再require就不是阻塞的了)。

7 回复

翻源码找答案的人伤不起啊!支持

最近也剛好有機會用到nodejs

看到你的Blog覺得很棒

不過我不太懂您的阻塞跟非阻塞的意思, 請問有無英文單字可供參考?

謝謝您

我英文不太好
阻塞应该是blocking
非阻塞应该是nonblocking.
其实是这样的,例如核心脚本,在lib下的node脚本,如module,fs,http等,其编译后的存储是使用的json对象,来避免文件的读写,即形式如{"module":"…","http":"…"},会伴随着node.exe一起加载,require核心模块是不涉及到IO读写的,但是非核心脚本,存在着IO读写,但关键是,无论是核心模块还是非核心模块的脚本都是使用了js中类似"eval"的
process.binding(“evals”).NodeScript.runInThisContext来解析,解析必然是阻塞的

謝謝你的回答, 清楚許多^^ thanks

最近我也在看相关内容,补充一下。
nodejs的环境变量 NODE_MODULE_CONTEXTS。
默认情况下它为0,表示module不使用独立的context。
设置为1,表示为每个module创建独立的context。
一般我们没有设置,也就是默认情况,nodejs为module创建了闭包环境
lz说的情况主要是只这个默认情况下。
对于 var a = "foo"; 这两种情况没有什么区别。
但 a = “foo” 就有明显区别了,默认情况下a将成为全局变量。而=1时a仍然是局部变量。

最近我也在看相关内容,补充一下。
nodejs的环境变量 NODE_MODULE_CONTEXTS。
默认情况下它为0,表示module不使用独立的context。
设置为1,表示为每个module创建独立的context。
一般我们没有设置,也就是默认情况,nodejs为module创建了闭包环境
lz说的情况主要是指这个默认情况下。
对于 var a = "foo"; 这两种情况没有什么区别。
但 a = “foo” 就有明显区别了,默认情况下a将成为全局变量。而=1时a仍然是局部变量。

光是这个问题,其实很好回答, 如var express = require(‘express’), 这个require必然是阻塞的,不然后面就没法调用到 express了。

回到顶部