Node.js 将JSONStream.parsed（）数据通过es.map（）和JSONStream.stringify（）传递到文件流时，节点堆耗尽

我试图通过JSONStream.parse（）将输入流（从一个巨大的GeoJSON文件创建）分解为对象，然后通过event stream.map（）转换对象，然后通过JSONStream.stringify（）从中创建字符串，最后转换为可写输出流。当进程运行时，我可以看到节点的内存占用继续增长，直到它最终耗尽堆。下面是重新创建问题的最简单脚本（test.js）：

const fs = require("fs")
const es = require("event-stream")
const js = require("JSONStream")

out = fs.createWriteStream("/dev/null")
process.stdin
    .pipe(js.parse("features.*"))
    .pipe(es.map( function(data, cb) { 
        cb(null, data);
        return;
    } ))
    .pipe(js.stringify("{\n\"type\": \"FeatureCollection\", \"features\": [\n\t", ",\n\t", "\n]\n}"))
    .pipe(out)

一个小bash脚本（barf.sh）向node的process.stdin中注入源源不断的JSON将导致node的堆逐渐增长：

#!/bin/bash

echo '{"type":"FeatureCollection","features":['
while :
do
    echo '{"type":"Feature","properties":{"name":"A Street"}, "geometry":{"type":"LineString"} },'
done

按如下方式运行：

barf.sh | node test.js

有两种奇怪的方法可以回避这个问题：

• 删除fs.createWriteStream（）并将最后一个管道阶段从“.pipe（out）”更改为“.pipe（process.stdout）”，然后将管道节点的stdout更改为/dev/null
• 将异步es.map（）更改为同步es.mapSync（）

前面两个操作中的任何一个都将允许脚本永远运行，节点的内存占用很低且不变。我在一台8核机器上使用NodeV6.3.1、event stream v3.3.4和JSONStream 1.1.4，该机器的内存为8GB，运行Ubuntu 16.04

---

我希望有人能帮我纠正我确定的明显错误。

JSONStream不是流2流，因此它不支持背压控制。（这里有一个关于流2的简要总结）

这意味着数据将从

data

事件中的

parse

流中出来，并且无论消费流是否准备就绪，流都将不断地将它们输出。如果在管道中的某个地方，读写速度之间存在差异，就会出现缓冲——这就是你所看到的

您的

barf.sh

线束可通过

stdin

查看泵入的功能。相反，如果您正在读取大量文件，则应该能够通过暂停文件的读取流来管理流。因此，如果您要在

map

回调中插入一些

pause/resume

逻辑，您应该能够让它处理大量文件；只需要再花一点时间。我会做这样的实验：

let in = fs.createReadStream("/some/massive/file");
let out = fs.createWriteStream("/dev/null");
in
    .pipe(js.parse("features.*"))
    .pipe(es.map(function(data, cb) {
        // This is just an example; a 10-millisecond wait per feature would be very slow.
        if (!in.isPaused()) {
            in.pause();
            global.setTimeout(function () { in.resume(); }, 10);
        }
        cb(null, data);
        return;
    }))
    .pipe(js.stringify("{\n\"type\": \"FeatureCollection\", \"features\": [\n\t", ",\n\t", "\n]\n}"))
    .pipe(out);

---

顺便说一句，使用

mapSync

对我的计算机（既旧又慢）几乎没有影响。但是，除非您要在

map

中执行一些异步操作，否则我将使用

mapSync

谢谢。坦率地说，我仍然感到困惑，为什么将目标流更改为process.stdout会允许代码无限期地运行，而不会增加内存。你能重现这种行为吗？对我来说，当管道传输到标准输出时，它似乎仍在消耗内存，但速度要低得多。我猜

fs

基础设施一定比

stdout

慢，即使对于

/dev/null

。所有推送流都有问题；使用RxJS也会遇到类似的情况。我认为你最好的办法是做一些暂停阅读的实验。也许每1000个功能就暂停一下？