Go Runtime Source Notes

Go from Request to Production

If you know only a little Go, you can start here. The whole series follows one small service: it receives a request, fetches several web pages concurrently, and returns the results as JSON. We first ask what the code does, then explain why it copies, waits, allocates, and reuses connections, and only then enter the standard library and runtime source.

First, picture one work order: the caller submits two URLs; the service visits both; after both results return, it combines them into one JSON response. On the first pass, follow only who receives the job, who starts work, who waits, and who hands results back. On the second pass, attach the standard-library and runtime names to those actions.

A two-pass route: if you only know variables, functions, structs, and basic loops, read the first two sections of the overview, then the request replay and conclusion in each chapter. Leave source fields, queue details, and diagnostic labs for a second pass. The chapter order remains values, scheduling, concurrency, abstraction, cancellation, memory, connections, and diagnosis.

One request through Go across Server.Serve, conn.serve, ServeHTTP, Transport, netpoll, scheduling, memory, and diagnostics

Source Notes · Chapter I How one request crosses net/http and the runtime

First see who accepts a connection, who runs application code, and who waits for the network; then follow the real handoffs through Server.Serve, Transport, and netpoll.

Go 1.26net/httpruntimeEnglish Source Notes · Chapter II What assignment copies and what a slice shares

Start with a puzzle—why can a copied slice still change the original data?—then learn value copies, shared backing data, append growth, and channel sends.

Go 1.26slicechannelEnglish Source Notes · Chapter III Where does a goroutine actually run?

Separate goroutines, threads, and parallelism first; then follow go h.fetch as it queues, runs, waits, and wakes.

Go 1.26schedulertraceEnglish Source Notes · Chapter IV When should we use channels or locks?

Use two examples—handing a result to someone else and jointly updating one state—to choose a channel or lock before reading how blocking, wake-up, and backpressure work.

Go 1.26channelMutexEnglish Source Notes · Chapter V Interface, generics, and reflection boundaries

Begin with three ordinary needs: depend on behavior, reuse one algorithm, or discover a type only at runtime; then enter interfaces, generics, and reflection.

Go 1.26interfacegenericsreflectionEnglish Source Notes · Chapter VI Did the goroutine stop after context cancellation?

Start with “why is the worker still running after cancel?” and separate sending a stop signal, worker exit, resource cleanup, and waiting for completion.

Go 1.26contextcancellationshutdownEnglish Source Notes · Chapter VII Why does one request land on the heap?

First learn that “on the heap” is not an error; then follow why an object must live longer, how it is allocated, and why a high allocation rate can make GC affect request latency.

Go 1.26escapeallocatorGCEnglish Source Notes · Chapter VIII Where does the bottleneck hide after connection reuse?

Start with “why are requests waiting if connections are reused?”, separate connections, HTTP/2 streams, and flow control, then use evidence to locate the slow layer.

Go 1.26TransportHTTP/2diagnosticsEnglish

All eight chapters are complete. One fetchd request now crosses value semantics, scheduling, concurrency primitives, abstraction boundaries, cancellation, allocation and GC, connection reuse, HTTP/2, and production diagnosis, with bilingual source notes, runnable labs, and paired illustrations throughout.