Threads vs Processes

The 30-second version

Every program you run — your editor, a Node server, a Go binary — runs inside a process. Inside each process, one or more threads do the actual work. "Should this be another process or another thread?" is one of the oldest trade-offs in software, and you meet it every time you scale a server.

Here's the whole trade-off on one screen. Each row gets its own section below.

A process: one program, its own memory

A program is a file on disk, like /usr/bin/node or your compiled Go binary. A process is that program running. Run node server.js in two terminals and you get two processes from the same program — two houses built from one blueprint.

What the OS gives every process

When a process starts, the Operating system (OS) / kernelOperating system (OS) / kernelThe core program (Linux, macOS, Windows) that manages hardware, memory, threads, files and network connections for every other program. The kernel is its innermost part. sets up a little kit for it and keeps a record of it in its process table:

• An ID. A number called the PIDPID (process ID)The number the OS gives each running process, e.g. 4120. You use it to look a process up (ps, top) or to send it a signal (kill 4120)., e.g. 4120, plus the PID of its parent — the process that started it (often your shell).
• Its own memory. Room for the program's code, its global variables, its HeapHeapMemory for data that must outlive a single function call. Unlike the call stack, nothing is thrown away automatically when a function returns., and a 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. for each thread. Private to this process — more on that below.
• Open files and connections. Every file and network SocketSocketThe OS's handle for one open network connection. Your program reads and writes bytes through it. it opens gets a small number, a File descriptorFile descriptor (fd)A small number the OS gives your program to identify an open file or socket — e.g. “fd 7”..
• Its surroundings. Environment variables, the current directory, and which user it runs as (which decides what it's allowed to do).
• At least one thread — the main thread — to run the code. It can start more (§03).

You can ask a program for its own PID:

package main

import (
	"fmt"
	"os"
)

func main() {
	fmt.Println("my PID:", os.Getpid())      // e.g. 4120
	fmt.Println("parent PID:", os.Getppid()) // the shell that started me
}

And from the outside, ps lists processes. On Linux you can also ask how many threads each one has:

$ ps -o pid,ppid,nlwp,rss,comm -p 4120,4188
  PID  PPID NLWP   RSS COMMAND
 4120  3301   11 48212 node
 4188  3301    8 12480 api-server

PID/PPID = the process and its parent. NLWP = number of threads (Linux calls them "lightweight processes"). RSS = RAM in use, in KB. COMMAND = the program. Yes — the "single-threaded" Node process has about 10 threads; §07 explains who they are.

Each process lives in its own address space

Memory is one long row of numbered bytes; a byte's number is its address. Programmers usually write addresses in hexadecimal (base 16), like 0x5000 — the 0x just means "this number is in hex".

Here's the trick: every process gets its own private numbering. Two processes can both store something at address 0x5000 and never collide. Each process sees its own Address spaceAddress spaceThe range of memory addresses a process can use — its private map of memory. Every process gets its own; all threads of a process share one., as if it were the only program on the machine.

This is Virtual memoryVirtual memoryThe trick that gives each process its own private address space. The addresses a program uses are “fake” (virtual); the CPU translates each one to a real spot in RAM, using a table the OS keeps per process.. The addresses your program uses are virtual: on every memory access, the CPU translates them into real RAM locations using a lookup table the OS keeps per process, the Page tablePage table (and pages)Memory is handled in chunks called pages (usually 4 KB). A page table is the per-process lookup table that says “virtual page X lives at physical RAM spot Y”. The CPU consults it on every memory access..

That's where the walls come from. Process A can only use addresses in its own page table, and none of them lead to B's memory. A can't read B's data, can't overwrite it — it can't even name it.

What if a program uses an address that isn't in its page table at all — say, a null pointer (address 0)? The CPU refuses, and the OS kills the process. That's the famous Segmentation faultSegmentation fault (segfault)What happens when a program touches a memory address it isn't allowed to use. The CPU stops it and the OS kills the whole process (“Segmentation fault (core dumped)”, exit code 139).. (That's what happens in C. JavaScript checks for null first and throws a TypeError, and Go turns a nil pointer into a panic, so you rarely see a real segfault in either.)

Threads: roommates sharing one house

Every process starts with one ThreadThreadOne worker that runs your code line by line. A program can have several threads, and the operating system decides which one runs on which CPU core., the main thread. The program can ask the OS for more. Each new thread runs its own function, side by side with the others, inside the same house.

Shared vs private

Why is the stack private? Because each thread is in the middle of different function calls. Thread A might be three calls deep in handleRequest, thread B in writeLog; each needs its own pile of plates. Everything else lives in the one address space they share.

