内存占用与释放差异
- 核心模块
- 内存占用：Node.js核心模块在编译阶段就已经被加载并缓存到内存中。由于核心模块是Node.js运行时的基础组成部分，它们通常会在整个应用程序的生命周期内持续占用内存。例如
http模块，在Node.js启动后，相关的代码和数据结构就已经在内存中准备就绪，等待被应用程序调用。
- 内存释放：核心模块在应用程序运行期间一般不会被释放，除非整个Node.js进程结束。因为它们是系统运行的关键部分，频繁释放和加载会带来较大的性能开销。
- 文件模块
- 内存占用：文件模块是按需加载的，当第一次被引用时，Node.js会读取文件内容并进行编译，然后将其缓存到内存中。后续再次引用该模块时，直接从缓存中获取，减少了重复加载的开销。但如果一个文件模块非常大，包含大量的数据或复杂的逻辑，首次加载时会占用较多内存。比如一个自定义的工具模块，里面定义了很多大型的数据结构和复杂的算法。
- 内存释放：文件模块在理论上如果长时间不再被引用，其占用的内存有可能被垃圾回收机制回收。然而，实际情况中由于模块缓存机制的存在，如果模块被缓存且仍在作用域链中可达，垃圾回收器不会轻易回收其内存。例如，在一个模块中通过
exports或module.exports导出了一个对象，而其他模块引用了这个对象，只要这个引用关系存在，该模块及其导出的对象就不会被回收。
优化因模块使用不当导致的内存问题
- 避免循环引用
- 问题：当两个或多个模块相互引用时，会形成循环引用。在Node.js中，循环引用可能导致模块不能完全加载，并且可能造成内存中的数据结构变得复杂，增加内存占用。例如，模块A引用模块B，模块B又引用模块A，这种情况下可能导致部分代码未执行或数据加载不完整。
- 优化：通过重构代码，打破循环引用。可以将相互依赖的部分提取到一个独立的模块中，让模块A和模块B都依赖这个新模块。例如，假设模块
user.js和order.js相互引用，将它们共同依赖的用户订单相关逻辑提取到userOrderUtil.js模块，user.js和order.js分别引用userOrderUtil.js。
- 及时清理不再使用的模块引用
- 问题：如果模块被加载后，其导出的对象或函数在应用程序中不再使用，但由于引用关系仍然存在，会导致内存无法释放。比如一个模块导出了一个数据库连接对象，在数据库操作完成后，没有释放该连接对象的引用，使得这个对象一直占用内存。
- 优化：在使用完模块的功能后，手动将相关的引用设置为
null，让垃圾回收器可以回收相关内存。例如：
const myModule = require('./myModule');
// 使用myModule的功能
myModule.doSomething();
// 使用完后，清理引用
myModule = null;
- 合理拆分大模块
- 问题：大型文件模块会在加载时占用较多内存，并且由于模块缓存机制，即使部分功能未使用，整个模块也会占用内存。例如，一个包含各种功能的大型工具模块，其中一些功能在特定应用场景下从未使用，但仍然占用内存。
- 优化：将大模块拆分成多个小模块，按需加载。比如将一个大型的图像处理模块，拆分成图像裁剪、图像压缩、图像格式转换等多个小模块，在需要时分别加载相应的小模块，减少不必要的内存占用。
