前言
在第三次浏览器大战中,来自Google的Chrome浏览器凭借优异的性能成为聚光灯下的焦点。而Chrome的成功离不开站在其背后的JavaScript引擎V8。
随着V8的出现,让JavaScript彻底摆脱了作为脚本语言性能低下的形象。V8出色的性能让JavaScript出现在高性能后台服务程序开发的舞台上。也正是因为这样的契机,在2009年,Node的创始人Ryan Dahl选择了V8作为Node的JavaScript脚本引擎。在事件驱动、非阻塞I/O模型的设计下实现了Node。
但是需要了解的是,Node虽然在JavaScript的执行上受益于V8,极大的扩宽了JavaScript的应用场景,让其应用场景从客户端进军到了服务端,但是也同时受到了v8的限制,对于性能敏感的服务端的程序,内存管理、垃圾回收都会对服务的构成产生影响,而这些都和v8有着很大的关系。
V8的内存限制
在Node中如果通过JavaScript使用内存操作时会发现实际只能使用部分内存(64位系统下约为1.4G,32位系统下约为0.7G),这种限制对于其他的服务端开发语言来说基本上都是不存在的。
而V8的这种限制导致的结果是Node无法直接操作大内存对象。在单个Node进程的情况下,计算机的内存资源无法得到充足的使用。
而问题的原因在于Node是基于V8构建,所以在Node中使用对象都是通过V8自己的方式进行分配和管理。
而其内存管理机制在浏览器的场景下问题不大,但是对于Node,却使得Node