"One per thread" doesn't mean protected: each thread has its own stack, but it sits in the same address space, so another thread with a pointer to it can still read or overwrite it. Step ③ below shows that.

Try it. The same two workers, A and B, first as threads in one process, then as two processes:

Why share? Speed

• Sharing is free. To give another thread a 100 MB array, you hand it the array's address. Nothing is copied. Between processes, those 100 MB must be copied through the OS (§09).
• Creating is cheap. A new thread doesn't need a new address space, so it starts in microseconds. A new process takes much longer (§06).
• Switching is a bit cheaper. Moving the CPU from one thread to another in the same process skips a step (§05).

The price of sharing

Two roommates can reach for the same egg. When two threads write the same variable at the same time, with nothing coordinating them, you get a Data raceData raceTwo threads or goroutines access the same memory, at least one of them writes, and nothing orders the two accesses (no lock, channel or atomic between them). The result is unpredictable. — and wrong results that change from run to run.

A worked example. counter is 5, and threads A and B each run counter++. The CPU does that in three steps: read, add 1, write back. If both threads read 5 before either writes, both compute 6 and both write 6. Two increments ran; the counter went up by one. One update is simply lost:

1// Both threads run counter++.
2// The CPU does it in three steps:
3let tmp = counter; // ① read into a register
4tmp = tmp + 1;     // ② add
5counter = tmp;     // ③ write back

The fix is a LockLock (mutex)A “do not disturb” sign for a piece of data: only the task holding the lock may touch it; others wait their turn. (or passing data through a channel), so only one thread runs those three steps at a time. Race Conditions §02 digs into this bug; Async / Await, pitfall #5 and Channels §10 show both fixes.

When one thread crashes, the whole house burns

Suppose one thread has a bug and writes to a bad address. The CPU stops it and the OS steps in. The OS can't know what else that broken thread scribbled over in the shared memory, so nothing in the process can be trusted any more. It does the only safe thing: it kills the whole process, every thread with it.

The same is true of unhandled errors in most runtimes. An uncaught exception on Node's main thread, or a Go panic / recoverpanic / recoverpanic is Go's crash-the-program error (like an uncaught throw). recover, called inside a deferred function, catches it — but only in the same goroutine. that nobody recovers in any goroutine, ends the whole process.

Separate processes don't have this problem: a crash stays inside its own walls. The demo below has a second mode with a supervisor: just a parent process whose job is to start workers and restart any that die. (You'll meet real ones in §07, Node's cluster, and §11, Kubernetes.) Send a bad request to each setup:

The OS scheduler: who gets a core

Open your laptop's activity monitor: hundreds of processes and a few thousand threads, on maybe 8 cores. Each CPU coreCPU coreOne independent “brain” inside the CPU. Each core runs exactly one thread at any instant, so a 4-core machine runs at most 4 threads truly at the same time. can only run one thread at any instant. How does that work?

They take turns. The part of the OS kernel that decides whose turn it is is the OS schedulerOS schedulerThe part of the kernel that decides which ready thread runs on which CPU core, and for how long. It runs thousands of times per second..

Turns, and taking turns away

Each running thread gets a Time sliceTime sliceHow long the scheduler lets a thread run before it may be paused so another thread gets a turn. Typically a few milliseconds. — a few milliseconds. If it's still running when the slice is up, a Timer interruptTimer interruptA hardware alarm that fires regularly (e.g. every 1–4 ms) and forces the CPU to jump into the kernel — even if the running thread doesn't want to stop. It's how the scheduler takes the CPU back. (a hardware alarm) forces the CPU back into the kernel (the CPU stops running your code and runs the OS's code instead), and the scheduler can hand the core to someone else. Pausing a thread that didn't ask to stop is called preemption.

Threads also give up the core voluntarily: whenever they have to wait — for the disk, the network, a lock, a timer — they're set aside until the wait is over. Step through both:

Three states

That last column explains a lot. A blocked thread uses no CPU time, but it still holds memory: its stack, its kernel record. That's exactly why one thread per connection got expensive at 10,000 connections (Async / Await §03) — the threads weren't busy, they were just there.

Context switches: what a swap really costs

In §04 the scheduler "swapped" threads on a core. What does that actually involve? A thread's whole in-progress state lives in the core's registersRegisters / program counterA handful of tiny, ultra-fast storage slots inside each CPU core. They hold what the running thread is working on right now; one of them, the program counter, holds the address of the next instruction to run.: where it is in the code (the program counter), where its stack is (the stack pointer), and the values it's working on. Swap the registers and you've swapped the thread.

