Chapter 3: Pointers & Memory

Understanding how Go manages memory helps you write more efficient code and avoid common pitfalls. Let’s explore pointers, stack vs heap allocation, and escape analysis.

Go manages memory automatically through garbage collection, but understanding pointers and memory allocation helps you write efficient code. Unlike C, Go pointers are safe - no pointer arithmetic, no manual memory management. But unlike high-level languages that hide pointers entirely, Go gives you control when you need it.

This chapter covers pointer fundamentals, when to use pointers vs values, stack vs heap allocation, and escape analysis. You’ll learn how Go decides where to allocate memory and how to write code that works with the runtime rather than against it.

Pointer Basics

Understanding Pointers

A pointer holds the memory address of a value. Use & to get an address and * to dereference it. Pointers let you share data without copying and modify values across function boundaries.

Go pointers are restricted for safety: no pointer arithmetic, no casting arbitrary addresses to pointers. This prevents entire categories of bugs common in C. You get the benefits of pointers without the danger.

When to Use Pointers

Use pointers when you need to:

Modify a value passed to a function
Avoid copying large structs
Share data between goroutines
Signal optional values (nil pointer)

Stack vs Heap

Go automatically decides where to allocate memory:

Stack: Fast, automatic cleanup, limited size
Heap: Slower, garbage collected, unlimited size

Escape Analysis

Escape analysis is the compiler pass that decides whether a value can live on the stack or must be heap-allocated. The rule is easy to state - a value escapes if the compiler cannot prove that nothing references it after the function returns - but the answer for any particular line depends on inlining and on the call site. That makes it very easy to guess wrong, so this section shows the compiler’s real verdict rather than intuition.

Escape analysis is a compiler pass, so you cannot observe it in the browser sandbox. Copy the program above into a local main.go and run:

go build -gcflags=-m ./...

Real output from Go 1.24.7:

./main.go:13:6: can inline NewUser
./main.go:20:6: can inline ProcessUser
./main.go:26:20: inlining call to NewUser
./main.go:27:16: inlining call to fmt.Println
./main.go:29:28: inlining call to ProcessUser
./main.go:30:16: inlining call to fmt.Println
./main.go:13:14: leaking param: name
./main.go:13:20: leaking param: email
./main.go:14:12: &User{...} escapes to heap
./main.go:20:18: leaking param: name
./main.go:20:24: leaking param: email
./main.go:22:23: ... argument does not escape
./main.go:22:39: u.Name escapes to heap
./main.go:26:20: &User{...} does not escape
./main.go:27:16: ... argument does not escape
./main.go:27:21: user.Name escapes to heap
./main.go:29:28: ... argument does not escape
./main.go:29:28: u.Name escapes to heap
./main.go:30:16: ... argument does not escape
./main.go:30:17: greeting escapes to heap

(Line numbers refer to the program above, starting at package main on line 1.)

Read the output above against the two obvious guesses, both of which are wrong:

“NewUser heap-allocates.” ./main.go:14:12: &User{...} escapes to heap is the verdict for NewUser compiled as a standalone function. The line that matters is the one at the call site: ./main.go:26:20: &User{...} does not escape, because NewUser was inlined there (./main.go:26:20: inlining call to NewUser). The User for “Alice” lives on main’s stack frame.
“ProcessUser is the stack-friendly one.” It is the function that actually heap-allocates: ./main.go:22:39: u.Name escapes to heap, because passing a string to fmt.Sprintf boxes it into an any argument.

Escape analysis is call-site and inlining dependent. The same function can allocate in one caller and not in another, and the answer changes as the inlining budget changes between releases. Run go build -gcflags='-m -m' ./... to see the flow that produced each decision, and confirm it matters with go test -bench=. -benchmem before you restructure code for it.

Nil Pointers

Always check for nil before dereferencing:

Struct Layout and Memory

Field order in structs affects memory usage due to alignment:

Slices and Memory

Slices are already reference types - they contain a pointer to the underlying array:

Key Takeaways

Use pointers to modify - pass by pointer when the function needs to change the value
Use pointers for large structs - avoid copying overhead
Escape analysis - the compiler decides stack vs heap allocation, per call site and after inlining; read -gcflags=-m instead of guessing
Check for nil - always validate pointers before use
Order struct fields - largest to smallest minimizes padding
Slices are references - they already point to underlying data

Exercise

Optimize Struct Memory

easy

Given a struct with poor memory layout, reorder its fields to minimize size. Print both the original and optimized struct sizes using unsafe.Sizeof.

Practice

Pointer and allocation decisions show up everywhere once shared state is involved. These batteries exercise them directly:

Concurrency Exercises - sharing pointers across goroutines safely (start with 1. Goroutine Counter)
Generics Exercises - 2. Generic Data Structures is a hands-on tour of value vs pointer storage
Testing Exercises - where go test -benchmem turns the guesses in this chapter into numbers

Next up: Chapter 4: Goroutines & Channels