Node.js的循環(huán)依賴
循環(huán)依賴，簡單點來說就是a文件中require b文件，然后b文件中又反過來require a文件。這個問題我們平時可能并不大注意到，但如果處理不好可能會引起一些讓人摸不清的問題。在node中，是如何處理循環(huán)依賴的問題的呢?
51CTO推薦專題：Node.js專區(qū)
寫個簡單的例子來試驗一下看吧。
定義兩個文件：
a.js
- var b = require('./b');
- console.log('a.js get b:' + b.b);
- module.exports.a = 1;
b.js
- var a = require('./a');
- console.log('b.js get a:' + a.a);
- module.exports.b = 2;
執(zhí)行
node a.js
輸出的結(jié)果是
b.js get a:undefined
a.js get b:2
從打印的軌跡上來看，代碼執(zhí)行的流程大致如下：
- a.js: b.js:
- var b = require('./b');
- var a = require('./a'); // a = {}
- console.log('b.js get a:' + a.a);
- module.exports.b = 2;
- // b = {b: 2}
- console.log('a.js get b:' + b.b);
- module.exports.a = 1;
node的加載過程，可以在lib/module.js文件中找到。與這個過程相關(guān)的代碼主要集中在Module._load方法里。可以看到，node會為每個新加載的文件創(chuàng)建一個Module對象(假設(shè)為a)，這個就是我們在a.js代碼中看到的module了。在創(chuàng)建a之后，node會先將a放到cache中，然后再對它進(jìn)行加載操作。也就是說，如果在加載a的過程中，有其他的代碼(假設(shè)為b)require a.js的話，那么b可以從cache中直接取到a的module，從而不會引起重復(fù)加載的死循環(huán)。但帶來的代價就是在load過程中，b看到的是不完整的a，也就是為什么前面打印undefined的原因。
Module的構(gòu)造函數(shù)
- function Module(id, parent) {
- this.id = id;
- this.exports = {};
- this.parent = parent;
- this.filename = null;
- this.loaded = false;
- this.exited = false;
- this.children = [];
- }
Module._load方法
- Module._load = function(request, parent, isMain) {
- //...
- var module = new Module(id, parent);
- //...
- Module._cache[filename] = module;
- try {
- module.load(filename);
- } catch (err) {
- delete Module._cache[filename];
- throw err;
- }
- return module.exports;
- };
這個看似簡單粗暴的處理手法，但實際上是node作者權(quán)衡各方面因素的結(jié)果。我們敬愛的npm作者issacs強調(diào)說了，這不是bug，而且近期內(nèi)不會做什么改變。當(dāng)然，issacs也給出了一些規(guī)避這個陷阱的建議(具體可以參考后面給的鏈接[1])。我總結(jié)了一下，主要有兩點：一個是在造成循環(huán)依賴的require之前把需要的東西exports出去;另一個是不要在load過程中操作未完成的模塊。
所以上面的例子的一種處理方法就是把各自的exports語句放到require語句前面，然后再運行，可以看到打印了正確的值。
從前面的分析來看，循環(huán)依賴的陷阱出現(xiàn)的條件比較苛刻：一個是循環(huán)依賴，另一個是在load期間調(diào)用未加載完成的對象。所以大家平常不怎么會遇到。但我之前就曾華麗麗的邂逅了這個陷阱，在這里拿出來當(dāng)一下反面教材。。。
場景簡化后大致如下：我有一堆service，每一個service負(fù)責(zé)消費某一類消息，并且可能會產(chǎn)生新的消息給其他service消費。從消息傳遞上來看，并沒有產(chǎn)生循環(huán)依賴。但我為了解耦，定義了一個消息中心center的角色出來進(jìn)行消息分發(fā)。center主要是維護一個type -> service的map來路由消息，這樣center就得把所有的service加載進(jìn)來，于是產(chǎn)生了center->service的依賴。另一面，每個service又需要通過center來分發(fā)它們新產(chǎn)生的消息，于是又出現(xiàn)了service->center的依賴，循環(huán)依賴就這么出來了。剛好在service加載的過程中，又調(diào)用了center的一個方法，就發(fā)生了undefined的錯誤。
這個問題查清楚原因以后，解決起來并不困難。
一種方法就是按前面的方法，在代碼層面上規(guī)避循環(huán)依賴的陷阱;
另外也可以在設(shè)計的層面上徹底避免循環(huán)依賴的出現(xiàn)。我的場景之所以出現(xiàn)循環(huán)依賴，是因為center和service都需要知道對方的存在，即 center <- -> service。如果采用依賴注入的方式，則可以切斷這種直接依賴，類似于center <- container -> service。即加入一個container角色，把center和service都先加載進(jìn)來，然后再用IOC的方法把依賴關(guān)系建立好。這樣center和service都無須知道對方具體的文件所在了，也就不會循環(huán)的require對方了。
總的來說，循環(huán)依賴的陷阱并不大容易出現(xiàn)，但一旦出現(xiàn)了，在實際的代碼中也許還真不好定位。它的存在給我們提了個醒，注意你工程中的依賴關(guān)系。哪天node對你抱怨，一個你明明已經(jīng)exports了的方法undefined，我們就該提醒一下自己：哦，也許是它來了：)
原文：http://club.cnodejs.org/topic/4f16442ccae1f4aa27001045
【編輯推薦】
