Nodejs 메모리 관리 단계에 대한 자세한 설명

이번에는 Nodejs 메모리 관리의 주의사항에 대해 자세히 설명드리겠습니다. 실제 사례를 살펴보겠습니다.

는 서로 다른 호스트 환경에서 실행되며 해당 메모리 관리에 대한 요구 사항도 다릅니다. 호스트 환경이 브라우저인 경우 웹 페이지의 실행 시간이 짧고 사용자 컴퓨터에서만 실행되기 때문입니다(분산과 동일). ), 메모리를 너무 많이 사용하거나 특정 메모리 누수가 발생하더라도 최종 사용자에게 큰 영향을 미치지 않습니다. 호스트 환경을 사용하여 서버(노드)를 프로그래밍하는 경우 상황이 매우 다릅니다. 코드 자체가 몇 개의 고정된 시스템(중앙 집중식)에서 실행되고 실행 시간이 오래 걸리므로 메모리 관리가 좋지 않습니다. 메모리 누수가 발생하더라도 서버 측 응답 시간이 길어지거나 서비스가 중단될 수도 있습니다.

Nodejs는 V8을 기반으로 구축되었기 때문에 Node에서 사용하는 JavaScript 객체(Buffer는 아님)는 기본적으로 V8을 통해 할당 및 관리됩니다. V8은 차지하는 메모리 크기에 제한을 둡니다(64비트 운영 체제의 경우 단일 노드 프로세스에서 사용할 수 있는 최대 힙 메모리 크기는 약 1.5GB입니다). 서버의 메모리가 크더라도 V8의 이러한 제한으로 인해 Node는 서버의 리소스를 완전히 활용할 수 없습니다. 그럼에도 불구하고 V8에는 왜 그러한 제한이 있습니까? 이러한 제한의 이유는 실제로 가비지 수집 메커니즘과 관련이 있습니다. 1.5GB 가비지 수집 힙 메모리 힙을 예로 들면, V8은 소규모 가비지 수집을 수행하는 데 50ms 이상이 걸리고 심지어 전체 가비지 수집을 수행하는 데 1초 이상이 걸립니다. 재활용 과정에서 JavaScript 스레드는 정지 상태에 있어야 하며, 일시적인 시간이 너무 길면 백엔드 서비스 성능에 큰 영향을 미치게 됩니다. 힙 메모리 제한. 그럼에도 불구하고 V8은 힙 메모리 크기(--max-old-pace-size)를 사용자 정의하는 방법을 제공합니다. old-space는 이전 세대를 나타내고 new-space는 새 세대를 나타냅니다.

node --max-old-space-size=xxx index.js //单位为MB
// 之前还可以通过-max-new-space-size来定义新生代堆大小，现在已经不可以了

메모리 누수로 인해 서버가 자주 다시 시작되는 경우 문제를 찾을 시간을 벌기 위해 먼저 힙 메모리 크기를 늘리는 것이 좋습니다. 결국 오류 페이지를 직접 반환하는 것보다 느린 서비스 응답이 사용자에게 더 좋습니다.

왜 구세대와 신세대가 필요한가?

세대별 가비지 수집 메커니즘에서 구세대와 신세대는 실제로 서로 다른 세대입니다. 왜냐하면 모든 시나리오에 적합한 가비지 수집 알고리즘은 없으며 서로 다른 객체 수명 주기에는 실제로 최상의 결과를 얻기 위해 서로 다른 재활용 전략이 필요하기 때문입니다. 그래서 V8은 세대별 가비지 수집 메커니즘을 채택합니다. 객체는 생존 시간에 따라 여러 세대로 구분된 다음 다양한 세대(신세대, 구세대)의 메모리에 더 적합하고 더 나은 알고리즘이 적용됩니다.