There are two kinds of switch, and you saw both in §04:

• Voluntary — the thread blocked (waiting on disk, network, a lock).
• Involuntary — its time slice ran out and it was preempted.

Step by step

Two words you'll meet in the stepper. Kernel mode: the CPU has a privileged mode for the OS and a restricted one for your code; crossing between them costs a little (User mode vs kernel modeUser mode vs kernel modeThe CPU has two privilege levels. Your code runs in user mode and can't touch hardware or other processes. The OS kernel runs in kernel mode and can do anything. Crossing between them (a syscall, an interrupt) costs a little time.). TLB: a small cache inside the CPU that remembers recent address translations from the page table (§02), so translating is usually instant (TLBTLBTranslation lookaside buffer: a small cache inside the CPU that remembers recent page-table lookups, so translating an address is usually instant.).

Step through a switch from thread A to thread B. Then flip the toggle: is B in the same process as A, or a different one?

So the difference between the two cases is exactly one step: a switch to another process also switches the address space (the page table), and the new process finds none of its data in the CPU's caches.

What it costs, in numbers

All numbers are approximate — they vary a lot with the CPU, the kernel version and how much data each thread touches.

The "then…" column is often the bigger cost. After a switch, the new thread's data isn't in the CPU cacheCPU cacheSmall, very fast memory on the CPU chip (L1, L2, L3) that keeps copies of recently used data. Reading from cache takes ~1–10 ns; reading from RAM takes ~100 ns., so its first reads go to RAM — around 100 ns each instead of 1–10 ns.

A worked example. One core does 10,000 switches per second, and each costs about 5 µs including the cache refill. That's 10,000 × 5 µs = 50,000 µs = 50 ms of every second — 5% of the core — doing no useful work. At 100,000 switches per second, it's 50%. Try it:

Why goroutines and event loops win here

This is the deeper reason behind Async / Await §03. With a thread per connection, every network wait means a trip into the kernel and a context switch. Go's runtime switches goroutines without entering the kernel at all — it just saves a few registers in user space, roughly ten times cheaper. And Node's event loop doesn't switch at all between callbacks: it's one thread that keeps running.

Measuring it (Linux)

# machine-wide context switches per second: the "cs" column
vmstat 1

# one process: voluntary = it blocked, nonvoluntary = it was preempted
grep ctxt_switches /proc/4120/status

# per thread, once a second (pidstat comes with the sysstat package)
pidstat -wt -p 4120 1

Starting processes: fork, exec and spawn

Why two steps instead of one "start this program" call? Because in between, the child is still running your code, so it can set itself up with ordinary function calls: connect its output to a pipe (a one-way byte channel, §09), change directory, drop privileges (switch to a less powerful user). Then it calls exec and becomes the new program, keeping that setup.

Step through what happens when a server runs ls -l. The code is pseudocode — neither Node nor Go lets you call these directly; they do it for you:

1const pid = fork();        // 1 in, 2 out
2if (pid === 0) {
3  // CHILD
4  exec("/bin/ls", ["ls", "-l"]);
5  // (never reached)
6} else {
7  // PARENT
8  const status = waitpid(pid);
9  console.log("exit:", status);
10}

Three ideas from that walkthrough:

• Copy-on-writeCopy-on-write (COW)A lazy copy: after fork(), parent and child share the same memory pages, marked read-only. A page is only really copied when one of them writes to it. This makes fork() fast.: fork doesn't copy memory up front. Parent and child share every page until one of them writes to it; that write causes a Page faultPage faultThe CPU stops a memory access because the page table doesn't allow it (yet) and hands control to the kernel. Often harmless: the kernel fixes things up — e.g. makes a private copy of a copy-on-write page — and the program carries on without noticing., and the kernel copies just that page. The kernel only copies the page table, not the gigabytes behind it, so forking even a big process is fast (milliseconds, not seconds).
• Exit codeExit codeA small number a process returns when it ends: 0 means success, anything else means failure. 128 + N means it was killed by signal N (137 = SIGKILL, 139 = segfault).: every process ends with a number. 0 = success; anything else = failure.
• Zombie processZombie processA child process that has exited, but whose parent hasn't collected its exit code yet (with wait). It uses no CPU or memory, just a slot in the process table — but enough of them exhaust the PID limit.: a finished child stays in the process table until its parent collects the exit code. Forget to collect it and the zombies pile up.

In real code

package main

