I · Anatomy

Verified against Minecraft 26.3 · Part I · The whole program at once: which threads exist, which loop each runs, and how the two halves talk.

Part I is the program the other twelve parts run inside. Java Minecraft is one codebase running as two programs — a server whose whole life is a tick loop, and a client whose life is a frame loop with ticks inside it — on four threads worth memorising: the Render thread, which is also the client’s game thread; the Server thread, which is the world; the Netty event loop, which carries the packets (Netty is the networking library both halves use); and one shared worker pool that chunk generation, the server’s lighting and section meshing all queue onto. A player recognises the split by its symptom, the game that keeps drawing while the world stands still, and the book returns to it wherever the two halves disagree, as when a broken block comes back for a moment. Read this part first for the plainest reason there is: nearly every lane in every sequence diagram after it is a class that runs on one of these threads, and the ten that are not a class are a thread, the process, the wire, the disk, the session service or the game’s own code.

The shape of the part

Two pages: what the program is, and where the book stops. The first is a trace and the second is a boundary, and the boundary is drawn second because a reader decides whether to go on once they can see the whole program.

flowchart LR
    A["1 · Anatomy<br/>a trace: four threads, two loops, one wire"]
    B["2 · What this book skips<br/>a boundary: where the book stops"]
    A -- "the program first" --> B

The part’s two lectures, numbered to the watch order. The arrow is a dependency, not a call: the boundary means nothing until you can see the program it is drawn around.

Before you start

Nothing. This is the first part, and it assumes only that you have played the game.

Watch in this order

Anatomy — from main to a running singleplayer world: the Render thread that is also the game thread, the Server thread that is the world, the Netty threads that run more than bytes, and the one CPU pool that chunk generation, the server’s lighting and section meshing all share.
What this book skips — the boundary, drawn honestly on the treemap of the jar: save migration, Realms, telemetry, the profilers, the management server, the data generators, and where to start if you need one anyway. It is the second lecture and not the last because a boundary is worth drawing before you invest in thirteen parts, not after.

Where the part stops

Part I says which threads exist and hands the two loops and the wire on. What the Server thread does with a tick is Part III; what the frame loop does between ticks is Part X, and the frame itself Part XI; what crosses the wire between them is Part IX. This part owes you only enough of each to read a lane.

The part’s own packages are the two entry points, the client’s GameConfig and SilentInitException, and the two loop classes, and it leaves none of them unnamed: 0% of the part’s lines are named on no page in the book. The boundary that matters here is the book’s rather than the part’s, and drawing it is the second lecture’s whole job.

Reference this part uses

Diagram lanes — the abbreviations every sequence diagram uses, needed from the first figure of the first lecture onward. Threads — every thread, who makes it and what may run on it; Part I names the four to memorise and this is the rest. Naming drift — the 1.21-era names that have moved. The atlas — where everything is, and the treemap the second lecture reads.

Rules: names, never code · how the system works, not how the code reads · newest version only · every backticked name passes tools/verify_names.py.

Keyboard shortcuts