How Go (Golang) Works?

Go (Golang) is a programming language developed at Google, designed to meet modern software engineering needs. In this article, we’ll examine Go’s execution model in depth—from compilation to runtime internals, from goroutines to garbage collection.

Summary

• Compilation pipeline: Lexer, parser, type checker, SSA, code generation
• Runtime internals: Scheduler (M:P:G), memory manager, garbage collector
• Concurrency model: Goroutines, channels, select
• Performance: Native binary, low latency, high throughput
• Production ready: Case studies, debugging scenarios, optimization techniques

Note: This article is a deep dive into the Go runtime. When applying these ideas in production, also follow the official documentation and best practices.

1. Go Program Lifecycle

When you write and run a Go program, it goes through the following steps:

Step-by-step explanation

1. Source code (.go): Go source files are written
2. Compile: The program is compiled with go build or go run
3. Executable (binary): A platform-specific binary is produced
4. Go runtime initialization: Runtime subsystems are initialized
5. main() execution: The program starts

Go is not an interpreted language. Your code is ahead-of-time compiled and runs directly on the OS. This provides:

• Fast startup: No JIT compilation delay
• Predictable performance: No runtime compilation overhead
• Small binary footprint: Optimized even though the runtime is included

2. Compilation Process

The Go compiler uses a modern compilation pipeline:

Compilation stages

2.1 Lexer & Tokenizer

Splits the source code into tokens:

• Keywords (func, var, if)
• Operators (+, -, :=)
• Literals (string, number)
• Identifiers (variable and function names)

2.2 Parser (AST Generation)

Transforms tokens into an Abstract Syntax Tree (AST):

1
2
3
4

// Example code
func add(a, b int) int {
    return a + b
}

This code produces an AST roughly like:

• Function declaration node
• Parameter list nodes
• Return statement node
• Binary expression node

2.3 Type Checker

Performs static type checking:

• Detects type mismatches
• Verifies interface implementations
• Performs type inference

2.4 Escape Analysis

Decides whether variables should live on the stack or escape to the heap:

1
2
3
4

func example() *int {
    x := 42  // Escape analysis: x escapes to the heap
    return &x
}

2.5 SSA (Static Single Assignment)

The code is converted into SSA form. This is critical for optimization:

SSA form characteristics:

• Each variable is assigned exactly once
• Data-flow analysis becomes easier
• Optimizations become more effective

2.6 SSA Optimization Passes

Many optimization passes run on SSA form:

1. Dead Code Elimination

Removes code that is proven to be unused:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Before
func example() {
    x := 42
    y := 10
    return x  // y is unused
}

// After (optimized)
func example() {
    x := 42
    return x  // y removed
}

How it works:

• Finds unused variables via data-flow analysis
• Removes unreachable code
• Can drop unused functions (where applicable)

2. Constant Propagation

Propagates constant values:

1
2
3
4
5
6

// Before
const x = 42
y := x + 10  // can be computed as 52

// After (optimized)
y := 52  // computed at compile time

How it works:

• Evaluates constant expressions at compile time
• Substitutes constants at their use sites
• Simplifies conditional branches when possible

3. Common Subexpression Elimination (CSE)

Avoids recomputing identical expressions:

1
2
3
4
5
6
7

// Before
x := a + b
y := a + b  // recomputed

// After (optimized)
x := a + b
y := x  // reused

How it works:

• Stores expressions (conceptually) and reuses them when they match
• Reduces redundant work and register pressure

4. Loop Invariant Code Motion

Moves loop-invariant work out of loops:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Before
for i := 0; i < n; i++ {
    x := expensive()  // computed each iteration
    result[i] = x + i
}

// After (optimized)
x := expensive()  // hoisted out of the loop
for i := 0; i < n; i++ {
    result[i] = x + i
}

How it works:

• Detects expressions that don’t change across iterations
• Hoists them outside the loop

5. Inlining Decisions

Inlines small functions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Before
func add(a, b int) int {
    return a + b
}

func main() {
    x := add(1, 2)  // Function call overhead
}

// After (optimized)
func main() {
    x := 1 + 2  // inlined
}

Inlining criteria (simplified):

• Function size (often below a certain threshold)
• Call frequency
• Function complexity
• Not recursive

Inlining advantages:

• Removes call overhead
• Enables further optimizations
• Often improves register allocation

Inlining downsides:

• Binary size may increase
• More pressure on the instruction cache

2.7 Code Generation

Conversion from SSA to machine code:

• Register allocation
• Instruction selection
• Peephole optimizations

Register Allocation:

• Live variable analysis
• Register spilling (if needed)
• Register coalescing

Instruction Selection:

• Selects platform-specific instructions
• Instruction scheduling
• Pipeline optimization

Compilation result

At the end of compilation, you get a platform-specific binary:

Note: Go binaries often include the runtime. This makes deployment simple—you can usually just copy and run the binary.

Cross-Compilation

Go supports cross-compilation natively:

1
2
3
4
5

# Windows binary from Linux/macOS
GOOS=windows GOARCH=amd64 go build

# ARM64 binary for macOS
GOOS=darwin GOARCH=arm64 go build

3. What Is the Go Runtime?

The Go runtime is the subsystem that stays active while your program runs. In the same way V8 is “the engine” for JavaScript, the Go runtime is the engine room for Go.

Runtime components

3.1 Goroutine Scheduler

• Distributes goroutines onto OS threads
• Uses a work-stealing algorithm
• Operates with the M:P:G model

3.2 Memory Manager

• Stack and heap management
• Memory pools
• Allocation optimizations

3.3 Garbage Collector

