根据 node.js 文档,一个 Node 在 32 位版本上有 512meg 的限制,在 64 位版本上有 1.4gig 的限制。 Chrome AFAICT 的限制类似。 (+/- 25%)
那么,为什么这段代码从不使用超过 ~424meg 的内存却会耗尽内存?
这是代码(代码是废话。这个问题不是关于代码在做什么,而是关于代码为什么失败)。
var lookup = 'superCaliFragilisticExpialidosiousThispartdoesnotrealllymattersd';
function encode (num) {
return lookup[num];
}
function makeString(uint8) {
var output = '';
for (var i = 0, length = uint8.length; i < length; i += 3) {
var temp = (uint8[i] << 16) + (uint8[i + 1] << 8) + (uint8[i + 2]);
output += encode(temp >> 18 & 0x3F) + encode(temp >> 12 & 0x3F) + encode(temp >> 6 & 0x3F) + encode(temp & 0x3F);
}
return output;
}
function test() {
var big = new Uint8Array(64 * 1024 * 1024 + 2); // multiple of 3
var str = makeString(big);
console.log("big:", big.length);
console.log("str:", str.length);
}
test();
如您所见,makeString 通过一次附加 4 个字符来构建一个字符串。在这种情况下,它将构建一个长度为 89478988 (180meg) 的大字符串。由于 output 被追加,最后一次追加字符时,内存中将有 2 个字符串。旧的有 89478984 个字符,最后一个有 89478988 个字符。GC 应该收集任何其他使用的内存。
因此,64meg(原始数组)+ 180meg * 2 = 424meg。远低于 v8 限制。
但是,如果您运行示例,它将因内存不足而失败
<--- Last few GCs --->
3992 ms: Scavenge 1397.9 (1458.1) -> 1397.9 (1458.1) MB, 0.2 / 0 ms (+ 1.5 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
4450 ms: Mark-sweep 1397.9 (1458.1) -> 1397.9 (1458.1) MB, 458.0 / 0 ms (+ 2.9 ms in 2 steps since start of marking, biggest step 1.5 ms) [last resort gc].
4909 ms: Mark-sweep 1397.9 (1458.1) -> 1397.9 (1458.1) MB, 458.7 / 0 ms [last resort gc].
$ node foo.js
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x3a8521e3ac1 <JS Object>
2: makeString(aka makeString) [/Users/gregg/src/foo.js:~6] [pc=0x1f83baf53a3b] (this=0x3a852104189 <undefined>,uint8=0x2ce813b51709 <an Uint8Array with map 0x32f492c0a039>)
3: test(aka test) [/Users/gregg/src/foo.js:19] [pc=0x1f83baf4df7a] (this=0x3a852104189 <undefined>)
4: /* anonymous */ [/Users/gregg/src/foo.js:24] [pc=0x1f83baf4d9e5] (this=0x2ce813b...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Abort trap: 6
Node 4.2.4和5.6.0都试过了
那么,问题是为什么内存不足?
一些我尝试过的东西。
我尝试加入 block
我没有无限期地附加到 output,而是尝试检查它是否
大于某个大小(如 8k)。如果是这样,我把它放在一个数组中,然后
将输出重置为空字符串。
通过执行此操作,输出 永远不会超过 8k。该阵列持有
180meg + 簿记。所以 180meg + 8k 比 180meg + 小很多
180兆。它仍然耗尽内存。现在,在那个过程的最后,我
加入数组,此时它实际上会使用更多内存
(180meg + 180meg + 簿记)。但是,v8 在到达之前就崩溃了
行。
我尝试将编码更改为
function encode(num) {
return 'X';
}
在这种情况下,它实际上运行到完成!所以我想,“啊哈!
该问题必须与 lookup[num] 生成相关
每次调用一个新字符串?所以我尝试了...
将 lookup 更改为字符串数组
var lookup = Array.prototype.map.call(
'superCaliFragilisticExpialidosiousThispartdoesnotrealllymattersd',
function(c) {
return c;
});
内存不足
这似乎是 v8 中的错误?由于此代码,它无法以某种奇怪的方式对未使用的字符串进行 GC,尽管 #2 与 #3 很奇怪,因为它们在内存使用方面看起来是等效的。
为什么 v8 在这些情况下会耗尽内存? (是否有解决方法)
最佳答案
TL;DR:您的示例是 v8 内部字符串表示之一的病态案例。您可以通过偶尔索引到 output 来修复它(有关原因的信息如下)。
首先,我们可以使用heapdump查看垃圾收集器在做什么:
上面的快照是在 Node 内存不足之前不久拍摄的。如您所见,大多数事情看起来都很正常:我们看到两个字符串(非常大的 output 和要添加的小块),三个对同一数组 big 的引用(大约 64MB,与我们的预期相似),以及许多看起来并不异常的小项目。
但是,有一件事很突出:output 是一个惊人的 1.4+ GB。在拍摄快照时,它大约有 8000 万个字符长,因此假设每个字符 2 个字节,大约 160 MB。这怎么可能?
也许这与 v8 的内部字符串表示有关。引用 mraleph :
There are two types [of v8 strings] (actually more, but for the problem at hand only these two are important):
- flat strings are immutable arrays of characters
- cons strings are pairs of strings, result of concatenation.
If you concat a and b you get a cons-string (a, b) that represents result of concatenation. If you later concat d to that you get another cons-string ((a, b), d).
Indexing into such a "tree-like" string is not O(1) so to make it faster V8 flattens the string when you index: copies all characters into a flat string.
那么 v8 是否可以将 output 表示为一棵巨树?一种检查方法是强制 v8 压平字符串(如上面 mraleph 所建议的),例如通过在 for 循环内定期索引到 output:
if (i % 10000000 === 0) {
// We don't do it at each iteration since it's relatively expensive.
output[0];
}
果然,程序成功运行了!
仍然存在一个问题:为什么上面的版本 2 可以运行?在那种情况下,v8 似乎能够优化大多数字符串连接(所有右侧的连接,它们都转换为 4 元素数组上的按位运算)。
关于javascript - 为什么在这种情况下 v8 会耗尽内存?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35354801/
类classAprivatedeffooputs:fooendpublicdefbarputs:barendprivatedefzimputs:zimendprotecteddefdibputs:dibendendA的实例a=A.new测试a.foorescueputs:faila.barrescueputs:faila.zimrescueputs:faila.dibrescueputs:faila.gazrescueputs:fail测试输出failbarfailfailfail.发送测试[:foo,:bar,:zim,:dib,:gaz].each{|m|a.send(m)resc
作为我的Rails应用程序的一部分,我编写了一个小导入程序,它从我们的LDAP系统中吸取数据并将其塞入一个用户表中。不幸的是,与LDAP相关的代码在遍历我们的32K用户时泄漏了大量内存,我一直无法弄清楚如何解决这个问题。这个问题似乎在某种程度上与LDAP库有关,因为当我删除对LDAP内容的调用时,内存使用情况会很好地稳定下来。此外,不断增加的对象是Net::BER::BerIdentifiedString和Net::BER::BerIdentifiedArray,它们都是LDAP库的一部分。当我运行导入时,内存使用量最终达到超过1GB的峰值。如果问题存在,我需要找到一些方法来更正我的代
我有一个模型:classItem项目有一个属性“商店”基于存储的值,我希望Item对象对特定方法具有不同的行为。Rails中是否有针对此的通用设计模式?如果方法中没有大的if-else语句,这是如何干净利落地完成的? 最佳答案 通常通过Single-TableInheritance. 关于ruby-on-rails-Rails-子类化模型的设计模式是什么?,我们在StackOverflow上找到一个类似的问题: https://stackoverflow.co
我正在使用的第三方API的文档状态:"[O]urAPIonlyacceptspaddedBase64encodedstrings."什么是“填充的Base64编码字符串”以及如何在Ruby中生成它们。下面的代码是我第一次尝试创建转换为Base64的JSON格式数据。xa=Base64.encode64(a.to_json) 最佳答案 他们说的padding其实就是Base64本身的一部分。它是末尾的“=”和“==”。Base64将3个字节的数据包编码为4个编码字符。所以如果你的输入数据有长度n和n%3=1=>"=="末尾用于填充n%
我主要使用Ruby来执行此操作,但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式,例如使用这个yaml文件,它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i
为什么4.1%2返回0.0999999999999996?但是4.2%2==0.2。 最佳答案 参见此处:WhatEveryProgrammerShouldKnowAboutFloating-PointArithmetic实数是无限的。计算机使用的位数有限(今天是32位、64位)。因此计算机进行的浮点运算不能代表所有的实数。0.1是这些数字之一。请注意,这不是与Ruby相关的问题,而是与所有编程语言相关的问题,因为它来自计算机表示实数的方式。 关于ruby-为什么4.1%2使用Ruby返
这是在Ruby中设置默认值的常用方法:classQuietByDefaultdefinitialize(opts={})@verbose=opts[:verbose]endend这是一个容易落入的陷阱:classVerboseNoMatterWhatdefinitialize(opts={})@verbose=opts[:verbose]||trueendend正确的做法是:classVerboseByDefaultdefinitialize(opts={})@verbose=opts.include?(:verbose)?opts[:verbose]:trueendend编写Verb
我正在尝试在我的centos服务器上安装therubyracer,但遇到了麻烦。$geminstalltherubyracerBuildingnativeextensions.Thiscouldtakeawhile...ERROR:Errorinstallingtherubyracer:ERROR:Failedtobuildgemnativeextension./usr/local/rvm/rubies/ruby-1.9.3-p125/bin/rubyextconf.rbcheckingformain()in-lpthread...yescheckingforv8.h...no***e
它不等于主线程的binding,这个toplevel作用域是什么?此作用域与主线程中的binding有何不同?>ruby-e'putsTOPLEVEL_BINDING===binding'false 最佳答案 事实是,TOPLEVEL_BINDING始终引用Binding的预定义全局实例,而Kernel#binding创建的新实例>Binding每次封装当前执行上下文。在顶层,它们都包含相同的绑定(bind),但它们不是同一个对象,您无法使用==或===测试它们的绑定(bind)相等性。putsTOPLEVEL_BINDINGput
我想在一个没有Sass引擎的类中使用Sass颜色函数。我已经在项目中使用了sassgem,所以我认为搭载会像以下一样简单:classRectangleincludeSass::Script::FunctionsdefcolorSass::Script::Color.new([0x82,0x39,0x06])enddefrender#hamlengineexecutedwithcontextofself#sothatwithintemlateicouldcall#%stop{offset:'0%',stop:{color:lighten(color)}}endend更新:参见上面的#re