本篇文章就先暂时实现一个简单的快照沙箱。下篇文章再使用Proxy实现一个沙箱
window 环境和沙箱环境，其实都是在 window 上进行操作，所以刚开始的时候有点分不清，其实就是要理解沙箱环境和 window 环境。在这两个环境来回切换的时候，需要对应环境原来的改动找回来，就需要两个变量来存储，一个 windowSnapshot 来存储 window 上的属性，一个 sandboxSnapshot 来存储沙箱上的属性
一、定位node.js内存漏洞的工具：工欲善其事必先利其器，在排查时，我们还是需要一些工具来帮忙的。
devTool
这个是今年初出的 Node.js 调试工具，基于 Electron 将 Node.js 和 Chromium 的功能融合在了一起。操作起来比 node-inspector 方便，开放的 Timeline 功能还是比较实用的，虽然不是实时显示。
仅需要 devtool xxx.js，还可以通过 .devtoolrc 来进行参数定制，具体见 GitHub
heapdump + chrome devTool
这个是比较传统的定位内存泄漏的组合。heapdump 可以直接在代码中调用生成内存快照，然后将快照文件导入到 chrome devTool 进行分析，之后操作其实和前者就差不多了。不过，这个方案和前者有一点区别就是，前者实际还是在浏览器环境中，所以生成的内存快照会有一些 DOM 对象的存在，会有一定的干扰。而这个方案，是直接调用底层 V8 的方法，生成的快照只有 Node.js 环境中的对象。
memwatch
这个可以在代码里直接使用，实时检测内存动态，当发生内存泄漏的时候，会触发 ‘leak’ 事件，会传递当前的堆状态，配合 heapdump 有奇效。
二、定位问题：
用 devTool 的可以忽略下面的过程：
打开 Chrome Devtools ，进入到 Profiles 选项卡，点 Load 按钮，加载之前生成的快照。
对于内存快照，有四个视图，Summary，Comparison，Containment，Statistics，这里面常用的是前三个。
在 Summary 视图中，我们可以看到当前快照的全部信息，以及多个快照之间的信息。在列表里显示的都是对象的构造函数名字，可以先忽略被括号包裹的对象，优先观察其他的对象，最后再来看他们。后面的 shallow size 表示的是对象自身的大小，retained size 表示的是对象和它依赖对象的大小，一般是 GC 不可达的。
在 Comparison 视图中，我们可以进行多个快照之间的对比，这个用处比较大，如果我们将前两次快照进行对比，可能比较快速的定位出问题的对象。注意观察 New、Deleted、Delta，如果是内存泄漏的对象，可能是一直在 New，而没有 Deleted。
在 Containment 视图中，我们可以查看整个 GC 路径，当然一般不会用到。因为展开在 Summary 和 Comparison 列举的每一项，都可以看到从 GC roots 到这个对象的路径。通过这些路径，你可以看到这个对象的句柄被什么持有，从而定位问题产生的原因。值的注意的是，其中背景色黄色的，表示这个对象在 Javascript 中还存在引用，所以可能没有被清除。如果是红色的，表示的是这个对象在 Javascript 中不存在引用，但是依然存活在内存中，一般常见于 DOM 对象，它们存放的位置和 Javascript 中对象还是有不同的，在 Node.js 中很少遇见。