신세대의 객체는 생존 시간이 더 짧은 반면, 구세대의 객체는 생존 시간이 길거나 심지어 메모리에 상주합니다. 이를 기반으로 설계된 신세대의 메모리는 일반적으로 구세대의 메모리보다 훨씬 작습니다. V8에서 신세대의 최대 메모리는 32M(예를 들어 64비트 시스템)이며, 구세대의 최대 메모리는 생성 용량은 1400MB입니다. V8에서 사용하는 실제 힙 메모리 크기는 신세대에서 사용하는 메모리 + 구세대에서 사용하는 메모리(1432MB)의 합이지만, V8의 최대값은 실제로 사용되는 메모리 쌍 크기보다 32M(1464MB) 더 큽니다. 새로운 세대에서는 어떻게 가비지 수집을 수행합니까?

신세대에서는 Scavenge라는 가비지 수집 알고리즘을 사용합니다. Scavenge의 구체적인 구현에서는 Cheney 알고리즘이 주로 사용됩니다. Cheney 알고리즘은 신세대 힙을 두 개로 나누어 하나는 사용되고(From semispace) 다른 하나는 free(To semispace)입니다. 객체 생성 시

이제 From 공간에 할당됩니다. 가비지 수집이 필요한 경우 From 공간에 남아 있는 객체를 확인한 다음 남아 있는 객체를 동시에 To 공간에 복사합니다. From 공간은 지워지고 From과 To는 Exchange이며 전체 가비지 수집 프로세스는 두 seispace 사이에서 살아남은 개체를 복사하는 것입니다. 수명주기가 짧은 시나리오의 경우 살아남은 객체는 전체 객체에서 상대적으로 작은 비율을 차지하므로 Scavenge는 살아남은 객체를 복사하지만 Scavenge는 힙 메모리 공간의 절반만 사용할 수 있습니다. 이는 공간을 시간과 거래하는 전형적인 예입니다. .

当一个对象经过多次垃圾回收依然存活的话，就会被认为是生命周期较长的对象，一方面新生代堆比较小，另一方面重复复制生命周期长的对象也很没有效率，所以对于生命周期长的对象会被移到老生代中去。新生代对象移动到老生代有两个对象：1.对象是否是生命周期较长的对象（已经经历过垃圾回收）2.To空间使用占比是否超过了25%。限制25%的原因是由于垃圾回收完成后To会变成From，如果不做限制的话可能会出现From很快被用光的情况，出现频繁的垃圾回收，也会影响效率。

老生代如何做垃圾回收？

老生代由于存活对象占较大比重，不适合对存活对象进行操作，使用Scavenge算法就不太合适了，因此老生代采用了Mark-Sweep和Mark-Compact相结合的方式。

Mark-Sweep分为标记和清除两个阶段，在标记阶段遍历堆中所有对象，标记活着的对象，然后在清除阶段未被标记的对象将会被清除掉。Mark-Sweep解决了内存释放的问题但是由于没有像Scavenge那样复制对象的操作导致内存碎片化不连续。而Mark-Compact就是用来解决内存碎片化问题的。Mark-Compact会将存活的对象往一端移动，移动完成后直接清理掉边界外的内存，这样就有大段的连续可用内存了，但是由于涉及到对象的移动，因此Mark-Compact的速度要比Mark-Sweep慢了。V8主要使用Mark-Sweep，只有当空间不足以对新生代中今生过来的对象进行分配时才使用Mark-Compact。

垃圾回收过程中会导致应用程序暂停执行，由于新生代本身空间较小，且要复制的存活对象占比也少，因此即便执行全量垃圾回收也影响不大，但是老生代空间很大，存活对象也多，执行一次全量垃圾回收对于应用程序暂停会是一个比较长的时间，因此V8将老生的标记改成了增量更新的方式，使得标记和应用程序交替执行直到标记完成，然后垃圾回收再执行后面的清理工作。注意清理工作并不是增量的。

开发者可以指定强制垃圾回收吗？

答案是可以了，在启动node服务的时候使用--expose-gc flag

$ node --expose-gc file.js

这样全局对象上就有了执行垃圾回收的函数

global.gc();

推荐更安全的写法

function forceGC()
 if (global.gc) {
  global.gc();
 } else {
  console.warn('No GC hook! Start your program as `node --expose-gc file.js`.');
 }
}

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

Vue页面骨架屏注入步骤详解

解决node修改后需频繁手动重启如何处理

위 내용은 Nodejs 메모리 관리 단계에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!