ChatGPT解决这个技术问题 Extra ChatGPT

What is JavaScript garbage collection?

What is JavaScript garbage collection? What's important for a web programmer to understand about JavaScript garbage collection, in order to write better code?


B
Ben Aston

Eric Lippert wrote a detailed blog post about this subject a while back (additionally comparing it to VBScript). More accurately, he wrote about JScript, which is Microsoft's own implementation of ECMAScript, although very similar to JavaScript. I would imagine that you can assume the vast majority of behaviour would be the same for the JavaScript engine of Internet Explorer. Of course, the implementation will vary from browser to browser, though I suspect you could take a number of the common principles and apply them to other browsers.

Quoted from that page:

JScript uses a nongenerational mark-and-sweep garbage collector. It works like this: Every variable which is "in scope" is called a "scavenger". A scavenger may refer to a number, an object, a string, whatever. We maintain a list of scavengers -- variables are moved on to the scav list when they come into scope and off the scav list when they go out of scope. Every now and then the garbage collector runs. First it puts a "mark" on every object, variable, string, etc – all the memory tracked by the GC. (JScript uses the VARIANT data structure internally and there are plenty of extra unused bits in that structure, so we just set one of them.) Second, it clears the mark on the scavengers and the transitive closure of scavenger references. So if a scavenger object references a nonscavenger object then we clear the bits on the nonscavenger, and on everything that it refers to. (I am using the word "closure" in a different sense than in my earlier post.) At this point we know that all the memory still marked is allocated memory which cannot be reached by any path from any in-scope variable. All of those objects are instructed to tear themselves down, which destroys any circular references.

The main purpose of garbage collection is to allow the programmer not to worry about memory management of the objects they create and use, though of course there's no avoiding it sometimes - it is always beneficial to have at least a rough idea of how garbage collection works.

Historical note: an earlier revision of the answer had an incorrect reference to the delete operator. In JavaScript the delete operator removes a property from an object, and is wholly different to delete in C/C++.


the Apple guide is flawed: the autor uses delete incorrectly; eg in the first example, instead of delete foo, you should first remove the event listener via window.removeEventListener() and then use foo = null to overwrite the variable; in IE, delete window.foo (but not delete foo) also would have worked if foo was global, but even then it wouldn't in FF or Opera
Be aware that the Eric's article should be considered "for historical purposes only". But it's still informative.
Also note - IE 6 and 7 DO NOT use a nongenerational mark-and-sweep garbage collector. They use a simple reference counting garbage collector, which is more vulnerable to circular reference problems with garbage collection.
ECMAScript's delete is an unary operator (an expression), not a statement (i.e.: delete 0, delete 0, delete 3). It looks like statement when expressed by an expression statement.
Yeh the answer at the time is now outdated, as of 2012, modern browsers use a mark/sweep algorthm.. so it's not scope dependent anymore. Referencing: developer.mozilla.org/en-US/docs/Web/JavaScript/…
C
Christoph

Beware of circular references when DOM objects are involved:

Memory leak patterns in JavaScript

Keep in mind that memory can only be reclaimed when there are no active references to the object. This is a common pitfall with closures and event handlers, as some JS engines will not check which variables actually are referenced in inner functions and just keep all local variables of the enclosing functions.

Here's a simple example:

function init() {
    var bigString = new Array(1000).join('xxx');
    var foo = document.getElementById('foo');
    foo.onclick = function() {
        // this might create a closure over `bigString`,
        // even if `bigString` isn't referenced anywhere!
    };
}

A naive JS implementation can't collect bigString as long as the event handler is around. There are several ways to solve this problem, eg setting bigString = null at the end of init() (delete won't work for local variables and function arguments: delete removes properties from objects, and the variable object is inaccessible - ES5 in strict mode will even throw a ReferenceError if you try to delete a local variable!).

I recommend to avoid unnecessary closures as much as possible if you care for memory consumption.


The DOM circular reference bug is specific to JScript -- no other browser suffers it but IE. In fact i'm fairly sure that the ECMAScript spec explicitly states that the GC must be able to handle such cycles :-/
@olliej: I don't see any mention of the GC in the ECMAScript spec.
a
alex

Good quote taken from a blog

The DOM component is "garbage collected", as is the JScript component, which means that if you create an object within either component, and then lose track of that object, it will eventually be cleaned up.

For example:

function makeABigObject() {
var bigArray = new Array(20000);
}

When you call that function, the JScript component creates an object (named bigArray) that is accessible within the function. As soon as the function returns, though, you "lose track" of bigArray because there's no way to refer to it anymore. Well, the JScript component realizes that you've lost track of it, and so bigArray is cleaned up--its memory is reclaimed. The same sort of thing works in the DOM component. If you say document.createElement('div'), or something similar, then the DOM component creates an object for you. Once you lose track of that object somehow, the DOM component will clean up the related.


H
Heat Miser

To the best of my knowledge, JavaScript's objects are garbage collected periodically when there are no references remaining to the object. It is something that happens automatically, but if you want to see more about how it works, at the C++ level, it makes sense to take a look at the WebKit or V8 source code

Typically you don't need to think about it, however, in older browsers, like IE 5.5 and early versions of IE 6, and perhaps current versions, closures would create circular references that when unchecked would end up eating up memory. In the particular case that I mean about closures, it was when you added a JavaScript reference to a dom object, and an object to a DOM object that referred back to the JavaScript object. Basically it could never be collected, and would eventually cause the OS to become unstable in test apps that looped to create crashes. In practice these leaks are usually small, but to keep your code clean you should delete the JavaScript reference to the DOM object.

Usually it is a good idea to use the delete keyword to immediately de-reference big objects like JSON data that you have received back and done whatever you need to do with it, especially in mobile web development. This causes the next sweep of the GC to remove that object and free its memory.


Is the JavaScript -> DOM -> JavaScript circular reference problem solved in newer versions of IE? If so, since when? I thought it was architecturally very deep down and unlikely to ever get fixed. Do you have any sources?
Just anecdotally. I haven't noticed the crazy leaks in IE 8 running in standards mode, not the broken mode. I'll adjust my response.
@erikkallen: yes, the GC bug has been fixed in IE versions 8+, as the older ones were using a very naive garbage collection algorithm, which made it impossible to GC a pair of objects referring to each other. The newer mark-and-sweep style algorithms take care of this.
A
Ahmed Gaber - Biga

garbage collection (GC) is a form of automatic memory management by removing the objects that no needed anymore.

any process deal with memory follow these steps:

1 - allocate your memory space you need

2 - do some processing

3 - free this memory space

there are two main algorithm used to detect which objects no needed anymore.

Reference-counting garbage collection: this algorithm reduces the definition of "an object is not needed anymore" to "an object has no other object referencing to it", the object will removed if no reference point to it

Mark-and-sweep algorithm: connect each objects to root source. any object doesn't connect to root or other object. this object will be removed.

currently most modern browsers using the second algorithm.


And to add a source of this, see the MDN: developer.mozilla.org/en-US/docs/Web/JavaScript/…
m
mtasic85

"In computer science, garbage collection (GC) is a form of automatic memory management. The garbage collector, or just collector, attempts to reclaim garbage, or memory used by objects that will never be accessed or mutated again by the application."

All JavaScript engines have their own garbage collectors, and they may differ. Most time you do not have to deal with them because they just do what they supposed to do.

Writing better code mostly depends of how good do you know programming principles, language and particular implementation.


A
Ani Naslyan

Reference types do not store the object directly into the variable to which it is assigned, so the object variable in the example below, doesn’t actually contain the object instance. Instead, it holds a pointer (or reference) to the location in memory, where the object exists.

var object = new Object();

if you assign one reference typed variable to another, each variable gets a copy of the pointer, and both still reference to the same object in memory.

var object1 = new Object();
var object2 = object1;

https://i.stack.imgur.com/CTFQt.png

JavaScript is a garbage-collected language, so you don’t really need to worry about memory allocations when you use reference types. However, it’s best to dereference objects that you no longer need so that the garbage collector can free up that memory. The best way to do this is to set the object variable to null.

var object1 = new Object();
// do something
object1 = null; // dereference

Dereferencing objects is especially important in very large applications that use millions of objects.

from The Principles of Object-Oriented JavaScript - NICHOLAS C. ZAKAS


d
dfa

What is JavaScript garbage collection?

check this

What's important for a web programmer to understand about JavaScript garbage collection, in order to write better code?

In Javascript you don't care about memory allocation and deallocation. The whole problem is demanded to the Javascript interpreter. Leaks are still possible in Javascript, but they are bugs of the interpreter. If you are interested in this topic you could read more in www.memorymanagement.org


Which of the various memory management systems in the article you link to is the one used by JavaScript? "Leaks are still possible in Javascript, but they are bugs of the interpreter." - That doesn't mean JS programmers can simply ignore the whole issue, for example there is a pretty well-known JS<->DOM circular reference issue in older versions of IE that you could work around in your JS code. Also, the way JS closures work is a design feature, not a bug, but you can tie up larger chunks of memory than intended if you use closures "inappropriately" (I'm not saying don't use 'em).
Memory leaks are a beast in JavaScript. If you're writing a simple "college project" application, then no worries. But when you start writing high-performance enterprise-level apps, memory management in JavaScript is a must.
p
powtac

On windows you can use Drip.exe to find memory leaks or check if your free mem routine works.

It's really simple, just enter a website URL and you will see the memory consumption of the integrated IE renderer. Then hit refresh, if the memory increases, you found a memory leak somewhere on the webpage. But this is also very useful to see if routines for freeing memory work for IE.


S
SuperNova

In javascript, garbage collection is non-deterministic, when an object will be cleared, or if it ever will be. This applies to objects which are strong referenced. Strong referenced objects are protected from Garbage collection.

After ES12, the below implementation can be done to check when an object is garbage collected.

To understand more about garbage collection in javascript, you can use Finalisers available after ES12.

let a = new Array(200).fill(true);

to construct finaliaser

const cleanup = new FinalizationRegistry(key => {
  // your code here
});

cleanup.register(a, 'wewew');

Object 'a' is now non-reachable, finalizer callback will happen after garbage collection