import (
	"context"
	"fmt"
	"os/exec"
	"time"
)

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancel()

	// No shell involved: "ls" is the program, "-l" and "/tmp" its arguments.
	cmd := exec.CommandContext(ctx, "ls", "-l", "/tmp")
	out, err := cmd.Output() // ← fork + exec + wait, collecting stdout
	if err != nil {
		fmt.Println("failed:", err) // non-zero exit code, timeout, or not found
		return
	}
	fmt.Print(string(out))
}

The child's standard streams — stdin / stdout / stderrstdin / stdout / stderrThe three standard streams every process starts with: input (fd 0), normal output (fd 1) and error output (fd 2). A parent can connect them to pipes to talk to its child. — are how parent and child talk by default: Node and Go connect them to pipes, which is how the parent reads ls's output. More on pipes in §09.

Node: one main thread, and three ways out

"Node is single-threaded" is half true. Your JavaScript runs on one thread — the one running the Event loopEvent loopThe loop inside every JS runtime that repeatedly picks the next piece of waiting work (a callback) and runs it to completion on the single main thread.. But a Node process has other threads too, and you can add more threads or more processes when you need them:

Threads you already have: the libuv pool

Some work the OS can't do in the background with a "wake me when it's done" call (the epoll / kqueue / IOCPepoll / kqueue / IOCPOS features that let one thread say “here are 10,000 connections — wake me when any of them has data”. epoll is Linux, kqueue is macOS/BSD, IOCP is Windows. trick from Async / Await §03): reading files, looking up hostnames with dns.lookup, slow crypto like pbkdf2 (password hashing), compression with zlib. For those, Node hands the job to the libuv thread poollibuv thread poolA small pool of background threads (4 by default) inside every Node process. Node uses it for work the OS can't do asynchronously: file system calls, DNS lookups, some crypto and zlib compression. and calls your callback when a pool thread finishes.

The pool has 4 threads by default. Run 4 slow password hashes at once and every fs.readFile queues behind them. You can raise it with the UV_THREADPOOL_SIZE environment variable (set it before Node starts; max 1024). Network sockets don't use the pool, so ordinary HTTP traffic isn't affected.

worker_threads: more JavaScript threads