• Concurrent mark-and-sweep
• Low-latency design
• Automatic memory reclamation

3.4 Channel Implementation

• Runtime implementation of channels
• select statement mechanics
• Blocking/unblocking logic

3.5 System Calls

• Communication with the OS
• Network I/O
• File I/O

Runtime initialization

When the program starts, the runtime initializes in roughly the following order. This happens before runtime.main():

Bootstrap sequence details

1. Entry Point (_rt0_amd64)

1
2
3
4
5

// runtime/rt0_linux_amd64.s (assembly)
TEXT _rt0_amd64(SB),NOSPLIT,$-8
    MOVQ    0(SP), DI  // argc
    LEAQ    8(SP), SI  // argv
    JMP     runtime·rt0_go(SB)

2. TLS (Thread Local Storage) Initialization

TLS provides fast access to each OS thread’s goroutine (g), machine (m), and processor (p) pointers. This is critical for scheduler performance.

3. Runtime Args Parsing

• Reads GOGC
• Determines GOMAXPROCS
• Parses GODEBUG flags
• Sets memory limits

4. CPU Detection

1
2
3
4
5

// runtime/os_linux.go
func osinit() {
    ncpu = getproccount()  // CPU core count
    physPageSize = getPageSize()  // Page size
}

5. Memory Allocator Initialization

• Creates mcache, mcentral, mheap
• Initializes size classes
• Prepares memory pools

6. Scheduler Initialization

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// runtime/proc.go
func schedinit() {
    // Create P's (GOMAXPROCS)
    procs := runtime.GOMAXPROCS(0)
    for i := int32(0); i < procs; i++ {
        newproc()
    }
    
    // Create the first M
    mcommoninit(m0)
}

7. Signal Handling Setup

Go uses signals for the following:

• SIGURG: Async preemption (Go 1.14+)
• SIGQUIT: Stack trace dump (Ctrl+)
• SIGSEGV: Segmentation fault handling
• SIGINT/SIGTERM: Graceful shutdown

8. Network Poller Initialization

1
2
3
4
5

// runtime/netpoll.go
func netpollinit() {
    // epoll (Linux), kqueue (BSD), IOCP (Windows)
    epfd = epollcreate1(_EPOLL_CLOEXEC)
}

The network poller is used to make I/O non-blocking.

9. Defer Mechanism The defer stack and panic/recover machinery are initialized.

10. runtime.main() call

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// runtime/proc.go
func main() {
    // Run all init() functions
    doInit(&runtime_inittask)
    doInit(&main_inittask)
    
    // Call main.main()
    fn := main_main
    fn()
    
    // Program finished
    exit(0)
}

Runtime initialization timeline

Total bootstrap time is typically around 1–2 milliseconds.

4. What Is a Goroutine?

A goroutine is the foundation of Go’s concurrency model. It is far lighter and more efficient than an OS thread.

Creating goroutines

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Simple goroutine
go doSomething()

// With an anonymous function
go func() {
    fmt.Println("Goroutine is running")
}()

// Parameterized goroutine
go processData(data)

Goroutine vs thread comparison

Goroutine lifecycle

Goroutine characteristics

1. Lightweight: ~2KB initial stack
2. Fast startup: Can start in microseconds
3. Dynamic stack: Grows as needed (up to ~1GB)
4. Cooperative scheduling: Can yield at safe points
5. Work stealing: Idle P’s steal work from other P’s queues

Practical example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

package main

import (
    "fmt"
    "time"
)

func main() {
    // Start 10,000 goroutines
    for i := 0; i < 10000; i++ {
        go func(id int) {
            fmt.Printf("Goroutine %d is running\n", id)
            time.Sleep(1 * time.Second)
        }(i)
    }
    
    time.Sleep(2 * time.Second)
    fmt.Println("All goroutines completed")
}

In this example, you can start 10,000 goroutines. If you tried to start the same number of OS threads, you would quickly exhaust system resources.

5. How Does the Go Scheduler Work?

The Go scheduler is the system that maps goroutines onto OS threads. It uses the M:P:G model.

The M:P:G model

Model components

G (Goroutine)

• The unit of work to execute
• Has its own stack
• Contains a program counter (PC)
• Can be blocked on wait objects like channels and mutexes

P (Processor)

• Execution capacity (context)
• Each P has a local run queue
• Count is usually equal to CPU core count (GOMAXPROCS)
• Has access to the global queue (and other P’s) for work stealing

M (Machine)

• Represents an OS thread
• Is associated with a P while executing Go code
• Runs on a real CPU core
• Can detach from P when entering a blocking system call

Scheduler algorithm

Scheduler properties

1. Work stealing: Idle P’s steal work from busy P’s run queues
2. Preemption: Goroutines are preempted roughly every 10ms (Go 1.14+)
3. System call handling: Blocking syscalls release P so other goroutines can run
4. Network poller: Dedicated poller integration for non-blocking I/O
5. Spinning threads: A spinning strategy to reduce latency when new work arrives

Preemption (Go 1.14+)

Before Go 1.14, goroutines were only preempted cooperatively (e.g., runtime.Gosched(), channel ops, function call boundaries). This could allow CPU-heavy goroutines to starve others.

Async Preemption (Go 1.14+)

Preemption types:

1. Cooperative preemption (older approach)

   • runtime.Gosched() call
   • Channel operations
   • Function call boundaries
   • Stack growth

2. Async preemption (Go 1.14+)

   • sysmon goroutine: checks periodically (~10ms)
   • SIGURG: sent to the goroutine to be preempted
   • Function prologue: preempt flag checked at function entry
   • Stack scanning: stack is scanned at safe points

1
2
3
4
5
6

// Preemption check (at function entry)
func functionPrologue() {
    if getg().preempt {
        goschedImpl()  // Preempt
    }
}

Preemption Timeline:

🔧 Production Note:

The async preemption mechanism is critical for preventing latency spikes in high CPU-consuming services. It ensures predictable performance in production by preventing CPU-bound goroutines from starving other goroutines.

Spinning threads

Spinning is when a P actively waits briefly instead of immediately sleeping the OS thread. This can reduce latency when new goroutines arrive.

Spinning strategy:

• When the local run queue is empty, P may spin for ~1ms
• If new work arrives during this window, it runs immediately
• If the window expires, the OS thread goes to sleep
• The thread is woken up when new work arrives

Spinning advantages:

• Lower latency (new work starts quickly)
• Better responsiveness under bursty workloads

Spinning disadvantages:

• CPU usage (the CPU is busy while spinning)
• Power consumption (notably on laptops)

Network poller integration

The network poller is used to make I/O non-blocking. Go uses platform-specific APIs such as epoll (Linux), kqueue (BSD), and IOCP (Windows).

Network poller structure:

1
2
3
4
5
6
7

// runtime/netpoll.go
type pollDesc struct {
    fd      uintptr
    closing bool
    rg      uintptr  // Read goroutine
    wg      uintptr  // Write goroutine
}

Network poller thread:

• A single dedicated OS thread
• Waits for events via epoll_wait() / kqueue()
• Wakes the appropriate goroutine when I/O completes

System Call Wrapping

Goroutines that enter blocking syscalls must release P so other goroutines can continue to run.

entersyscall/exitsyscall mechanism:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

// runtime/proc.go

// When entering a system call
func entersyscall() {
    // Release P (so another M can use it)
    releasep()
    // Mark M as being in a system call
    getg().m.incallsyscall = true
}

// When exiting a system call
func exitsyscall() {
    // Try to get a P back
    if oldp := getg().m.oldp; oldp != nil {
        // Reacquire the old P
        acquirep(oldp)
    } else {
        // Find a new P
        acquirep(pidleget())
    }
}

System call scenarios:

1. Blocking System Call (read, write, accept)

   • P is released
   • A new M may be created (if needed)
   • A P is reacquired when the syscall returns

2. Non-blocking / fast system call

   • P is kept (short-lived)
   • The system call returns quickly
   • No need to release P

M creation strategy:

M limit:

• Default: 10,000 M
• Can be changed via runtime/debug.SetMaxThreads()
• Too many M’s can exhaust OS resources

Work stealing details

Work stealing is when an idle P steals runnable goroutines from a busy P.

Work stealing algorithm:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// runtime/proc.go
func findrunnable() *g {
    // 1. Get from local queue
    if gp := runqget(_p_); gp != nil {
        return gp
    }
    
    // 2. Get from global queue
    if sched.runqsize != 0 {
        return globrunqget(_p_, 0)
    }
    
    // 3. Work stealing
    for i := 0; i < 4; i++ {
        // Pick a random P
        p2 := allp[fastrand()%len(allp)]
        if p2 != _p_ && !p2.runqempty() {
            // Steal half from P2's local queue
            n := p2.runq.len / 2
            for j := 0; j < n; j++ {
                gp := p2.runq.pop()
                _p_.runq.put(gp)
            }
            return _p_.runq.get()
        }
    }
    
    // 4. Check network poller
    if netpollinited() {
        if gp := netpoll(0); gp != nil {
            return gp
        }
    }
    
    // 5. Idle
    return nil
}

GOMAXPROCS

1

runtime.GOMAXPROCS(4) // Use 4 P's

By default, it equals the CPU core count. If you increase it:

• More parallelism
• More context-switch overhead
• More memory usage

GOMAXPROCS tuning:

1
2
3
4
5
6
7
8

// For CPU-bound workloads
runtime.GOMAXPROCS(runtime.NumCPU())

// For I/O-bound workloads
runtime.GOMAXPROCS(runtime.NumCPU() * 2)

// For low-latency targets
runtime.GOMAXPROCS(runtime.NumCPU())

🔧 Production Note:

Setting GOMAXPROCS appropriately for your workload type is critical in production. For I/O-bound services, set it to 2-4x the CPU count; for CPU-bound services, set it to the CPU count. Incorrect settings can cause context switch overhead or CPU underutilization.

Practical example: observing the scheduler

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    fmt.Printf("CPU Cores: %d\n", runtime.NumCPU())
    fmt.Printf("GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))
    
    // Start 100 goroutines
    for i := 0; i < 100; i++ {
        go func(id int) {
            for {
                // CPU-heavy work
                runtime.Gosched() // voluntarily yield the CPU
            }
        }(i)
    }
    
    time.Sleep(1 * time.Second)
    fmt.Printf("Active Goroutine Count: %d\n", runtime.NumGoroutine())
}

Scheduler trace analysis

1
2
3
4
5

# Generate scheduler trace output
GODEBUG=schedtrace=1000 go run main.go

# Output:
# SCHED 1000ms: gomaxprocs=4 idleprocs=0 threads=5 spinningthreads=0 idlethreads=0 runqueue=0 [0 0 0 0]

Trace output explanation:

• gomaxprocs=4: 4 P’s active
• idleprocs=0: No idle P’s
• threads=5: 5 OS thread (4 M + 1 network poller)
• spinningthreads=0: No spinning threads
• idlethreads=0: No idle threads
• runqueue=0: No goroutines in the global run queue
• [0 0 0 0]: Goroutine count in each P’s local run queue

6. Communication with Channels

In Go, goroutines typically communicate via channels rather than shared memory. This approach follows the philosophy:

“Don’t communicate by sharing memory, share memory by communicating.”

.

Channel types

Unbuffered Channel

1
2
3
4
5
6
7

ch := make(chan int) // Unbuffered

go func() {
    ch <- 42  // Blocks until a receiver is ready
}()

value := <-ch  // Blocks until a sender is ready

Characteristics:

• Synchronous rendezvous
• Sender and receiver must be ready at the same time
• Blocking operation

Buffered Channel

1
2
3
4
5
6

ch := make(chan int, 3) // buffer capacity: 3

ch <- 1  // Non-blocking (space available)
ch <- 2  // Non-blocking
ch <- 3  // Non-blocking
ch <- 4  // Blocking (buffer full)

Characteristics:

• Asynchronous communication
• Non-blocking until the buffer is full
• Blocks when the buffer is full

Channel operations

Select Statement

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

select {
case msg1 := <-ch1:
    fmt.Println("message from ch1:", msg1)
case msg2 := <-ch2:
    fmt.Println("message from ch2:", msg2)
case ch3 <- 42:
    fmt.Println("sent to ch3")
default:
    fmt.Println("none ready")
}

How select works:

Closing channels

1
2
3
4
5
6

close(ch)  // Close the channel

value, ok := <-ch
if !ok {
    // Channel is closed
}

Closed channel behavior:

• Receiving returns the zero value immediately
• Sending panics
• Closing an already-closed channel panics

Channel Patterns

1. Worker Pool Pattern

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

func workerPool(jobs <-chan int, results chan<- int) {
    for job := range jobs {
        result := process(job)
        results <- result
    }
}

jobs := make(chan int, 100)
results := make(chan int, 100)

// Start 10 workers
for w := 0; w < 10; w++ {
    go workerPool(jobs, results)
}

// Send jobs
for j := 1; j <= 100; j++ {
    jobs <- j
}
close(jobs)

2. Fan-Out / Fan-In Pattern

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Fan-out: distribute from one channel to multiple workers
func fanOut(input <-chan int, outputs []chan int) {
    for val := range input {
        for _, out := range outputs {
            out <- val
        }
    }
}

// Fan-in: collect from multiple channels into one channel
func fanIn(inputs []<-chan int, output chan<- int) {
    var wg sync.WaitGroup
    for _, in := range inputs {
        wg.Add(1)
        go func(ch <-chan int) {
            defer wg.Done()
            for val := range ch {
                output <- val
            }
        }(in)
    }
    wg.Wait()
    close(output)
}

7. Memory Management

Memory management in Go is automatic, but understanding the difference between stack and heap is critical for performance.

Stack vs Heap

Escape Analysis

The Go compiler decides whether a variable lives on the stack or escapes to the heap using escape analysis.

Escape analysis examples

Stays on stack

1
2
3
4

func stackExample() int {
    x := 42  // On stack
    return x
}

🔧 Production Note:

Understanding escape analysis is critical for production performance. You can see which variables escape to the heap using go build -gcflags=-m. Variables that stay on the stack run without GC overhead, which provides significant performance gains, especially in hot paths.

Escapes to heap

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

func heapExample() *int {
    x := 42  // Escapes to heap (pointer return)
    return &x
}

func channelExample() {
    ch := make(chan *int)
    x := 42
    ch <- &x  // x escapes to heap
}

func closureExample() func() int {
    x := 42  // Escapes to heap (closure)
    return func() int {
        return x
    }
}

Memory structure

Memory layout visualization

Go program memory layout (Linux x86-64):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

+-------------------+  <- 0x7fffffffffff (High Address)
|                   |
|   Stack (G1)      |  <- Goroutine 1 stack (2KB-1GB)
|   [Local vars]    |
+-------------------+
|   Stack (G2)      |  <- Goroutine 2 stack
|   [Local vars]    |
+-------------------+
|       ...         |
+-------------------+
|                   |
|       Heap        |  <- Dynamic memory
|  [mcache spans]  |     - Small objects (mcache)
|  [mcentral]      |     - Central pools
|  [mheap arenas]  |     - Large objects
|  [GC metadata]   |     - GC structures
|                   |
+-------------------+
|   Data Segment    |  <- Static data
|  [Global vars]   |     - Global variables
|  [BSS]           |     - Uninitialized data
|  [Constants]     |     - Read-only constants
+-------------------+
|   Text Segment   |  <- Executable code
|  [Binary Code]   |     - Machine instructions
|  [Runtime]       |     - Go runtime code
+-------------------+  <- 0x400000 (Low Address)

Memory segment details:

Memory layout characteristics:

Guard Pages:

• To detect stack overflow
• Special pages at the end of a stack
• Access → segmentation fault

Stack growth and shrinking

Goroutine stacks grow and shrink dynamically:

Stack growth mechanism:

1. Detect imminent stack overflow (approaching a guard page)
2. Allocate a new, larger stack (typically 2x)
3. Copy data from the old stack to the new stack
4. Update pointers (integrated with stack copying + GC)
5. Free the old stack

Stack shrinking mechanism:

Stack shrinking conditions:

• Happens during GC stack scanning
• Shrinks if more than 50% is unused
• Minimum stack size: 2KB
• Reduces memory footprint and GC overhead

Stack splitting vs stack copying

Go tried two different approaches for stack growth:

Stack Splitting (Go 1.2 and Earlier)

How it worked:

1. When stack growth was needed, a new stack segment was allocated
2. Pointers in the old stack were updated to reference the new segment
3. The stack consisted of segments (similar to a linked list)

Problems:

• Hot split problem: performance issues when stacks grow frequently
• Complex pointer updates: updating all pointers is hard
• Cache locality: segments live in different memory regions
• GC complexity: stack scanning becomes more complex

Stack Copying (Go 1.3+)

How it works:

1. Allocate a new, larger stack (typically 2x)
2. Copy all data from the old stack to the new stack
3. Update pointers (integrated with stack copying + GC)
4. Free the old stack

Advantages:

• Simplicity: one continuous memory region
• Performance: better cache locality
• GC simplicity: stack scanning is simpler
• Predictability: more predictable performance

Why copying was preferred:

Copying overhead:

• Copy cost: ~1–5µs (depends on stack size)
• Pointer update: handled automatically by the runtime/GC machinery
• Frequency: rare (stack growth is not frequent)

Copying optimizations:

• Copy-on-write (where possible)
• Bulk copy (optimized memory moves)
• GC integration (stack copying is integrated with scanning/updating)

Memory allocator architecture: mcache, mcentral, mheap

Go’s allocator uses a three-tier structure:

mcache (Per-P Cache)

Each P has its own mcache, enabling mostly lock-free allocation.

1
2
3
4
5

// runtime/mcache.go
type mcache struct {
    alloc [numSpanClasses]*mspan  // Spans by size class
    // ...
}

Characteristics:

• Lock-free: no locks needed because it’s P-local
• Fast allocation: served directly from the local cache
• Refill: replenished from mcentral when empty

mcentral (Global Pool)

A central pool shared by all P’s.

1
2
3
4
5
6
7

// runtime/mcentral.go
type mcentral struct {
    spanclass spanClass
    partial [2]spanSet  // Partial spans
    full    [2]spanSet  // Full spans
    // ...
}

Characteristics:

• Lock-protected for concurrent access
• Per size class: a separate mcentral for each size class
• Span management: manages partial and full spans

mheap (OS Memory)

The main structure that obtains memory from the OS and manages spans.

1
2
3
4
5
6
7
8
9

// runtime/mheap.go
type mheap struct {
    arenas [1 << arenaL1Bits]*[1 << arenaL2Bits]*heapArena
    central [numSpanClasses]struct {
        mcentral mcentral
        pad      [cpu.CacheLinePadSize - unsafe.Sizeof(mcentral{})%cpu.CacheLinePadSize]byte
    }
    // ...
}

Characteristics:

• Arena-based: large memory blocks (e.g., 64MB arenas)
• Span allocation: carves spans out of arenas
• OS interaction: talks to the OS via mmap/munmap

Span structure

A span is the basic unit of heap management. It contains one or more pages.

Span characteristics:

• Size: 8KB to 512KB (depending on page count)
• Size class: determines object size within the span
• State: Free, partial, full
• Linked list: managed in mcentral via lists

Span Lifecycle:

Size class mechanism

Go uses 67 different size classes:

1
2
3
4
5
6
7

// runtime/sizeclasses.go
// Size class 0: 8 bytes
// Size class 1: 16 bytes
// Size class 2: 24 bytes
// Size class 3: 32 bytes
// ...
// Size class 66: 32768 bytes (32KB)

Size class selection:

Size class advantages:

• Reduces internal fragmentation: similar-sized objects share the same span
• Fast allocation: served from per-size-class free lists
• Cache efficiency: improved locality

Memory allocation flow

Large Object Allocation

Objects larger than 32KB are allocated directly from mheap:

1
2
3
4
5

// runtime/malloc.go
func largeAlloc(size uintptr, needzero bool, noscan bool) *mspan {
    // Direct allocation from mheap
    // No size class, no mcache
}

Large object characteristics:

• Direct allocation: mcache/mcentral bypass
• Zero-copy: optimized for large objects
• GC overhead: large objects impact GC

Memory Pool

Go uses memory pools for small objects:

Size classes:

• 8, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, … bytes
• Separate pool per size class
• Fast allocation/deallocation

Memory ordering and atomic operations

Go provides atomic operations with well-defined memory ordering:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import "sync/atomic"

var counter int64

// Atomic increment
atomic.AddInt64(&counter, 1)

// Atomic load
value := atomic.LoadInt64(&counter)

// Atomic store
atomic.StoreInt64(&counter, 42)

// Compare and swap
swapped := atomic.CompareAndSwapInt64(&counter, old, new)

Memory Ordering Semantics:

Go Atomic Operations:

• Load: Acquire semantics
• Store: Release semantics
• CAS: Acquire-Release semantics
• Add/Sub: Sequentially consistent

Use cases:

• Lock-free data structures
• Counters
• Flags
• Memory allocator internals

Practical tips

1. Avoid unnecessary pointers: staying on stack is faster
2. Pass large structs by pointer: reduces copying overhead
3. Inspect escape analysis: go build -gcflags=-m
4. Profile memory: go tool pprof

8. Garbage Collector (GC)

Go’s garbage collector automatically reclaims unused memory. It is designed to be modern, concurrent, and low-latency.

GC history

GC algorithm: tri-color mark & sweep

GC process

GC phases

1. Mark Phase (Concurrent)

1
2
3
4
5
6
7

// Find GC roots
- Global variables
- Stack variables
- Registers

// Mark all reachable objects
// Runs concurrently

Mark phase characteristics:

• Concurrent: the application (mutator) keeps running
• Write Barrier: Preserves marking invariants while the mutator writes
• Work-stealing: for parallel marking

2. Mark Termination (Stop-the-World)

STW duration:

• Go 1.8+: < 1ms (often < 100µs)
• Go 1.12+: < 100µs (often)
• Go 1.18+: further optimized

3. Sweep Phase (Concurrent)

1
2
3

// Sweep unmarked objects
// Runs concurrently
// Lazy sweeping: as needed

GC trigger mechanism

GC is triggered in these situations:

GOGC variable:

• Default: 100
• Meaning: GC triggers when the heap grows by 100%
• Example: 50MB heap → GC when it reaches 100MB

1
2

GOGC=200 go run main.go  # GC less frequently
GOGC=50 go run main.go   # GC more frequently

🔧 Production Note:

Optimizing the GOGC value for your workload in production is important. For services requiring high throughput, GOGC=200-300 is usually more suitable; for services requiring low latency, GOGC=50-100 is better. When used together with memory limits (Go 1.19+), it provides better control.

Write barrier implementation

The write barrier tracks pointer writes performed by the mutator during concurrent GC.

Write barrier types:

1. Hybrid Write Barrier (Go 1.8+)

1
2
3
4
5
6

// runtime/barrier.go
func gcWriteBarrier(dst *uintptr, src uintptr) {
    // 1. Shade src (if white)
    // 2. Shade dst (if white)
    // 3. Perform the write
}

Write Barrier Overhead:

• Invoked on pointer writes
• ~5-10ns overhead per write
• Optimized by the compiler (where needed)

GC pacing algorithm

Pacing determines when GC should start and how aggressively it should run.

Pacing calculation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// runtime/mgc.go
func gcControllerState.endCycle() {
    // Compute heap growth rate
    growth := float64(heapLive) / float64(heapGoal)
    
    // Compute GC CPU budget
    cpuBudget := 0.25  // 25% CPU for GC
    
    // Compute mark-assist ratio
    assistRatio := allocationRate / scanRate
}

Pacing strategy:

• By heap growth rate: Faster growth → more frequent GC
• By allocation rate: Higher allocation → more mark assists
• By CPU budget: GC can use ~25% of CPU

GC assists

GC assist means goroutines that allocate also help the GC keep up.

GC assist calculation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// runtime/mgc.go
func gcAssistAlloc(gp *g) {
    // Compute debt
    debt := gp.gcAssistBytes
    
    // Do mark work
    workDone := gcMarkWork(gp, debt)
    
    // Reduce debt
    gp.gcAssistBytes -= workDone
}

Assist properties:

• Proportional: based on allocation amount
• Fair: each goroutine contributes proportionally
• Non-blocking: does not block GC workers

Scavenging (Memory Return to OS)

Scavenging returns unused memory back to the OS.

Scavenging strategy:

1
2
3
4
5
6

// runtime/mheap.go
func (h *mheap) scavenge() {
    // Scavenge free spans older than 5 minutes
    // If at least 1MB of free memory exists
    // Return to OS (madvise)
}

Scavenging properties:

• Lazy: done as needed
• Threshold-based: requires minimum free memory
• OS-specific: MADV_FREE on Linux, VirtualFree on Windows

Scavenging Timeline:

GC Phases Timeline

GC phase durations:

• Mark phase: 5–50ms (depends on heap size)
• Mark Termination: < 100µs (STW)
• Sweep Phase: 5-20ms (concurrent)
• Scavenge: 1-5ms (lazy)

GC performance metrics

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package main

import (
    "fmt"
    "runtime"
    "runtime/debug"
    "time"
)

func main() {
    // Read GC statistics
    var m runtime.MemStats
    runtime.ReadMemStats(&m)
    
    fmt.Printf("GC Count: %d\n", m.NumGC)
    fmt.Printf("Total GC Pause: %v\n", time.Duration(m.PauseTotalNs))
    fmt.Printf("Heap Alloc: %d KB\n", m.Alloc/1024)
    fmt.Printf("Next GC Target: %d KB\n", m.NextGC/1024)
    fmt.Printf("GC CPU Fraction: %.2f%%\n", m.GCCPUFraction*100)
    
    // GC settings
    debug.SetGCPercent(100)  // Default
    debug.SetMemoryLimit(1024 * 1024 * 1024)  // 1GB limit (Go 1.19+)
}

GC metrics:

• NumGC: Total GC count
• PauseTotalNs: Total pause time
• GCCPUFraction: Fraction of CPU used by GC
• NextGC: Next GC trigger threshold
• HeapAlloc: Current heap allocation

GC optimization tips

1. Use object pools: reuse with sync.Pool
2. Tune GOGC: optimize for your workload
3. Avoid large allocations: small, steady allocations are often better
4. Reduce pointers: lowers GC marking overhead
5. Memory profiling: analyze with go tool pprof

Using sync.Pool

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

var pool = sync.Pool{
    New: func() interface{} {
        return make([]byte, 1024)
    },
}

func process() {
    buf := pool.Get().([]byte)
    defer pool.Put(buf)
    
    // use buf
}

Pool benefits:

• Reduces GC pressure
• Reduces allocation overhead
• Encourages reuse

🔧 Production Note:

Using sync.Pool is critical, especially for services requiring high throughput. Using pools for frequently allocated, short-lived objects significantly reduces GC pressure. However, remember that objects retrieved from the pool must be zeroed, otherwise there’s a risk of data leaks.

9. Go vs Other Languages

Go vs JavaScript

Go vs Java

Go vs Rust

10. Mutex and Atomic Operations

In Go, besides channels, there are traditional synchronization primitives.

sync.Mutex

Mutexes are used to protect critical sections.

1
2
3
4
5
6
7
8

var mu sync.Mutex
var counter int

func increment() {
    mu.Lock()
    defer mu.Unlock()
    counter++
}

Mutex properties:

• Exclusive lock: one goroutine holds the lock; others wait
• Not re-entrant: the same goroutine cannot lock it again
• Not strictly fair: no FIFO guarantee

sync.RWMutex

RWMutex separates reads and writes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

var rwmu sync.RWMutex
var data map[string]int

func read(key string) int {
    rwmu.RLock()
    defer rwmu.RUnlock()
    return data[key]
}

func write(key string, value int) {
    rwmu.Lock()
    defer rwmu.Unlock()
    data[key] = value
}

RWMutex properties:

• Multiple readers: many goroutines can read concurrently
• Single writer: writes block all readers
• Write preference: writers are prioritized over readers

Mutex vs RWMutex performance:

Atomic Operations

Atomic operations are used for lock-free programming.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

import "sync/atomic"

var counter int64

// Atomic increment
atomic.AddInt64(&counter, 1)

// Atomic load
value := atomic.LoadInt64(&counter)

// Atomic store
atomic.StoreInt64(&counter, 42)

// Compare and swap
old := atomic.LoadInt64(&counter)
new := old + 1
swapped := atomic.CompareAndSwapInt64(&counter, old, new)

Atomic vs Mutex:

Atomic use cases:

• Counters
• Flags
• Pointers
• Lock-free data structures

Mutex vs Channel Comparison

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// Mutex usage
var mu sync.Mutex
var data int

func setValue(v int) {
    mu.Lock()
    data = v
    mu.Unlock()
}

// Channel usage
ch := make(chan int, 1)

func setValue(v int) {
    ch <- v
}

When to use mutex vs channel?

Rule of thumb:

• Mutex: protect shared state
• Channel: goroutine-to-goroutine communication
• Atomic: simple counters/flags

11. Advanced Channel Patterns

Pipeline Pattern

Pipelines pass data through multiple stages.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

func pipeline() {
    // Stage 1: Generate
    numbers := make(chan int)
    go func() {
        defer close(numbers)
        for i := 0; i < 10; i++ {
            numbers <- i
        }
    }()
    
    // Stage 2: Square
    squares := make(chan int)
    go func() {
        defer close(squares)
        for n := range numbers {
            squares <- n * n
        }
    }()
    
    // Stage 3: Print
    for s := range squares {
        fmt.Println(s)
    }
}

Pipeline benefits:

• Modular structure
• Parallel processing
• Backpressure handling

Cancellation Pattern

Cancellation pattern with context:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

func worker(ctx context.Context, jobs <-chan Job) error {
    for {
        select {
        case job, ok := <-jobs:
            if !ok {
                return nil
            }
            if err := process(ctx, job); err != nil {
                return err
            }
        case <-ctx.Done():
            return ctx.Err()
        }
    }
}

func process(ctx context.Context, job Job) error {
    // Sub-operations should also take the context
    return subprocess(ctx, job)
}

Error Handling Pattern

Error channel pattern:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

type Result struct {
    Value int
    Error error
}

func processWithError(jobs <-chan Job) <-chan Result {
    results := make(chan Result)
    go func() {
        defer close(results)
        for job := range jobs {
            value, err := doWork(job)
            results <- Result{Value: value, Error: err}
        }
    }()
    return results
}

Timeout Pattern

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

func withTimeout(fn func(), timeout time.Duration) error {
    done := make(chan struct{})
    go func() {
        fn()
        close(done)
    }()
    
    select {
    case <-done:
        return nil
    case <-time.After(timeout):
        return errors.New("timeout")
    }
}

12. Anti-Patterns and Common Mistakes

❌ Goroutine leak examples

Leak 1: Unbuffered Channel

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

func leakyFunction() {
    ch := make(chan int)  // Unbuffered
    
    go func() {
        // This goroutine blocks forever!
        val := <-ch  // Leak!
    }()
    
    // Nothing is ever sent to ch
    // Goroutine leak!
}

Fix:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

func fixedFunction() {
    ch := make(chan int)
    
    go func() {
        val := <-ch
        fmt.Println(val)
    }()
    
    ch <- 42  // Send
    close(ch) // Close
}

Leak 2: Range Loop Variable Capture

1
2
3
4
5
6
7

func leakyLoop() {
    for i := 0; i < 10; i++ {
        go func() {
            fmt.Println(i)  // ❌ Prints 10 every time!
        }()
    }
}

Fix:

1
2
3
4
5
6
7
8

func fixedLoop() {
    for i := 0; i < 10; i++ {
        i := i  // Shadow variable
        go func() {
            fmt.Println(i)  // ✅ Correct value
        }()
    }
}

Leak 3: Defer in Goroutine

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

func leakyDefer() {
    ch := make(chan int)
    
    go func() {
        defer close(ch)  // ❌ Won't run until the goroutine returns
        ch <- 42
    }()
    
    // main exits before the goroutine finishes
}

Fix:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

func fixedDefer() {
    ch := make(chan int)
    var wg sync.WaitGroup
    
    wg.Add(1)
    go func() {
        defer wg.Done()
        defer close(ch)
        ch <- 42
    }()
    
    wg.Wait()  // Wait for the goroutine to finish
}

❌ Deadlock scenarios

Deadlock 1: Mutual Blocking

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

func deadlockExample() {
    ch1, ch2 := make(chan int), make(chan int)
    
    go func() {
        ch1 <- 1
        <-ch2  // Blocks
    }()
    
    go func() {
        ch2 <- 2
        <-ch1  // Blocks
    }()
    
    // Deadlock!
}

Deadlock 2: Lock Ordering

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

var mu1, mu2 sync.Mutex

func deadlockLock() {
    go func() {
        mu1.Lock()
        mu2.Lock()  // Waits
        // ...
    }()
    
    go func() {
        mu2.Lock()
        mu1.Lock()  // Waits
        // ...
    }()
    
    // Deadlock!
}

