// app.js function cleanCache(modulePath) { var module = require.cache[modulePath]; // remove reference in module.parent if (module.parent) { module.parent.children.splice(module.parent.children.indexOf(module), 1); } require.cache[modulePath] = null; } setInterval(function () { var code = require('./code.js'); cleanCache(require.resolve('./code.js')); }, 10);
再执行一下，这次好多了，内存只会有轻微的增长，说明老模块占用的资源已经正确的释放掉了。
使用了新的 cleanCache 函数后，常规的使用就没有问题，然而并非就可以高枕无忧了。在 Node.js 中，除了 require 系统会添加引用外，通过 EventEmitter 进行事件监听也是大家常用的功能，并且 EventEmitter 有非常大的嫌疑会出现模块间的互相引用。那么 EventEmitter 能否正确的释放资源呢？答案是肯定的。
// code.js var moduleA = require('events').EventEmitter(); moduleA.on('whatever', function () { });
当 code.js 模块被更新，并且所有引用被移出后，只要 moduleA 没有被其他未释放的模块引用， moduleA 也会被自动释放，包括我们在其内部的事件监听。
只有一种畸形的 EventEmitter 应用场景在这套体系下无法应对，即 code.js 每次执行的时候都会去监听一个全局对象的事件，这样会造成全局对象上不停的挂载事件，同时 Node.js 会很快的提示检测到过多的事件绑定，疑似内存泄露。
至此，可以看到只要处理好了 require 系统中 Node.js 为我们自动添加的引用，老模块的资源回收并不是大问题，虽然我们无法做到像 Erlang 一样实现下一次热更新对还留存的老模块进行扫描这样细粒度的控制，但是我们可以通过合理的规避手段，解决老模块资源释放的问题。
在 Web 应用下，还有一个引用问题就是未释放的模块或者核心模块对需要热更新的模块有引用，如 app.use，导致老模块的资源无法释放，并且新的请求无法正确的使用新模块进行处理。解决这个问题的手段就是控制全局变量或者引用的暴露的入口，在热更新执行的过程中手动更新入口。如 如何使用新模块处理请求 中对 router 的封装就是一个例子，通过这一个入口的控制，我们在 router.js 中无论如何引用其他模块，都会随着入口的释放而释放。
另一个会引起资源释放问题的就是类似 setInterval 这类操作，会保持对象的生命周期无法释放，不过在 Web 应用中我们极少会使用这类技术，因此方案中并未关注。
尾声
至此，我们就解决了 Node.js 在 Web 应用下代码热更新的三大问题，不过由于 Node.js 本身缺乏对有效的留存对象的扫描机制，因此并不能100%的消除类似 setInterval 导致的老模块的资源无法释放的问题。也是由于这样的局限性，目前我们提供的 YOG2 框架中，主要还是将此技术应用于开发调试期，通过热更新实现快速开发。而生产环境的代码更新依然使用重启或者 PM2 的 hot reload 功能来保证线上服务的稳定性。
由于热更新实际上与框架和业务架构紧密相关，因此本文并未给出一个通用的解决方案。作为参考，简单的介绍一下在 YOG2 框架中我们是如何使用这项技术的。由于 YOG2 框架本身就支持前后端子系统 App 拆分，因此我们的更新策略是以 App 为粒度更新代码。同时由于类似 fs.watch 这类操作会有兼容性问题，一些替代方案如 fs.watchFile 则会比较消耗性能，因此我们结合了 YOG2 的测试机部署功能，通过上传部署新代码的形式告知框架需要更新 App 代码。在以 App 为粒度更新模块缓存的同时，会更新路由缓存与模板缓存，来完成所有代码的更新工作。
如果你使用的是类似 Express 或者 Koa 这类框架，只需要按照文中的方法结合自身业务需要，对主路由进行一些改造，就可以很好的应用这项技术。
您可能感兴趣的文章: