Garbage Collection

The 30-second version

Every {} in JavaScript and every &User{} or make([]byte, n) in Go that lands on the heap takes some memory. Your program creates millions of these. If nothing ever gave that memory back, even a small server would run out within minutes.

Why not just free memory by hand?

Languages like C make you the busser: you call malloc to get memory and free to give it back. That sounds simple, but you must free every object exactly once, after its last use, on every code path. Get it wrong and you get three classic bugs:

• Freeing too early: a Use-after-freeUse-after-freeA bug in manually managed languages: memory is freed, then still read or written through an old pointer. By then the memory may hold someone else's data, so the program reads garbage or corrupts it. — you keep using memory that now belongs to something else.
• Freeing twice: a Double freeDouble freeFreeing the same piece of memory twice. The allocator's bookkeeping gets corrupted, which usually crashes the program later, far from the real bug., which corrupts the bookkeeping of the allocatorMemory allocator (malloc)The part of a runtime or C library that hands out heap memory in chunks and takes it back when freed. Go and V8 have their own allocators tuned for their garbage collectors. (the code that hands out and takes back memory).
• Never freeing: a Memory leakMemory leakMemory that your program no longer needs but can't free, because something still holds a reference to it. In garbage-collected languages, a forgotten listener or map entry is the usual culprit., which slowly eats all the memory until the process is killed.

Step through them, then flip to the Go tab to see what a GC changes. (The C code reads like Go: malloc asks for memory, free gives it back, -> reads a field through a pointer.)

1User *u = malloc(sizeof(User));   // ask the allocator for memory
2u->name = "Ana";
3free(u);                          // hand it back…
4Order *o = malloc(sizeof(Order)); // …the allocator reuses the spot
5o->total = 99;
6printf("%s", u->name);            // use-after-free!
7free(u);                          // double free!

What a GC buys you, and what it costs

Most of this topic is about that bill: how collectors keep pauses tiny (§04, §07), how to tune the trade-off between memory and CPU (§08), and why a GC'd program can still leak memory (§09).

Garbage = unreachable

The collector can't read your mind. It doesn't know whether you'll use an object again — only whether you could. So it uses a mechanical rule: if your code can still get to the object somehow, it must stay.

Where can your code start from?

Think about what your code can touch at any moment without being handed anything:

• Local variables of every function that's running right now. Each GoroutineGoroutineA very lightweight task in Go, started with the go keyword. The Go runtime runs thousands of them on just a few OS threads. or thread has its own Call stackCall stackThe list of functions that are running right now — each one sits on top of the one that called it. When a function returns, its entry (and its local variables) is thrown away., and every Stack frameStack frameOne function call's entry on the call stack (one “plate”), holding that call's local variables. on it holds locals.
• Global variables (Go's package-level vars, JavaScript's module-level variables and globalThis).
• CPU registers: values the processor is working with this instant. (A CPU registerCPU registerA tiny storage slot inside one CPU core where it does arithmetic. To add 1 to a variable, the core copies it from memory into a register, adds, and copies it back. is a tiny storage slot inside the CPU.)

These are the roots. From a root, follow every reference (in Go a PointerPointer (*T, &v)A value that holds the memory address of another value instead of a copy of it. In Go, &v takes v's address and *T is the type “pointer to T”; changes made through a pointer are seen by everyone holding it. JS objects behave like this automatically., in JavaScript any object, array or function value): the variable req points at a Request object, the Request has a user field pointing at a User, and so on. Drawn out, this is the Object graphObject graphAll the objects in memory, drawn as dots, with an arrow for every reference from one object to another. The garbage collector walks this graph.. Everything you can reach by following arrows is ReachableReachableAn object is reachable if you can get to it by following references (pointers) starting from a root. Reachable = kept. Unreachable = garbage, even if other garbage still points at it., or live. Everything else is garbage.

let req = { user: { name: "Ana" } }; // root `req` → Request → User
let user = req.user;                 // a second path to the same User
req = null;                          // Request: unreachable → garbage
                                     // User: still reachable via `user` → live

Two ways to find the garbage

Reference countingReference countingA memory-management scheme where every object keeps a count of how many references point at it, and is freed the moment the count drops to 0. Simple and immediate, but two objects pointing at each other (a cycle) never reach 0. sounds simpler and frees memory sooner. But try deleting User → Avatar in reference-counting mode below: the Avatar and its Thumb point at each other, so their counts never reach zero. They're unreachable and never freed. A Tracing garbage collectionTracing garbage collectionA collector that finds live objects by starting at the roots and following every reference ("tracing" the graph). Whatever it never reaches is garbage. Go and V8 both trace. collector frees them without a second thought.

A few things to try:

1. Tracing mode: delete Request → Theme, run the GC. The Theme survives — Config still points at it. One path from a root is enough.
2. Tracing mode: delete req → Request. Request, User, Avatar and Thumb all go in one collection, cycle and all.
3. Reference counting: delete User → Avatar. The Avatar ↔ Thumb pair stays forever, in yellow: a leak.

Mark & sweep

Mark & sweepMark & sweepThe classic tracing algorithm. Mark: walk from the roots and tag every object you reach. Sweep: go through the whole heap and free every object without a tag. is the oldest tracing algorithm (1960, for Lisp) and still the core of Go's collector and V8's old generation. Every fancier design in this topic is mark & sweep with tricks added to make it faster or less disruptive.

Back to the restaurant: the busser marks every table with someone sitting at it — or with a coat on a chair that belongs to someone sitting elsewhere. Then they sweep the room: every unmarked table gets cleared.

1function collect() {
2  stopTheWorld();     // pause the program
3  for (const r of roots) mark(r);
4  sweep();
5  resumeTheWorld();
6}
7function mark(obj) {
8  if (obj.marked) return; // seen it
9  obj.marked = true;
10  for (const c of obj.refs) mark(c);
11}
12function sweep() {
13  for (const obj of heap) {
14    if (obj.marked) obj.marked = false;
15    else free(obj);   // garbage
16  }
17}

The two phases, in plain words

1. Mark. Start at each root. Mark the object it points at, then everything that object points at, and so on. If you reach an object that's already marked, stop — that's how cycles are handled, and how shared objects get visited only once.
2. Sweep. Walk the whole heap. Unmarked objects are garbage: their memory goes onto a Free listFree listThe allocator's list of empty gaps in the heap. Sweeping adds freed objects to it; the next allocation takes a gap that is big enough. for future allocations. Marked objects get their mark cleared, ready for the next cycle.

Notice what the collector's work depends on. Marking costs time proportional to the live objects (only they get visited). Sweeping costs time proportional to the whole heap. Hold on to that: it's why the generational trick in §05 is so effective.

Two problems with the simple version

Problem 1: holes. After a sweep, free memory is scattered in gaps between survivors. That's Heap fragmentationHeap fragmentationWhen the free memory in a heap is split into many small gaps between live objects. There may be plenty of free bytes in total, but no single gap big enough for a large object.: plenty of free bytes in total, but maybe no single gap big enough for a large object. Some collectors fix it with CompactionCompaction (GC)Moving live objects next to each other so all the free space forms one big block. It fixes fragmentation but means every pointer to a moved object must be updated.: slide the survivors together and update every pointer to them. Others, like Go's, avoid it by grouping objects of similar size together on the same memory pages (§07).

Problem 2: the pause. In the stepper the collector began with stopTheWorld(). That's a Stop-the-world pauseStop-the-world pauseA moment when the garbage collector pauses every thread of your program so it can safely do part of its work. Modern collectors keep these pauses very short (often well under a millisecond). pause: every thread of your program is frozen while the GC works. Why? If your code kept moving pointers around during marking, the collector could miss a live object and free it (§04 shows exactly how).

The catch is that a full mark & sweep of a big heap can take a long time. For a 10 GB heap that could be hundreds of milliseconds, maybe seconds — and every request in flight waits.

For a batch job, one big pause is fine; for a web server, a 300 ms freeze is a timeout for every user caught in it. So modern collectors do most of the work while your program runs. That's the next section.

Marking while the program runs: tri-color and write barriers

Three ways to shrink a pause

GC people use three words that sound alike but mean different things. All three are used by both Go and V8:

Incremental and concurrent marking share one big problem. In GC jargon, your program is the MutatorMutatorGC jargon for "your program": the code that allocates objects and changes (mutates) pointers between them, while the collector tries to find the garbage.: it changes (mutates) pointers. If the mutator keeps rewiring the object graph while the collector walks it, the collector can miss something. To see how, we need a better way to describe "how far marking has got".

Tri-color marking

Tri-color markingTri-color markingA way to describe marking with three colors. White = not seen yet (garbage if still white at the end). Grey = seen, but its references not checked yet. Black = seen and fully checked. gives every object one of three colors:

Marking is just: make the roots' targets grey; then, repeatedly, pick a grey object, make everything it points at grey (if it's still white), and turn it black. When no grey objects are left, every white object is unreachable → garbage. It's the same mark phase as §03, with the to-do list made explicit.

The colors let the collector stop and resume at any point (just keep the grey list), which is what makes incremental and concurrent marking possible. They also let us state the one rule that must never break:

The bug, then the fix

Step through with the barrier off. Your program does two ordinary-looking writes: copy a pointer into A, then clear it from B. Then turn the barrier on and run it again.

1// Your program, while the GC marks.
2// Copy B's pointer to C into A:
3a.child = b.child
4// Then remove it from B:
5b.child = nil

Without help, the collector would free C while A still uses it — a use-after-free caused by the garbage collector itself. The fix is a Write barrierWrite barrierA few extra instructions the compiler adds to every pointer write (like a.child = b). They tell the collector about the change — so concurrent marking can't miss a live object, and a generational GC can track pointers from old objects to young ones.: while marking is in progress, the compiler-generated code for every pointer write (like a.child = c) also does a tiny extra step. One classic version (Dijkstra's) shades the newly stored object grey, so a black object can never end up pointing at a white one.

a.child = c // what you write
// what runs while the GC is marking (roughly):
//   if gcIsMarking { shade(c) }  // white → grey: "don't forget this one"
//   a.child = c

You never write a barrier yourself. The Go compiler and V8 insert them automatically, and when no GC is running they cost little more than a check of one flag.

Most objects die young: generational GC

Think of what a web server allocates per request: a parsed JSON body, some strings, a few arrays, a response object. Milliseconds later the response is sent and all of it is garbage. Meanwhile a handful of objects — the config, a connection pool, a cache — live as long as the process.

This pattern is so common it has a name: the Generational hypothesisGenerational hypothesisThe observation that most objects die young: a request's temporary strings and arrays become garbage within milliseconds, while a few objects (caches, config) live for the whole program.. Real measurements across many languages agree: typically the large majority of objects (often quoted as 80–98%) die before the next collection.

Split the heap by age

A generational collector splits the heap in two:

• The Young generationYoung generation (nursery)A small heap area where new objects are created. It is collected often and cheaply, because most objects in it are already dead. (also called the nursery): small, where every new object starts. Collected often, in a Minor GCMinor GCA collection of only the young generation. Fast, because it only touches the (few) live young objects..
• The Old generationOld generationThe heap area for objects that survived a few young-generation collections. It is collected rarely, with a slower full collection.: big, for objects that have survived a couple of minor GCs. Collected rarely, in a Major GCMajor GC (full GC)A collection of the whole heap, including the old generation. More work, done less often. that covers the whole heap.

Moving a survivor from young to old is called PromotionPromotion (tenuring)Moving an object that has survived enough young-generation collections into the old generation, so it stops being copied around.. Once promoted, an object stops being looked at on every minor GC.

Why a minor GC is so cheap: copy the survivors

Many young generations (V8's among them) use Semi-space copyingSemi-space copyingA young-generation design with two equal halves. New objects fill one half; a collection copies the live ones into the other half and then treats the first half as empty. Dead objects cost nothing — they're never touched.. The nursery has two equal halves, from-space and to-space:

1. New objects are placed one after another in from-space. Allocating is just "bump a pointer to the next free byte" — about as cheap as allocation gets.
2. When from-space is full, a minor GC finds the live objects (starting from the roots, like any tracing collector) and copies them into to-space, packed tightly. Objects that already survived once are promoted to the old generation instead.
3. Everything left in from-space is garbage. It isn't freed one by one; the whole half is simply considered empty. Then the two halves swap names.

The work done is proportional to the number of survivors — the dead objects are never touched. If 95% died, you only copy 5%. Run it and watch the counters:

Notice that the copying also compacts for free: survivors end up side by side, so the nursery never fragments.

The catch: pointers from old to young

A minor GC wants to scan only the nursery. But what if an old object points at a young one — say, a long-lived cache (old) gets a fresh entry (young)? The cache isn't a root, and the minor GC doesn't scan the old generation, so the new entry would look unreachable.

The fix reuses an idea from §04. A write barrier watches every pointer write; when the program stores a young object into an old one, the barrier records that spot in a Remembered setRemembered setA list, kept up to date by the write barrier, of places in the old generation that point at young objects. A minor GC treats those places as extra roots so it doesn't have to scan the whole old generation.. A minor GC treats those recorded spots as extra roots. That's why generational collectors need a write barrier even when they aren't concurrent.

const cache = new Map();          // created at startup → long since promoted (old)

function handle(req) {
  const entry = { at: Date.now() }; // brand new → young
  cache.set(req.id, entry);         // old → young pointer: the write barrier
                                    // remembers it, so the next minor GC keeps `entry`
}

Node's collector: V8 and Orinoco

Everything from §02–§05 shows up in V8V8The JavaScript engine (the part that actually executes JS) inside Chrome and Node.js., the engine that runs JavaScript in Node and Chrome:

Orinoco: keeping the main thread free

JavaScript runs your code on one main thread, so any GC work on that thread delays your callbacks directly. OrinocoOrinocoThe project name for V8's modern garbage collector, which moved most GC work off the main JavaScript thread using parallel, incremental and concurrent techniques. applied all three techniques from §04:

• Scavenges are parallel. JavaScript does pause, but several helper threads copy survivors together, so the pause is short.
• Old-generation marking is concurrent and incremental. Helper threads mark while your JavaScript keeps running; the main thread does small marking steps now and then. A write barrier keeps it correct.
• Compaction is parallel; sweeping is concurrent. Only a short final pause remains, to finish marking and move objects.

Watching it: --trace-gc

Run any script with node --trace-gc and V8 prints one line per collection. Here's a real run on this machine (Node 22) of a script that creates 3 million small objects and keeps 1 in 10 forever:

const keep = [];                       // long-lived: grows to 300k objects
const recent = new Array(1000);        // short-lived: each slot is overwritten soon
for (let i = 0; i < 3_000_000; i++) {
  const obj = { id: i, name: "user" + i };
  recent[i % 1000] = obj;              // the old object in this slot becomes garbage
  if (i % 10 === 0) keep.push(obj);    // 1 in 10 survives forever
}
console.log("done", keep.length);

$ node --trace-gc alloc.js
[9723:0xa3a6000]   49 ms: Scavenge 6.1 (8.8) -> 4.7 (8.8) MB, pooled: 0 MB, 0.60 / 0.00 ms  (average mu = 1.000, current mu = 1.000) allocation failure;
[9723:0xa3a6000]   50 ms: Scavenge 6.1 (8.8) -> 4.9 (9.1) MB, pooled: 0 MB, 0.76 / 0.00 ms  (average mu = 1.000, current mu = 1.000) allocation failure;
…
[9723:0xa3a6000]  250 ms: Mark-Compact 16.8 (45.7) -> 14.6 (48.0) MB, pooled: 0 MB, 54.50 / 0.00 ms  (+ 1.8 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 65 ms) (average mu = 0.775, current mu = 0.775) finalize incremental marking via stack guard; GC in old space requested
…
[9723:0xa3a6000]  404 ms: Scavenge 47.3 (65.0) -> 34.1 (65.7) MB, pooled: 0 MB, 4.64 / 0.00 ms  (average mu = 0.775, current mu = 0.775) allocation failure;
done 300000

Reading one line, left to right:

In this run there were 33 scavenges (each 0.6–5 ms) and one Mark-Compact. That's the generational hypothesis at work: almost all objects died in the nursery. The Mark-Compact paused for 54 ms on this machine — rare, but exactly the kind of pause you'll see in tail latency. The walltime since start of marking 65 ms shows marking had been running concurrently for 65 ms before that final pause.

The heap limit, and how Node dies

V8 caps the old generation at a Heap limitHeap limitThe maximum size a runtime lets its heap grow to. For Node, V8's old-generation limit is set with --max-old-space-size; going past it crashes with "JavaScript heap out of memory".. Recent Node versions pick a default based on the machine's memory; check yours with node -e 'console.log(require("v8").getHeapStatistics().heap_size_limit / 2**20)' (on this 16 GB machine: 2096 MB). Set it explicitly with --max-old-space-size (in MB). When live data won't fit, V8 runs Mark-Compact after Mark-Compact, each freeing less, then gives up. Real output, with a deliberately small limit and a Map that's never cleared:

const cache = new Map();               // never evicted → grows forever
let i = 0;
while (true) {
  cache.set(i, { id: i, payload: "x".repeat(100) + i });
  i++;
}

$ node --max-old-space-size=64 oom.js
<--- Last few GCs --->
[10239:0x20371000]  425 ms: Mark-Compact 70.0 (87.9) -> 68.8 (103.4) MB, pooled: 0 MB, 112.97 / 0.00 ms  (average mu = 0.419, current mu = 0.193) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
 1: 0xe40d24 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 …
$ echo $?
134

Read the last GC line: 70.0 → 68.8 MB. The collector freed almost nothing, because almost everything was reachable through cache. And current mu = 0.193: the GC was eating 80% of the time just before the crash. Exit code 134 means the process aborted itself (128 + signal 6, SIGABRT). Raising the limit only delays this; the real fix is to stop holding on to everything (§09).

Checking memory from code

const mb = (n) => (n / 2 ** 20).toFixed(1) + " MB";
const m = process.memoryUsage();
console.log({
  rss: mb(m.rss),             // all memory the OS gave this process
  heapTotal: mb(m.heapTotal), // memory V8 reserved for the JS heap
  heapUsed: mb(m.heapUsed),   // memory used by JS objects right now
  external: mb(m.external),   // memory outside the JS heap tied to JS objects (Buffers…)
});

Go's collector: concurrent, non-moving, non-generational

Go's design is the opposite of V8's in two ways, and both are deliberate:

Not moving objects keeps things simple: pointers stay valid, and Go code can hand pointers to C code (via cgocgoGo's mechanism for calling C code. Go's cgo DNS resolver uses it to call the system's getaddrinfo; the pure-Go resolver doesn't need C at all.) safely. The cost is the work saved by generations: a Go service with a big, stable heap re-marks all of it every cycle.

One cycle, four phases

Two details in that picture matter in production:

• Background marking takes about 25% of the CPU (GOMAXPROCSGOMAXPROCSHow many OS threads may run Go code at the same instant. Defaults to the number of CPU cores. × 0.25) while it runs. Your goroutines keep going on the rest.
• Mark assists. If a goroutine allocates faster than the background workers can mark, the runtime makes that goroutine do some marking before its allocation succeeds. This Mark assistMark assistIn Go, a goroutine that allocates quickly while a GC is running is made to do some marking work itself before its allocation succeeds. It keeps the heap in check, but slows that goroutine down. stops a fast allocator from outrunning the collector — but it shows up as random extra latency in whichever request happened to allocate at the wrong moment.

When does a cycle start? The pacer

Go doesn't collect on a timer. It collects based on heap growth. After each cycle, it knows the Live heapLive heapThe part of the heap that is still reachable after a collection — the data your program really needs right now. The rest was garbage. — how much survived. It then sets a Heap goalHeap goalThe heap size at which Go wants the current GC cycle finished. By default: live heap × (1 + GOGC/100), so with GOGC=100 the heap may grow to twice the live data.:

heap goal = live heap × (1 + GOGC / 100)

With the default GOGC=100, that's live × 2: if 10 MB survived, the next cycle should finish by the time the heap reaches about 20 MB. The GC pacerGC pacerThe part of Go's runtime that decides when to start the next collection, aiming to finish marking just as the heap reaches its target size. watches how fast you allocate and how long marking took last time, and starts the next cycle early enough to finish near the goal. (There's also a floor of 4 MB, so tiny programs don't collect constantly, and a 2-minute timer that forces a cycle if nothing else did.)

Watching it: GODEBUG=gctrace=1

Set this environment variable and the runtime prints one line per cycle to stderr. Here's a real run of a small program that keeps about 10 MB of live data and churns out short-lived garbage:

package main

import "fmt"

type node struct {
	next *node
	data [64]byte
}

var keep []*node // stays reachable: ~10 MB of live data
var sink *node   // a package-level variable forces each temporary onto the heap

func main() {
	for i := 0; i < 100_000; i++ {
		keep = append(keep, &node{})
	}
	for i := 0; i < 5_000_000; i++ {
		sink = &node{} // the previous one becomes garbage
	}
	fmt.Println("done", len(keep))
}

$ go build -o t . && GODEBUG=gctrace=1 ./t
gc 1 @0.002s 4%: 0.049+3.8+0.007 ms clock, 0.19+0/1.1/1.3+0.031 ms cpu, 4->4->3 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 2 @0.008s 9%: 0.012+3.1+0.040 ms clock, 0.050+0/2.8/2.6+0.16 ms cpu, 6->7->6 MB, 6 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 3 @0.014s 10%: 0.017+2.3+0.043 ms clock, 0.070+0.58/2.0/2.1+0.17 ms cpu, 11->12->9 MB, 12 MB goal, 0 MB stacks, 0 MB globals, 4 P
…
gc 11 @0.065s 9%: 0.016+2.3+0.055 ms clock, 0.066+0.022/2.0/2.9+0.22 ms cpu, 17->19->10 MB, 20 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 12 @0.072s 9%: 0.021+2.2+0.050 ms clock, 0.086+0.29/1.8/1.9+0.20 ms cpu, 18->20->11 MB, 21 MB goal, 0 MB stacks, 0 MB globals, 4 P
done 100000

Take gc 11 apart:

Now check the pacer formula yourself: gc 11 found 10 MB live, so the next goal is about 10 × 2 = 20 MB — and gc 12 says 21 MB goal (the live number is rounded down for printing). The whole program ran 36 cycles in about 0.2 s (35–39 across runs). Across three runs on this machine, the longest single pause (① + ③) was between 0.25 and 0.95 ms; most were under 0.1 ms.

Tuning Go: GOGC and GOMEMLIMIT

Here's the trade-off as a worked example. Say your service keeps 300 MB of live data and allocates 400 MB/s of short-lived garbage:

• With GOGC=100 the heap goal is 300 × 2 = 600 MB. Each cycle, 300 MB of new garbage piles up before the next one: 300 / 400 ≈ 0.75 s between cycles.
• With GOGC=50 the goal is 300 × 1.5 = 450 MB: only 150 MB of headroom, so a cycle every 0.375 s — twice the GC CPU, 150 MB less memory.
• With GOGC=200 the goal is 900 MB: a cycle every 1.5 s — half the GC CPU, 300 MB more memory.

Each cycle has to mark the whole 300 MB of live data no matter how much garbage there is. So fewer cycles = less CPU, and the only way to get fewer cycles is more headroom. That's the whole idea of GOGCGOGCGo's main GC knob (environment variable or debug.SetGCPercent). It sets how much the heap may grow past the live data before the next GC: 100 (default) = +100%, 50 = +50%, off = never collect on growth..

GOMEMLIMIT: a ceiling, not a ratio

GOGC alone has a blind spot: it only knows ratios. If live data grows from 300 MB to 600 MB, the goal silently becomes 1.2 GB — and in a container with a 1 GB limit, the kernel kills the process (OOM-killedOOM-killed“Out of memory”: the system kills a program that uses more memory than allowed., exit code 137) before Go ever thinks the heap is too big.

GOMEMLIMITGOMEMLIMITA soft memory limit for the Go runtime (Go 1.19+). As total memory approaches it, the GC runs more often to stay under it — even if GOGC would allow more. (Go 1.19+) fixes that. It's a soft limit on total Go runtime memory (heap, goroutine stacks, runtime bookkeeping). As memory approaches it, the GC runs earlier than GOGC would ask, to stay under. Try the presets in order:

What the presets show:

1. defaults — 300 MB live, GOGC=100: the classic sawtooth between 300 and 600 MB.
2. bigger live heap — 600 MB live: the goal is now 1.2 GB and the container dies.
3. …plus GOMEMLIMIT — same, with GOMEMLIMIT=900MiB: the GC starts earlier, the peak stays under 900 MB, and it costs more GC cycles per second instead of a crash.
4. GOGC=off + limit — a popular setup for services with a known memory budget: never collect because of growth, only when memory approaches the limit. Very few cycles, all memory used.
5. live ≈ limit — the danger zone. With only a sliver of headroom, the GC would have to run constantly. Go caps GC CPU at roughly 50% when the memory limit is the reason it's running, and lets the heap go over the limit rather than freeze your program entirely. That's a GC death spiralGC death spiralWhen the live data is almost as big as the memory limit, the GC runs back-to-back, frees almost nothing, and eats most of the CPU — the program crawls instead of doing useful work.: the program stays alive but crawls.

The same thing, for real

The program from §07 (10 MB live, lots of garbage), run with different settings on this machine. The numbers are real but small and noisy; the direction is what matters:

$ for g in 50 100 400 off; do echo -n "GOGC=$g: "; GOGC=$g GODEBUG=gctrace=1 ./t 2>&1 | grep -c '^gc'; done
GOGC=50: 77
GOGC=100: 35
GOGC=400: 9
GOGC=off: 0

$ GOGC=off GOMEMLIMIT=40MiB GODEBUG=gctrace=1 ./t 2>&1 | grep -c '^gc'
19

$ GOMEMLIMIT=15MiB GODEBUG=gctrace=1 ./t 2>&1 | tail -2
gc 309 @0.977s 20%: 0.011+3.8+0.007 ms clock, 0.046+2.0/2.2/0.18+0.031 ms cpu, 9->10->8 MB, 10 MB goal, 0 MB stacks, 0 MB globals, 4 P
done 100000

Doubling GOGC roughly halves the number of cycles. GOGC=off with a 40 MiB limit collected only 19 times, each time near the limit. And the last run is the death spiral in miniature: a 15 MiB limit for ~10 MB of live data forced 309 cycles, took 20% of all CPU time, and stretched a 0.2 s program to about 1 s (another run took 2.7 s — the more the GC fights for CPU, the noisier it gets).

Setting them

# Usual way: environment variables, read at startup.
GOGC=100 GOMEMLIMIT=900MiB ./server   # units: B, KiB, MiB, GiB, TiB
GOGC=off GOMEMLIMIT=900MiB ./server   # collect only near the limit

There's no GOGC equivalent in Node; the nearest knobs are --max-old-space-size (§06), which is a hard ceiling, and --max-semi-space-size, which sets the size of the young generation (bigger = fewer scavenges, more memory).

Memory leaks in garbage-collected languages

You can't forget to call free any more — but you can forget to let go. If a global map, a listener list or a running goroutine still points at an object, the collector has to assume you'll use it, and it keeps it forever. In the restaurant: a coat left on a chair keeps the table reserved, even though its owner went home hours ago.

The usual suspects

Three of these deserve a closer look.

1. Listeners that capture big things

const { EventEmitter } = require("node:events");
const bus = new EventEmitter();

function handleRequest(id) {
  const bigBuffer = Buffer.alloc(1024 * 1024);          // 1 MB per request
  bus.on("config-changed", () => bigBuffer.fill(id));   // closure keeps bigBuffer alive…
  // …and nobody ever calls bus.off(), so the listener (and its 1 MB) lives forever
}

for (let i = 0; i < 200; i++) handleRequest(i);

Real output after 200 calls (with --expose-gc so a full GC ran first):

listeners: 200 external: 201 MB
(node:13297) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 config-changed listeners added to [EventEmitter]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

The function passed to bus.on is a ClosureClosureA function that remembers the variables around where it was created, even after that outer function has returned. Both Go and JS have them.: it remembers bigBuffer, so every buffer stays reachable through bus. Node even warns you at the 11th listener. Don't silence that warning with setMaxListeners() — find the missing bus.off.

2. Goroutines that never finish

func fetchFirst(urls []string) string {
	ch := make(chan string) // unbuffered: a send waits for a receiver
	for _, u := range urls {
		go func() { ch <- get(u) }() // every goroutine but the first blocks here forever
	}
	return <-ch // we only ever receive once
}

Calling this 1000 times with 3 URLs and then printing runtime.NumGoroutine() gives goroutines: 2001 on this machine: 2 leaked goroutines per call, plus main. Each one holds its stack and everything it references, forever. The fix here is make(chan string, len(urls)), so every send can finish; in general, a Goroutine leakGoroutine leakA goroutine still running after the code that started it is done with it — usually stuck waiting on a channel nobody will use again. Each one holds memory, so leaks slowly grow until the process runs out. is fixed by giving each goroutine a way to stop.

3. A small piece that pins a big whole

In Go, data[:16] doesn't copy anything: it's a new slice header pointing into the same backing array (see SliceSlice (Go)Go's growable list type, written []T: []byte is a list of bytes, []Node a list of Nodes. Like a JS array, but every item has the same type.). Strings work the same way: strings.Cut, slicing s[a:b] and similar return views into the original string's memory. Keep the small piece and you keep the big one.

header := data[:16]              // ✗ keeps all of data alive
header := bytes.Clone(data[:16]) // ✓ copies 16 bytes; data can be collected (Go 1.20+)
title := strings.Clone(line)     // ✓ the same for strings (Go 1.20+)

V8 does something similar for strings: slicing a long string may produce a "sliced string" that refers to the original. It's an engine detail you can't control directly, but it explains heap snapshots full of (sliced string) entries.

Finding leaks in Go: compare two heap profiles

The tool is pprofpprofGo's built-in profiler and its viewer (go tool pprof). A heap profile shows which lines of code allocated the memory that is still in use.. A heap profile records, for every allocation site (a line of code), how much of its memory is still in use after the last GC. Take one profile, let the program run, take another, and diff them: what grew is your suspect. A real run:

var sessions = map[int][]byte{} // leak 1: a global map nobody cleans up
var titles []string             // leak 2: tiny strings that pin big ones

func handle(id int) {
	sessions[id] = make([]byte, 4096)                    // line 14
	doc := strings.Repeat("x", 4096) + "\ntitle"         // line 15
	_, title, _ := strings.Cut(doc, "\n") // title = the part AFTER "\n": 5 bytes,
	titles = append(titles, title)         // but it points INTO doc's 4 KB
}

func writeHeapProfile(name string) {
	runtime.GC() // the heap profile describes the state after the last GC
	f, err := os.Create(name)
	if err != nil {
		panic(err)
	}
	defer f.Close()
	pprof.WriteHeapProfile(f)
}

// main: 1 000 requests → writeHeapProfile("before.pprof")
//       10 000 more    → writeHeapProfile("after.pprof")

$ go tool pprof -top -lines -diff_base=before.pprof leak after.pprof
File: leak
…
Type: inuse_space
Showing nodes accounting for 79.38MB, 878.30% of 9.04MB total
      flat  flat%   sum%        cum   cum%
   43.20MB 478.00% 478.00%    43.20MB 478.00%  main.handle main.go:15
   36.18MB 400.29% 878.30%    36.18MB 400.29%  main.handle main.go:14
…

Read flat as "memory still in use that was allocated on this line, added since before.pprof". (The percentages are relative to the first profile, which is why they're above 100%.) Line 14 is the session map: 10 000 × 4 KB. Line 15 is the documents — each 4 KB document is kept alive only by the 5-byte title pointing into it (strings.Cut returns the part before the separator, the part after it, and whether it was found; we keep only the part after). Both leaks found in one command. The exact numbers vary a little from run to run.

In a real server you don't write files by hand: import net/http/pprof and fetch /debug/pprof/heap twice, a few minutes apart. Use /debug/pprof/goroutine to see where leaked goroutines are stuck.

Finding leaks in Node: compare two heap snapshots

A Heap snapshotHeap snapshotA dump of every object on the JavaScript heap, with who references whom. Chrome DevTools (and Node) can take two and show what was added in between. lists every object on the V8 heap and who points at it.

1. Start Node with node --inspect server.js, open chrome://inspect in Chrome and click inspect.
2. In the Memory tab, take a heap snapshot. (Taking one runs a full GC first, so only reachable objects appear.)
3. Put the suspect code path under load (send a few hundred requests), then take a second snapshot.
4. Select the second snapshot and switch the view from Summary to Comparison. Sort by Size Delta: the object types that grew are your suspects.
5. Click one object and read its Retainers pane: its Retainer pathRetainer pathIn a heap snapshot, the chain of references from a root to an object — it answers "why is this object still alive?", the chain of references from a root to that object. That chain ends at the thing that should have let go — a Map, a listener array, a timer.

On a server without a browser, node --heapsnapshot-signal=SIGUSR2 server.js writes a snapshot whenever you send that signal (kill -USR2 <pid>), and require("node:v8").writeHeapSnapshot() writes one from code. Load the files into the Memory tab later.

Giving the GC less work

From §07–§08, GC cost comes from two numbers:

• How often a cycle runs — driven by your allocation rate (MB/s). Halve it and cycles happen half as often.
• How much work each cycle does — driven by the live heap, and especially how many pointers it contains, since marking means following pointers.

So there are two levers: allocate less, and keep less (pointer-heavy) data alive. Before pulling either, measure — most code allocates plenty and that's fine. Optimise the hot paths a ProfilerProfilerA tool that measures where a program spends its time or memory (e.g. Go's pprof, Chrome DevTools, perf), usually by sampling what's running many times per second. points at.

Step 1: keep things off the heap

The best allocation is the one that never reaches the heap. In Go, a value that doesn't outlive its function can live on the stack, which costs the GC nothing; the compiler decides this with Escape analysisEscape analysisA compiler check (Go has one) that decides whether a value can live on the stack or must “escape” to the heap — for example because a pointer to it outlives the function.. Returning pointers, storing values in interfaces and capturing them in closures tend to push them to the heap. Stack vs Heap covers this in depth, including go build -gcflags=-m, which prints the compiler's decision for each value.

Step 2: pre-size slices and maps

append on a full slice allocates a bigger backing array and copies everything over — repeatedly, as the slice grows. If you know the final size, say so up front:

func growing(n int) []int {
	var out []int // starts with capacity 0
	for i := 0; i < n; i++ {
		out = append(out, i) // re-allocates and copies whenever it runs out of room
	}
	return out
}

func presized(n int) []int {
	out := make([]int, 0, n) // ← one allocation, exactly big enough
	for i := 0; i < n; i++ {
		out = append(out, i)
	}
	return out
}

func BenchmarkGrowing(b *testing.B) {
	for b.Loop() {
		_ = growing(10_000)
	}
}
// BenchmarkPresized is the same, calling presized.

$ go test -bench . -benchmem
BenchmarkGrowing-4        	    7093	    203762 ns/op	  357625 B/op	      19 allocs/op
BenchmarkPresized-4       	   42262	     35654 ns/op	   81920 B/op	       1 allocs/op

Read the columns as: how many times it ran, time per run, bytes allocated per run, allocations per run. Pre-sizing cut 19 allocations to 1 and allocated about 4× fewer bytes, and on this machine it ran about 5–6× faster. The same goes for maps: make(map[string]int, n).

Step 3: reuse with sync.Pool

When a hot path needs a big temporary buffer per request, keep used buffers around and reuse them. sync.Poolsync.PoolA Go standard-library type that keeps used objects around so you can reuse them instead of allocating new ones. The GC may empty it at any time, so it's only a cache. does exactly that, and is safe to use from many goroutines:

var bufPool = sync.Pool{
	New: func() any { return new(bytes.Buffer) }, // called when the pool is empty
}

func render(w io.Writer, items []string) (int, error) {
	buf := bufPool.Get().(*bytes.Buffer) // borrow (or create) a buffer
	buf.Reset()                          // ← always clear what the last user left
	defer bufPool.Put(buf)               // give it back when done
	for _, it := range items {
		buf.WriteString("<li>")
		buf.WriteString(it)
		buf.WriteString("</li>")
	}
	return w.Write(buf.Bytes())
}

In a micro-benchmark on this machine, building a 1.3 KB response in a fresh buffer each time cost 7 allocations and 4080 B per run (2714 ns); with the pool, 0 allocations (412 ns). Two warnings. The pool is only a cache: the GC may empty it at any cycle, so never rely on what's in it. And pooling objects that are cheap to create only adds complexity — pool big buffers on hot paths, not every struct (see Object pools and sync.Pool for the general pattern).

Step 4: fewer pointers, less marking

Marking means following pointers. Go knows which memory can't contain pointers (a []byte, a []int, a struct of only numbers) and doesn't scan it at all — it's noscanPointer-free (noscan) memoryHeap memory Go knows can't contain pointers (a []byte, a []int, a struct of numbers). The GC never scans inside it, so it costs almost nothing to mark. memory. So the same data can cost very different amounts of GC work:

type PointerHeavy struct {
	Name *string     // each pointer is one more thing to follow
	Tags []*Tag
}

type PointerFree struct {
	NameID uint32    // an index into a shared table instead of a pointer
	Tags   [4]uint16 // a fixed-size array of small numbers: nothing to scan
}

A cache of 10 million PointerFree values stored in a []PointerFree is nearly invisible to the GC's mark phase (a map[string]PointerFree brings the pointers back: every string key is one); 10 million PointerHeavy values means tens of millions of pointers to follow on every cycle. This is why large in-memory caches in Go often store data as []byte or in big arrays indexed by integers.

And in JavaScript?

In V8, short-lived objects are cheap — that's what the Scavenger is built for (§05). On this machine, a loop allocating a million small temporary objects was no slower than one reusing a single object, because V8's optimizing compiler removed most of those allocations entirely. What costs real time is objects that survive: they get copied, promoted, and then marked on every major GC. So in JS:

• Don't worry about small temporaries inside a function.
• Do watch anything that keeps objects alive across requests: module-level arrays and maps, queues, memoized results.
• For hot numeric code, reuse a preallocated typed array (new Float64Array(n)) instead of building new arrays each call; typed arrays store raw numbers, so there's nothing inside them to scan.

Production: latency, containers, weak refs and other designs

Latency vs throughput

Every collector picks a point between two goals:

• ThroughputThroughputHow many jobs get finished per second. For a worker pool, the maximum is roughly workers ÷ time per job.: the smallest total share of CPU spent on GC. Easiest with big, rare, stop-the-world collections. Great for batch jobs.
• LatencyLatencyHow long one request or job takes from the moment it arrives until it's finished — including any time spent waiting in a queue.: the shortest pauses. Needs concurrent and incremental work, write barriers, spare cores — so it usually costs more total CPU.

Go and V8 both lean towards latency. Java lets you choose: the Parallel collector for throughput, G1 (the default) for a balance, ZGC for very short pauses.

How GC shows up in p99

Pauses don't move your average much; they move your tail. A worked example: a Node service handles 1 000 requests/s, and a major GC pauses the main thread for 50 ms once every 10 s.

• Every request that arrives or is in flight during those 50 ms waits — up to 50 ms, about 25 ms on average: roughly 1 000 × 0.05 = 50 requests per pause.
• That's 50 out of 10 000 requests per 10 s = 0.5% of requests.
• Average latency barely moves. Your p99p99 (99th percentile)The value that 99% of measurements are below — i.e. how bad the slowest 1% is. Averages hide slow outliers; p99 shows them. barely moves either: only 0.5% of requests are hit, so they all fit inside the slowest 1%, and the p99 cut-off still lands on an ordinary request. p99.9 is what jumps, by up to 50 ms.
• Make the pause happen every 3 s instead, and about 1.7% of requests are hit — now p99 moves too.

That's why GC appears in Tail latencyTail latencyThe latency of the slowest few requests — usually reported as p99 or p99.9. It's what your unluckiest users feel, and it grows much faster than the average under load. investigations, not average ones. In Go, the stop-the-world pauses are usually too small to matter; what shows up instead is mark assists (§07) — a request that allocates heavily while a cycle is running is made to help mark, and takes longer. Lowering the allocation rate (§10) helps both.

Containers: tell the runtime about the limit

A container's memory limit is enforced by the kernel through cgroupscgroupsControl groups: a Linux kernel feature that limits how much CPU, memory and how many processes a group of processes may use. It controls how much a container can use.: go over it and the process is killed instantly (OOMKilled, exit 137), with no chance to collect garbage first. (Threads & Processes §11 explains containers and OOM kills.) The runtime's job is to never get there, but it can only do that if it knows the budget.

# Kubernetes: give the runtime ~90% (Go) or ~75% (Node) of the container limit
resources:
  limits:
    memory: 1Gi
env:
  - name: GOMEMLIMIT
    value: "900MiB"
  # for a Node container instead:
  # - name: NODE_OPTIONS
  #   value: "--max-old-space-size=768"

Weak references and finalizers: useful, but not for cleanup

Sometimes you want to point at an object without keeping it alive — for a cache that may be emptied by the GC, or to attach data to objects you don't own. That's a Weak referenceWeak referenceA reference that lets you reach an object without keeping it alive. If only weak references remain, the GC may collect the object and the weak reference then gives you nothing.. And sometimes you want to know when an object was collected; that's a Finalizer / cleanupFinalizer / cleanupA callback the runtime runs some time after an object becomes garbage. There's no guarantee when — or, in JavaScript, whether — it runs.. Both languages have them:

import (
	"fmt"
	"runtime"
	"time"
	"weak" // standard library since Go 1.24, not a third-party package
)

type Blob struct{ data [1 << 20]byte }

func main() {
	b := &Blob{}
	w := weak.Make(b) // a weak pointer: does NOT keep b alive

	runtime.AddCleanup(b, func(name string) {
		fmt.Println("cleanup ran for", name) // must not use b itself
	}, "blob-1")

	fmt.Println("before:", w.Value() != nil) // true: b is still in use below
	runtime.KeepAlive(b)                      // b is reachable up to here

	runtime.GC()                      // b is now unreachable
	time.Sleep(10 * time.Millisecond) // cleanups run on a separate goroutine
	fmt.Println("after: ", w.Value() == nil)
}
// Output on this machine (Go 1.24):
// before: true
// cleanup ran for blob-1
// after:  true

Now the warnings. The callback runs some time after the object is collected — or never:

• Timing is unknown. A collection may not happen for minutes on a quiet process. Closing a file or a database connection in a cleanup means it stays open for an unknown time; under load you run out of them first.
• It may never run. The JavaScript spec explicitly allows engines to skip FinalizationRegistry callbacks, and they don't run if the process exits first. While testing this very example, a slightly different version (with a WeakRef to a created in the same tick) printed nothing at all.
• Easy to break. In Go, if the cleanup function refers to the object itself (func() { b.Close() }), the object stays reachable through the cleanup and is never collected. That's why AddCleanup passes a separate arg.

Use explicit cleanup — defer f.Close() in Go, try { … } finally { conn.release() } in JS — and treat finalizers only as a safety net that logs "someone forgot to close this". For "data attached to an object", JavaScript's WeakMap is the everyday tool: its keys are held weakly, so entries vanish with their key object, no callbacks involved.

Other designs, briefly

CPython (the standard Python) uses reference counting plus a tracing cycle collector for exactly the leak you saw in §02's reference-counting mode. Every design is a different answer to the same question: who proves that nobody can use this memory any more — the programmer, the compiler, or the runtime?

Pitfalls gallery

const cache = new Map();
function getUser(id) {
  if (!cache.has(id)) cache.set(id, loadUser(id));
  return cache.get(id);          // grows with every new id, forever
}

const cache = new Map();
const MAX = 10_000;
function getUser(id) {
  if (!cache.has(id)) {
    if (cache.size >= MAX) cache.delete(cache.keys().next().value); // drop the oldest
    cache.set(id, loadUser(id));
  }
  return cache.get(id);
}

func firstLine(body []byte) []byte {
	i := bytes.IndexByte(body, '\n')
	if i < 0 {
		return body
	}
	return body[:i] // ✗ keeps all of body alive — use bytes.Clone(body[:i])
}

function watch(user) {
  setInterval(() => refresh(user), 1000); // runs forever and keeps `user` alive
}

function watch(user) {
  const id = setInterval(() => refresh(user), 1000);
  return () => clearInterval(id);         // caller stops it when done
}

Check yourself

Predict the answer before you click. Q1 is covered in §02, Q2 in §07–§08, Q3–Q4 in §09, Q5 in §06 and §11, Q6 in §05.

let a = { name: "a" };
let b = { name: "b" };
a.other = b;
b.other = a;
a = null;
b = null;
// …a GC runs

var cache = map[string][]byte{}

func handle(id string) {
    cache[id] = make([]byte, 1<<20) // 1 MB
}

func readHeader(path string) []byte {
    data, _ := os.ReadFile(path) // each file is 100 MB
    return data[:16]
}

var headers [][]byte // stores 10 results

Cheat sheet