Fix: lock ordering

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// Always lock in the same order
func fixedLock() {
    go func() {
        mu1.Lock()
        mu2.Lock()
        // ...
        mu2.Unlock()
        mu1.Unlock()
    }()
    
    go func() {
        mu1.Lock()  // Same order
        mu2.Lock()
        // ...
        mu2.Unlock()
        mu1.Unlock()
    }()
}

❌ Context propagation mistakes

1
2
3
4
5
6
7
8
9

// ❌ Wrong: doesn't pass context
func handleRequest(req *Request) {
    go process(req)  // No context!
}

// ✅ Correct: pass context
func handleRequest(ctx context.Context, req *Request) {
    go process(ctx, req)  // Context passed
}

✅ Correct approaches

1. Close channels when appropriate
2. Propagate context into all sub-operations
3. Use WaitGroup to wait for goroutines to finish
4. Add timeouts with select
5. Use the race detector: go run -race

🔧 Production Note:

Goroutine leaks and deadlocks are among the most common issues in production. Closing all channels, propagating context, and adding timeouts is critical. Add the race detector to your CI/CD pipeline, but don’t run it in production as it has ~10x performance overhead.

13. Practical Examples and Best Practices

Example 1: Worker Pool Pattern

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

package main

import (
    "fmt"
    "sync"
)

type Job struct {
    ID int
}

type Result struct {
    JobID int
    Output string
}

func worker(id int, jobs <-chan Job, results chan<- Result, wg *sync.WaitGroup) {
    defer wg.Done()
    for job := range jobs {
        // Process the job
        result := Result{
            JobID:  job.ID,
            Output: fmt.Sprintf("Job %d processed by worker %d", job.ID, id),
        }
        results <- result
    }
}

func main() {
    const numWorkers = 5
    const numJobs = 100
    
    jobs := make(chan Job, numJobs)
    results := make(chan Result, numJobs)
    
    var wg sync.WaitGroup
    
    // Start workers
    for w := 1; w <= numWorkers; w++ {
        wg.Add(1)
        go worker(w, jobs, results, &wg)
    }
    
    // Send jobs
    for j := 1; j <= numJobs; j++ {
        jobs <- Job{ID: j}
    }
    close(jobs)
    
    // Collect results
    go func() {
        wg.Wait()
        close(results)
    }()
    
    // Print results
    for result := range results {
        fmt.Println(result.Output)
    }
}

Example 2: Rate Limiting

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

package main

import (
    "context"
    "fmt"
    "golang.org/x/time/rate"
    "time"
)

func main() {
    limiter := rate.NewLimiter(rate.Every(time.Second), 5) // 5 req/s
    
    for i := 0; i < 20; i++ {
        if err := limiter.Wait(context.Background()); err != nil {
            panic(err)
        }
        fmt.Printf("Request %d\n", i+1)
    }
}

Example 3: Timeout with Context

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package main

import (
    "context"
    "fmt"
    "time"
)

func longRunningTask(ctx context.Context) error {
    select {
    case <-time.After(5 * time.Second):
        fmt.Println("Task completed")
        return nil
    case <-ctx.Done():
        fmt.Println("Task cancelled:", ctx.Err())
        return ctx.Err()
    }
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()
    
    if err := longRunningTask(ctx); err != nil {
        fmt.Println("Error:", err)
    }
}

Best Practices

1. Don’t forget to close channels: the producer should close the channel (when appropriate)
2. Use context: for timeouts and cancellation
3. Use sync.Pool: for frequently allocated objects
4. Avoid goroutine leaks: make sure goroutines can always exit
5. Check race conditions: test with go run -race
6. Memory profiling: monitor and profile memory usage in production
7. GC tuning: tune GOGC for your workload

14. Debugging and Profiling (Extended)

Race Detector

1
2

go run -race main.go
go test -race ./...

Detects race conditions, but has significant overhead (~10x slowdown).

Race detector characteristics:

• Tracks all goroutines
• Logs memory accesses
• Reports races
• Should be used in development/testing only

Memory Profiling

1
2
3
4
5
6
7
8

import _ "net/http/pprof"

func main() {
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()
    // ... application code
}

1
2
3
4
5
6
7
8

# Collect heap profile
go tool pprof http://localhost:6060/debug/pprof/heap

# Profile commands
(pprof) top10          # Top 10 memory consumers
(pprof) list function  # Function details
(pprof) web            # Visual graph
(pprof) png            # Save as PNG

🔧 Production Note:

When profiling in production, you can collect profiles at runtime using net/http/pprof. However, remember that CPU profiling has overhead. Keep the profiling duration short (10-30 seconds) and only enable it when needed. Memory profiling has less overhead and can be used more frequently.

Memory Profiling Metrics:

• alloc_space: Total allocation
• alloc_objects: Total allocated objects
• inuse_space: Current in-use bytes
• inuse_objects: Current in-use objects

🔧 Production Note:

When profiling in production, you can collect profiles at runtime using net/http/pprof. However, remember that CPU profiling has overhead. Keep the profiling duration short (10-30 seconds) and only enable it when needed. Memory profiling has less overhead and can be used more frequently.

CPU Profiling

1

go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

CPU profiling usage:

1
2
3

(pprof) top10          # Top 10 CPU consumers
(pprof) list function  # Function details
(pprof) web            # Flame graph

Goroutine Profiling

1

go tool pprof http://localhost:6060/debug/pprof/goroutine

Goroutine Profiling:

• Active goroutine count
• Goroutine stack trace’leri
• Blocking goroutine’ler

Trace Analysis

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13