前言
这篇文章主要是为了记录笔者寻求突破Node中内存使用限制的过程，以及中间遇到的一些问题和给我的启发。
承接前文 探讨Node内存机制和大文件处理，笔者分析了破除Node对内存使用限制的方法，最后得到结论：
仅仅使用未经改造的Buffer对象或者增加max_old_space是不能使用一块连续的2G以上的内存的
怎么办呢？
上一篇文章中也提到了，使用原生C++插件的方式扩展Node，使用C++特性来获得对大片内存空间的使用权限。
想法很美好，但是现实却很骨感。
在开始之前
首先讨论下现在Node的C++插件的模式。
如果你是一个喜欢Node并且愿意编写C++插件用来提升自己代码的计算效率的人，就很容易发现，早期的C++插件的编写方式和现在有着很大不同。
到今天为止，我们还是可以在绝大部分中文教程和文档中看见类似如下代码，包括《深入浅出Nodejs》
#include <v8.h>
#include <node.h>
using namespace node;
using namespace v8;
static Handle<Value> foo(const Arguments& args)
{
return String::New("World");
}
extern "C" {
static void init(Handle<Object> target)
{
NODE_SET_METHOD(target, "foo", foo);
}
NODE_MODULE(hello, init);
}
这些东西太老了。。。。
如果你把上面这些打到你的扩展上去，gyp会给你报一堆的错误，那是因为很久以前，Node扩展的方法已经变为如下：
// hello.cc
#include <node.h>
namespace demo {
using v8::FunctionCallbackInfo;
using v8::Isolate;
using v8::Local;
using v8::Object;
using v8::String;
using v8::Value;
void Method(const FunctionCallbackInfo<Value>& args) {
Isolate* isolate = args.GetIsolate();
args.GetReturnValue().Set(String::NewFromUtf8(isolate, "world"));
}
void init(Local<Object> exports) {
NODE_SET_METHOD(exports, "hello", Method);
}
NODE_MODULE(NODE_GYP_MODULE_NAME, init)
} // namespace demo
至于具体的差别，不是笔者今天要进行讨论的点，在这里主要是想说明：
- Node的C++扩展，可以理解为是面向V8编程
- 编写Node拓展的方法中必须受到V8的GC控制
从老一版到新版的扩展编写示例，使用v8::Isolate进行调度管理，甚至在老版中可以看到需要用Handle<Value>模板来对作用域进行限制。
那么，可以认为，即使是使用了C++原生的插件，可能也会有内存的使用限制。
但是我头铁
于是笔者编写了以下demo
//c++ code
#include <node.h>
#include <iostream>
#include <fstream>
#include <cstdlib>
using namespace std;
namespace demo {
using v8::FunctionCallbackInfo;
using v8::Isolate;
using v8::Local;
using v8::Object;
using v8::String;
using v8::Value;
void Method(const FunctionCallbackInfo<Value>& args) {
Isolate* isolate = args.GetIsolate();
filebuf *pbuf;
ifstream filestr;
long size;
char * buffer;
filestr.open ("/home/kanoyami/桌面/stackOverFlow.json", ios::binary);
if (! filestr.is_open())
{
cout << "Error opening file"; exit (1);
}
pbuf=filestr.rdbuf();
size=pbuf->pubseekoff (0,ios::end,ios::in);
pbuf->pubseekpos (0,ios::in);
buffer=new char[size];
//int length = sprintf(buffer, "%05X", size);
pbuf->sgetn (buffer,size);
filestr.close();
//cout<<buffer ; 调试的时候试着让控制台打印下buffer
args.GetReturnValue().Set(String::NewFromUtf8(isolate,buffer));
}
void init(Local<Object> exports) {
NODE_SET_METHOD(exports, "hello", Method);
}
NODE_MODULE(NODE_GYP_MODULE_NAME, init)
} // namespace demo
这里这个StackOverFlow.json是笔者从它的网站按照热度排行爬取的前5000页也就是二十五万条问答数据，一共用3G。
使用$ node-gyp build生成可用的node模块
在index.js中使用
var sb = require('./build/Release/superBuffer.node');//模块名字superBuffer.node
var showMem = function() {
var mem = process.memoryUsage();
var format = function(bytes){
return (bytes / 1024 / 1024).toFixed(2)+'MB';
}
console.log('Process: heapTotal'+format(mem.heapTotal)+'**heapUsed:'+format(mem.heapUsed)+'**extenal:'+format(mem.external));
}
showMem();
var a = sb.hello();
showMem();
做人要厚道，这里用到的监测内存变化的方法是从《深入浅出Nodejs》中获得的。
在笔者自己的笔记本上运行的时候，可以看到一个常见错误：
kanoyami@kanoyami-Inspiron-7537:~/bigDataTest$ node index.js -max_old_space=4096
Process: heapTotal8.00MB**heapUsed:4.18MB**extenal:0.01MB
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
已放弃 (核心已转储)
这里注意到一点，是由std抛出的错误，开辟内存空间的时候失败了。
引起这个错误的原因显然是我内存不足，但是值得关注的是，std返回的错误而不是v8,也就是说在内存足够的情况下是不是可以开辟出足够的内存空间，把json装进内存呢？
是时候拿出了我的双路E5了。
为了看到是不是真的把文件装载进了内存，我在关闭文件流之后试着打印buffer变量。
监视内存和cpu用量$ top。
开始执行。
结果很美好。
通过监视进程也可以看到
在可以看到使用了9.8%的内存，RES的值也是3.048G，很完美。
也就是我成功的把文件装进内存了。
这时候关闭打印，直接把buffer以字符串的形式返回。
[root@cdh-61 bigDataTest]# node index.js
Process: heapTotal7.35MB**heapUsed:4.20MB**extenal:0.01MB
#
# Fatal error in ../deps/v8/src/handles.h, line 212
# Check failed: (location_) != nullptr.
#
非法指令
这个时候返回了一个空指针错误。
明明我已经成功把数据装进内存了，为什么会返回一个空指针呢？
分析
前面也提到过，在使用Node的原生插件的时候，要求使用V8定义的数据结构，而且必须在一个V8作用域内完成操作。
如果真是如此，理论上我们是不能开辟出2G以上的内存的，但是我们确实在这里看到了，整个文件被成功的装进了内存。也就是说，在模块内部编写代码的时候，是允许我们用std的方法，那问题出在哪里？
从老版本的模块代码中，我们能看到这样的代码
scope.Close(/*返回值*/)
新版中使用
args.GetReturnValue()
第一个方法的意思是，将整个作用域销毁并向上层作用域返回一个值。而后者依旧来自于v8包。
也就说，在这一步的时候，调用了销毁作用域，此时这个值应当被保留，但是已经由v8管理。由于使用了过多的内存，触发了v8的GC机制，被直接销毁。
因此我们就得到了一个空的返回。
还有办法吗？
查阅了官方文档之后，从Node8.0.0版本开始，加入了一组新的实验性API
C++ N-API
官方对他的描述是：
N-API (pronounced N as in the letter, followed by API) is an API for building native Addons. It is independent from the underlying JavaScript runtime (ex V8) and is maintained as part of Node.js itself. This API will be Application Binary Interface (ABI) stable across versions of Node.js. It is intended to insulate Addons from changes in the underlying JavaScript engine and allow modules compiled for one version to run on later versions of Node.js without recompilation.
Addons are built/packaged with the same approach/tools outlined in the section titled C++ Addons. The only difference is the set of APIs that are used by the native code. Instead of using the V8 or Native Abstractions for Node.js APIs, the functions available in the N-API are used.
APIs exposed by N-API are generally used to create and manipulate JavaScript values. Concepts and operations generally map to ideas specified in the ECMA262 Language Specification.
大意如下：
N -API（读做嗯-A屁唉）是一个构建本地插件的API。它并不依赖于JavaScript运行时（例如v8）而是作为Node.js自身的组建的一部分运行。这个API将会作为应用程序二进制接口（ABI 描述了应用程序和操作系统之间，一个应用和它的库之间，或者应用的组成部分之间的低接口。）稳定在Node.js当中。它的目的是为了可以让插件更改JS引擎底层实现并允许它们为Node编译一次而无需为每个新版本的Node重新编译。
这个插件的构建和打包使用和一般C++插件相同的方法和应用。惟一的不同是这组API使用原生代码。N-API使用本地函数，而不是使用v8或者本地抽象的Node.js API。
N-API暴露的API通常是用于创建和操纵JS的值。概念和操作的一些思想也通常是被列举在ECMA262语言规范之中。
启发
这给我了一些新的思路，或许可以在NAPI上找到内存限制的突破口。
但这也是下篇文章的事情了。