A blocking calculation on the main thread freezes everything else (see Async / Await, pitfall #2). A Worker threadWorker threadAn extra JavaScript thread you create on purpose (Web Workers in browsers, worker_threads in Node) to run CPU-heavy code without freezing the main thread. runs that code on another thread, so it can use another core:

import { Worker } from "node:worker_threads";
import { readFile } from "node:fs/promises";

// Run hash-worker.js on a new thread; resolve with whatever it sends back.
function hashInWorker(buf) {
  return new Promise((resolve, reject) => {
    const w = new Worker(new URL("./hash-worker.js", import.meta.url), {
      workerData: buf, // ← copied into the worker
    });
    w.once("message", resolve); // the worker's result
    w.once("error", reject);    // an uncaught throw inside the worker
    w.once("exit", (code) => reject(new Error(`worker exited (${code})`))); // never hang
  });
}

// files = the CONTENTS of each file (Buffers), not just their names
const files = await Promise.all(["a.txt", "b.txt", "c.txt", "d.txt"].map((f) => readFile(f)));

// 4 files → 4 threads → up to 4 cores busy at once.
// Fine for a handful; for 1,000 files use a pool (§12, pitfall #1).
const sums = await Promise.all(files.map(hashInWorker));

The key fact about workers: each one runs its own V8 isolateV8 isolateOne complete, independent JavaScript world inside the V8 engine: its own heap, its own globals, its own garbage collector. Each Node worker thread runs its own isolate, so JS objects aren't shared between them. — a separate JavaScript world with its own heap and globals. It's an OS thread inside the same process, but JavaScript objects are not shared. Data moves in three ways:

1. Copied (the default). postMessage copies the value with Structured cloneStructured cloneThe algorithm postMessage uses to copy a value to another thread or window: it deep-copies objects, arrays, Maps, Dates and more — but not functions or class instances' methods.. Fine for small messages; slow for 100 MB.
2. Transferred. postMessage(buf, [buf]) moves an ArrayBufferArrayBufferA fixed-size block of raw bytes in JavaScript. You read and write it through views like Uint8Array; Node's Buffer is one such view. It can be moved (transferred) to a worker without copying. (a block of raw bytes; a Node Buffer sits on top of one) to the other thread with no copy. The sender can't use it any more.
3. Shared. A SharedArrayBuffer + AtomicsSharedArrayBuffer + AtomicsA block of raw bytes that several JS threads can see at the same time (real shared memory). Atomics gives safe operations on it, like an increment that can't be interrupted halfway. is real shared memory: both threads see the same bytes at once — with all the data-race risks from §03.

child_process: other programs

§06 showed execFile and spawn. Use them to run anything that isn't your JavaScript — git, ffmpeg, a Python script — or JavaScript you don't trust. It's a separate process: its own memory, its own crashes. Node's own child_process.fork() starts another Node process with a message channel attached (§09).

cluster: one server, every core

A single Node server uses one core for JavaScript. The clustercluster (Node)A built-in Node module that starts several copies of your server as separate processes, all accepting connections on the same port. starts several copies of the server as separate processes, all accepting connections on the same port:

import cluster from "node:cluster";
import http from "node:http";
import { availableParallelism } from "node:os";

if (cluster.isPrimary) {
  // The primary process only manages workers.
  for (let i = 0; i < availableParallelism(); i++) cluster.fork(); // one per core
  cluster.on("exit", (worker, code) => {
    console.log(`worker ${worker.process.pid} died (code ${code}), starting another`);
    cluster.fork(); // ← the primary is a supervisor
  });
} else {
  // Each worker is a full copy of the server, in its own process.
  http.createServer((req, res) => res.end(`hi from ${process.pid}\n`)).listen(3000);
}

The primary is a SupervisorSupervisorA program whose job is to start other processes and restart them if they die — e.g. systemd, Kubernetes, PM2, or a primary process watching its workers.: when a worker crashes, it starts a new one — exactly the "4 processes + supervisor" mode of the §03 crash demo. But each worker has its own memory: an in-memory cache or session store exists once per worker, not once per server (§12, pitfall #5).

Which one?

Go: goroutines on threads, all in one process

A GoroutineGoroutineA very lightweight task in Go, started with the go keyword. The Go runtime runs thousands of them on just a few OS threads. is not an OS thread. The Go runtime keeps its own scheduler that puts goroutines onto threads, and the OS scheduler (§04) puts those threads onto cores. Running many tasks on a few threads like this is called M:N schedulingM:N schedulingRunning many (M) lightweight tasks on a few (N) OS threads, with the language runtime deciding which task runs on which thread. Go's goroutines work this way..

How the Go scheduler decides which goroutine runs on which thread — the G · M · P model, the netpoller, work stealing — is covered step by step in Async / Await §09. Here we care about what it means for threads and processes.

Goroutines vs threads, in numbers

All approximate:

The number of threads running Go code at once is GOMAXPROCSGOMAXPROCSHow many OS threads may run Go code at the same instant. Defaults to the number of CPU cores., one per core by default. The runtime starts a few extra threads when goroutines get stuck in blocking system calls, so a busy Go server typically shows a dozen or so threads.

What "one process" means for you

• Every goroutine shares one heap. Goroutines are roommates: two of them writing the same map is a Data raceData raceTwo threads or goroutines access the same memory, at least one of them writes, and nothing orders the two accesses (no lock, channel or atomic between them). The result is unpredictable. (§03). Go often catches this one itself and kills the process (see the third bullet). Use a mutex or channels (Channels §10), and run tests with go test -race.
• One unrecovered panic ends everything. A panic / recoverpanic / recoverpanic is Go's crash-the-program error (like an uncaught throw). recover, called inside a deferred function, catches it — but only in the same goroutine. in any goroutine, if not recovered inside that same goroutine, exits the whole program. Go's HTTP server recovers panics in your handlers — but not in goroutines your handlers start (§12, pitfall #4).
• Some crashes can't be recovered at all. "Fatal errors" — concurrent map writes, running out of memory, a segfault in C code called from Go — kill the process no matter how many recover() calls you have.

Threads, when you need to see them

// Pin this goroutine to its current OS thread (and no other goroutine
// runs on that thread). Needed for C libraries or GUI toolkits that
// insist on being called from the same thread every time.
runtime.LockOSThread()
defer runtime.UnlockOSThread()

// Go crashes the program if it ever needs more than this many OS threads
// (default 10,000) — usually a sign of thousands of goroutines stuck in
// blocking system calls or C calls.
debug.SetMaxThreads(10_000) // from "runtime/debug"

Processes in Go

Go has no plain fork (§06 explains why). To start another process, use os/exec, as in §06. Real Go systems do use processes for isolation: HashiCorp's go-plugin library — used by Terraform (a tool that creates cloud servers from config files) for its providers, the plugins that talk to each cloud — runs each plugin as a separate process and talks to it over gRPCgRPCA popular framework for one service to call functions on another service over the network. It passes deadlines along automatically. on a local socket. A buggy provider can crash itself, not Terraform.

Talking: shared memory vs IPC

Threads: share an address

Between threads (and goroutines), you just use the same variable, or pass a pointer — an address in the shared heap. Handing over a 10 MB object costs the same as handing over a number: nanoseconds.

The catch is coordination. Two threads touching the same data need a LockLock (mutex)A “do not disturb” sign for a piece of data: only the task holding the lock may touch it; others wait their turn., or a rule that only one of them owns it at a time — which is what passing it through a Go channel achieves (Channels §01).

Processes: send bytes through the OS

Processes can't share an address (§02), so every option for IPCIPC (inter-process communication)Any way for separate processes to exchange data: pipes, sockets, shared memory, files, signals. The OS has to be involved, because processes can't see each other's memory. goes through the kernel:

What copying really costs

A pipe carries bytes, not objects. To send an object you must turn it into bytes (SerializationSerializationTurning an in-memory object into a flat string of bytes (e.g. JSON) so it can be sent somewhere, and parsing it back on the other side. It costs CPU time proportional to the data size., e.g. JSON.stringify), the kernel copies those bytes in and out, and the other side parses them back:

Concrete numbers (approximate): a 10 MB JSON payload takes tens of milliseconds to stringify and about as long again to parse. Send it 50 times per second and those two steps alone can fill a core. Between threads, the same hand-off is a pointer.

A pipe in practice

Run the Unix sort program as a child, write lines into its stdin, read the sorted result from its stdout:

cmd := exec.Command("sort")                         // the child process
cmd.Stdin = strings.NewReader("pear\napple\nfig\n") // ← fed into its stdin pipe
out, err := cmd.Output()                            // ← read from its stdout pipe
if err != nil {
	log.Fatal(err)
}
fmt.Print(string(out)) // apple, fig, pear — one per line

Node-to-Node: a message channel

Node's child_process.fork() starts another Node process and adds a message channel on top of a pipe. Messages are serialized (JSON by default) on the way:

import { fork } from "node:child_process";

const child = fork("./child.js"); // a new Node process (path relative to the current directory)
child.on("message", (msg) => {
  console.log("child says", msg); // { done: 7 }
  child.disconnect();             // close the channel so both can exit
});
child.send({ task: "resize", id: 7 }); // ← serialized, sent through the pipe

When each wins: Chrome, Postgres, MySQL, Nginx, Redis

The decision table

Now five systems you've probably used, and the side each one picked.

Chrome: a process per site

Chrome runs a browser process (tabs, address bar), a GPU process, a network process, and renderer processes that run each site's HTML and JavaScript. Since Chrome 67 (2018), desktop Chrome gives each site its own renderer process ("Site Isolation").

• Crashes: a tab that crashes shows "Aw, Snap!" — the rest of the browser keeps running.
• Security: web pages are untrusted code. After SpectreSpectreA family of CPU flaws disclosed in 2018: code could trick the CPU into leaking memory from the same process through timing. It's why browsers put each website in its own process. showed that JavaScript could read memory within its own process through CPU timing tricks, the only safe answer was to never put two sites in the same process. The address-space walls from §02 became the security boundary.
• The price: memory. Each renderer has its own heap, its own copy of engine data. That's a big part of why Chrome uses so much RAM.

Postgres: a process per connection

Postgres has a main process (the postmaster) that forks a new backend process for every client connection. Isolation is good, and the design dates from when threads were poorly supported across operating systems.

• The price: each backend costs several MB at least (approximate; more with big queries). Thousands of connections means thousands of processes, so busy apps put a Connection poolerConnection pooler (PgBouncer)A small proxy between your app and a database that keeps a few real database connections open and shares them among many app connections. like PgBouncer in front.
• The twist: the backends share a large shared memoryShared memory (between processes)A region of RAM that the OS maps into two processes' address spaces at once, so both can read and write it directly. The fastest IPC — and it brings back all the data-race problems of threads. region (the buffer cache). If one backend dies abnormally — a memory fault, or the OOM killerOOM-killed“Out of memory”: the system kills a program that uses more memory than allowed. (§11) — the postmaster can't trust that memory any more — so it terminates every backend and recovers. Every connection drops. Sharing memory weakened the walls (§09).

MySQL: a thread per connection

MySQL runs one process (mysqld) with a thread per connection (some editions add a thread pool). Connections are cheaper than Postgres's, and all threads share caches directly. The flip side is the §03 rule: a crash in any thread takes the whole server down.

Nginx: a few processes, each with an event loop

Nginx runs a master process and a few worker processes — usually one per core — and each worker handles thousands of connections with an event loop. Processes give multi-core use and isolation; the event loop gives scale without a thread per connection. That's the same shape as Node + cluster (§07).

Redis: one main thread, and fork() for snapshots

Redis executes commands on a single main thread, so commands never race with each other (Redis 6+ can add I/O threads for network reading and writing). To save a snapshot to disk without pausing, it calls forkfork()The Unix system call that clones the calling process. The copy (the child) gets a new PID and a copy of the parent's memory and open files. It returns twice: 0 in the child, the child's PID in the parent.: the child writes the data to disk while the parent keeps serving.

That works because of Copy-on-writeCopy-on-write (COW)A lazy copy: after fork(), parent and child share the same memory pages, marked read-only. A page is only really copied when one of them writes to it. This makes fork() fast. (§06): the child sees a frozen copy of memory for free. Only pages the parent changes during the save get duplicated.

Production: limits, OOM kills and containers

A container is a process

There's no "container" object in the Linux kernel. A ContainerContainerA normal Linux process (or a small group of them) that the kernel fences off: it sees only its own files, processes and network, and gets a cap on how much CPU and memory it may use. Docker and Kubernetes run containers. is an ordinary process — your node server.js or Go binary — started with two extra kernel features:

• NamespacesNamespaces (Linux)A kernel feature that gives a process its own private view of something — its own list of PIDs, its own network interfaces, its own file system root. It controls what a container can see. control what it can see: its own list of PIDs (your app is often PID 1 inside), its own network interfaces, its own file system.
• 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. control how much it can use: CPU time, memory, number of processes.

# 512 MB of RAM, 2 CPUs' worth of time, at most 200 processes + threads
docker run --memory=512m --cpus=2 --pids-limit=200 my-api

The limits you'll hit

On Linux, threads count against the process limits — a thread is a "task" just like a process (§04).

When memory runs out, the kernel's OOM killer picks a victim and sends it SIGKILL. A signalSignal (Unix)A tiny message the OS delivers to a running process, e.g. SIGINT (Ctrl+C), SIGTERM (“please shut down” — what kill and Kubernetes send first), SIGKILL (stop immediately; can't be caught) or SIGQUIT (Ctrl+\, Go prints every goroutine's stack). Send one with kill -TERM <pid>. is the OS's way of tapping a process on the shoulder; SIGKILL (signal 9) is the one that can't be caught or ignored: the process just dies (128 + 9 = exit codeExit codeA small number a process returns when it ends: 0 means success, anything else means failure. 128 + N means it was killed by signal N (137 = SIGKILL, 139 = segfault). 137). It kills a whole process, never just one thread — the roommates go down together again. That's why you tell the runtime the budget, so it can clean up before the kernel steps in:

• Node: --max-old-space-size=384 (in MB) caps the JavaScript heap. Set it well below the container limit; buffers and native memory live outside it.
• Go: GOMEMLIMIT=450MiB (Go 1.19+) makes the garbage collector work harder as memory approaches the limit.
• Go CPU: Go 1.25+ sets GOMAXPROCS from the container's CPU limit, when go.mod says go 1.25 or later (§08). Node's libuv pool size (§07) doesn't adapt; set it yourself if you change it.

Shutting down politely: SIGTERM and PID 1

When Kubernetes (or docker stop) stops a container, it sends SIGTERM — "please finish up" — waits a grace period (30 s by default in Kubernetes), then sends SIGKILL, which can't be caught. Unlike SIGKILL, SIGTERM can be caught. Catch it, stop accepting new requests, finish the in-flight ones, exit:

ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM, os.Interrupt)
defer stop()

srv := &http.Server{Addr: ":8080", Handler: mux}
go func() {
	if err := srv.ListenAndServe(); err != nil && !errors.Is(err, http.ErrServerClosed) {
		log.Fatal(err)
	}
}()

<-ctx.Done() // ← blocks until SIGTERM (or Ctrl-C) arrives
shutdownCtx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
defer cancel()
// stop accepting; wait for in-flight requests (max 20 s)
if err := srv.Shutdown(shutdownCtx); err != nil {
	log.Printf("forced shutdown: %v", err) // the 20 s ran out
}

Here's what the handler buys you, and what happens without one:

Why the PID 1 remark? PID 1PID 1The first process started on a machine or inside a container. It has special duties: it must collect exited orphan processes, and the kernel ignores signals sent to it unless it installed a handler. is special: the kernel doesn't apply the default "die" action to signals it hasn't installed a handler for, and it adopts every Orphan processOrphan processA child process whose parent has already exited. PID 1 adopts it, and from then on PID 1 must collect (reap) its exit code when it finishes. (a child whose parent died), so it's expected to ReapReap (a child process)Collect a finished child's exit code with wait/waitpid. Only then does the kernel delete its entry; until that happens the child is a zombie. them when they exit — otherwise they stay zombiesZombie processA child process that has exited, but whose parent hasn't collected its exit code yet (with wait). It uses no CPU or memory, just a slot in the process table — but enough of them exhaust the PID limit. (§06). Two practical rules:

1. Start your app directly (CMD ["node", "server.js"]), not via npm start or a shell script that may not forward SIGTERM.
2. If your app starts child processes, run a tiny init in front of it — docker run --init or tini — to forward signals and reap zombies.

Seeing threads and processes

ps -o pid,nlwp,rss,comm -p 4120   # threads (NLWP) and memory (RSS) of one process
top -H -p 4120                    # live CPU use per THREAD of that process
ls /proc/4120/task | wc -l        # thread count, straight from the kernel
cat /sys/fs/cgroup/memory.max     # inside a container (cgroup v2): your memory limit

Pitfalls gallery

Six mistakes I've seen in real code reviews, each with the fix.

app.post("/thumb", (req, res) => {
  // a whole new JS engine per request
  const w = new Worker(new URL("./thumb.js", import.meta.url), {
    workerData: req.body,
  });
  w.once("message", (img) => res.send(img));
});

import Piscina from "piscina"; // a pool of reusable worker threads
// thumb.js: export default (body) => makeThumbnail(body);
const pool = new Piscina({
  filename: new URL("./thumb.js", import.meta.url).href,
});

app.post("/thumb", async (req, res) => {
  res.send(await pool.run(req.body)); // waits in a queue if all are busy
});

import { exec } from "node:child_process";
// name = "cat.png; rm -rf ~"  ← runs BOTH commands
exec(`convert ${name} thumb.png`);

import { execFile } from "node:child_process";
// No shell: name is ONE argument, whatever it contains.
execFile("convert", [name, "thumb.png"], (err) => {
  if (err) console.error(err);
});

cmd := exec.Command("convert", in, out)
cmd.Start() // runs in the background…
return nil  // …and nobody ever waits for it

cmd := exec.CommandContext(ctx, "convert", in, out)
if err := cmd.Start(); err != nil {
	return err
}
// …other work while it runs…
return cmd.Wait() // collects the exit code, closes pipes

func handler(w http.ResponseWriter, r *http.Request) {
	go sendAnalytics(r.URL.Path) // a panic here kills the server
	w.Write([]byte("ok"))
}

func handler(w http.ResponseWriter, r *http.Request) {
	path := r.URL.Path
	go func() {
		defer func() {
			if v := recover(); v != nil {
				log.Printf("analytics panicked: %v", v) // the server lives on
			}
		}()
		sendAnalytics(path)
	}()
	w.Write([]byte("ok"))
}

const sessions = new Map(); // exists once PER PROCESS
app.post("/login", (req, res) => {
  sessions.set(token, user);
  // …
});
app.get("/me", (req, res) => res.json(sessions.get(token))); // often undefined

// shared by every process (node-redis client)
await redis.set(`session:${token}`, JSON.stringify(user), { EX: 3600 });

const raw = await redis.get(`session:${token}`);
const user = raw && JSON.parse(raw);

Check yourself: predict the outcome

Commit to an answer before you click. Each one maps to a section: crashes (§03), memory walls (§02, §07), fork (§06), switching (§05) and per-process state (§07).

func main() {
    go func() {
        panic("boom")
    }()
    time.Sleep(time.Second)
    fmt.Println("main survived")
}

// main.js
import { Worker } from "node:worker_threads";
globalThis.count = 41;
new Worker(new URL("./w.js", import.meta.url));

// w.js
console.log(globalThis.count);

// bad.js:  throw new Error("boom");
import { Worker } from "node:worker_threads";
const w = new Worker(new URL("./bad.js", import.meta.url));
w.on("error", (e) => console.log("worker died:", e.message));
setTimeout(() => console.log("main alive"), 100);

// pseudocode, as in §06 (fork/waitpid aren't real JS functions)
let x = 1;
const pid = fork();
if (pid === 0) { x = 99; exit(0); }   // child
waitpid(pid);
console.log(x);                        // parent prints…

// One core does 20,000 context switches per second.
// Each costs ~5 µs (switch + cache warm-up).
// How much of that core goes to switching?

// Started with cluster: 4 worker processes, same code.
let hits = 0;
http.createServer((req, res) => {
  hits++;
  res.end(String(hits));
}).listen(3000);
// 8 requests arrive, spread evenly. The 8th response says…

Cheat sheet