The invisible cleanup crew
You write a Go web server. Requests pour in. You unmarshal JSON into structs, slice up byte arrays, spawn goroutines to process tasks, and return responses. You never call a cleanup function. You never track reference counts. You never worry about double-frees. The memory usage stays flat. The server runs for months without crashing.
Go handles all of that behind the scenes. The runtime includes a concurrent, non-blocking garbage collector that scans your heap, identifies objects you no longer touch, and reclaims the space. You get automatic memory management without the stop-the-world pauses that older languages used to suffer. The tradeoff is that you need to understand how the collector decides what is alive and what is dead. Once you see the mechanics, you stop fighting the runtime and start writing code that plays nicely with it.
How Go tracks what you actually need
Go uses a tricolor marking algorithm. Think of it like a librarian scanning a room full of books. Every object starts as white, meaning unvisited and potentially dead. The collector picks a few roots, like global variables and stack frames, and marks them black. Those are definitely alive. When the collector follows a pointer from a black object to a white one, it turns the white object gray. Gray means discovered but not yet fully scanned. The collector then processes the gray queue, marking everything reachable as black. When the scan finishes, any white objects left behind are garbage. The sweeper phase reclaims them.
The tricky part is that your program keeps running while the collector scans. Your goroutines might move pointers around, create new objects, or drop references. If the collector misses a pointer change, it might accidentally collect a live object. Go solves this with write barriers. A write barrier is a tiny runtime hook that triggers whenever you assign a pointer. If you change a pointer during the mark phase, the barrier tells the collector to revisit the target object. This keeps the scan accurate without freezing your code.
Go also uses escape analysis at compile time. The compiler looks at every variable and decides whether it can live on the stack or must move to the heap. Stack allocation is fast and automatic. When a function returns, the stack frame pops and the memory vanishes. Heap allocation requires the garbage collector. The compiler moves a variable to the heap if it outlives the function call, if it is returned by pointer, or if it is captured by a closure. You do not control this decision directly. You write the code, and the compiler places the data where it belongs.
Escape analysis is a compiler optimization, not a guarantee. Trust the compiler. Argue logic, not placement.
A minimal allocation cycle
Here is the simplest heap allocation you can write. It creates a struct, lets it go out of scope, and shows how the runtime handles the lifecycle.
package main
import "fmt"
type Task struct {
ID int
Name string
}
func createTask(id int) *Task {
// Allocate on heap because we return a pointer
t := &Task{ID: id, Name: "init"}
return t
}
func main() {
// Compiler sees the pointer escapes to the caller
t := createTask(1)
fmt.Println(t.Name)
// t goes out of scope here
// The GC will eventually reclaim the heap block
}
The createTask function returns a pointer. The compiler knows the struct must survive past the function call, so it allocates it on the heap. When main finishes, t is no longer reachable. The next garbage collection cycle will mark it white, sweep it, and return the memory to the allocator. You do not see this happen instantly. The collector runs concurrently and reclaims memory when it decides it is time.
What happens under the hood
When your program starts, the runtime initializes a set of spans. A span is a contiguous block of heap memory, usually 8 kilobytes to 32 megabytes. The allocator divides spans into size classes. Tiny allocations under 16 bytes share a single span to reduce fragmentation. Small allocations get their own buckets. Large allocations over 32 kilobytes bypass the size classes and go straight to the system allocator.
When you call new or allocate a slice, the runtime checks the size. If it fits in a size class, it grabs a free slot from the appropriate span. If the span is full, the runtime asks the operating system for more memory and carves out a new span. This process is lock-free for tiny and small allocations, which is why Go can handle millions of allocations per second.
The garbage collector triggers when the heap grows past a threshold. The threshold is controlled by GOGC, which defaults to 100. That means the collector runs when the heap doubles since the last collection. You can lower it to reduce memory footprint or raise it to reduce CPU overhead. The collector runs in three phases: mark preparation, concurrent mark, and sweep. The mark phase uses the tricolor algorithm and write barriers. The sweep phase walks the spans, clears dead objects, and returns memory to the allocator. Pause times typically stay under one millisecond on modern hardware.
You can tune runtime behavior with GODEBUG or the //go:debug directive. These are debugging tools, not production knobs. The //go:debug directive lives at the top of a file or in go.mod and lets you flip runtime flags without environment variables. For example, //go:debug panicnil=1 restores the pre-Go 1.21 behavior where panic(nil) triggers a stack trace. Use these flags to isolate issues, then remove them. The runtime is tuned for general workloads. Override it only when you have measured data proving the default hurts your specific case.
GODEBUG is a scalpel, not a hammer. Measure first, tweak second.
Real-world allocation patterns
Production code rarely allocates single structs. You process batches, buffer streams, and reuse objects. Here is a realistic pattern that shows how allocation, reuse, and collection interact in a worker loop.
package main
import (
"context"
"fmt"
"sync"
)
// Worker processes items from a channel and reuses buffers
type Worker struct {
buf []byte
mu sync.Mutex
}
// NewWorker allocates a reusable buffer
func NewWorker(size int) *Worker {
// Pre-allocate to avoid repeated heap pressure
return &Worker{buf: make([]byte, size)}
}
// Process reuses the internal buffer for each item
func (w *Worker) Process(ctx context.Context, data []byte) error {
// Copy incoming data into the reusable buffer
n := copy(w.buf, data)
// Simulate work that might allocate
result := fmt.Sprintf("processed: %d bytes", n)
fmt.Println(result)
return nil
}
func main() {
ctx := context.Background()
w := NewWorker(1024)
// Reuse the same worker across many calls
w.Process(ctx, []byte("hello"))
w.Process(ctx, []byte("world"))
}
The worker holds a pre-allocated byte slice. Each call to Process reuses that slice instead of allocating a new one. This reduces heap pressure and gives the garbage collector less work. The context.Context parameter follows Go convention: it is always the first argument, named ctx, and signals cancellation. The receiver name w matches the type Worker. These are small details that keep code readable and idiomatic.
When you need to allocate many short-lived objects, consider batch patterns. The arena package (available as an experimental or third-party tool) lets you allocate a group of objects and free them all at once. This avoids per-object GC overhead. You call arena.NewArena(), allocate into it, and call arena.Free() when the batch is done. This pattern shines in parsers, game loops, and request handlers where objects share the same lifetime.
Arena allocation trades fine-grained control for bulk efficiency. Use it when objects die together.
When memory management bites back
Go makes memory easy, but it does not make it free. The most common mistake is holding references longer than necessary. A goroutine that captures a large slice, waits on a channel, and never exits will keep that slice alive forever. The collector cannot reclaim it because the goroutine's stack still points to it. The compiler will not warn you. The runtime will not panic. Your memory usage will climb until the process gets killed.
If you forget to close a channel and a goroutine blocks on it, you get a goroutine leak. The runtime logs nothing. The leak is silent. Always provide a cancellation path. Use context.WithCancel or a done channel. Check for context cancellation in long loops.
Another trap is large allocations. Objects over 32 kilobytes bypass the size-class allocator and go straight to the OS. They are not swept by the garbage collector in the same way. If you allocate many large buffers and drop them, the runtime may not return the memory to the OS immediately. You will see high RSS in top even though Go reports low heap usage. This is normal. The runtime keeps the memory for future allocations. If you truly need to release it, call runtime.GC() and runtime.GC() again, or rely on the OS to reclaim it when the process exits.
The compiler will catch type mismatches and unused imports, but it will not catch logical leaks. If you pass a *string to a function, the compiler accepts it, but you are paying for a pointer indirection for no reason. Strings are already cheap to pass by value. The compiler complains with cannot use x (type *string) as string value in argument if you mix them up. Fix the type, not the pointer.
Goroutine leaks are the worst memory bug. They never log, never panic, and never stop.
Choosing your allocation strategy
Use standard heap allocation when you need automatic cleanup and do not care about micro-optimizations. Use stack allocation when the compiler can prove the variable dies with the function call. Use sync.Pool when you allocate and discard the same type repeatedly in a hot loop. Use an arena or batch allocator when a group of objects shares the exact same lifetime and you want to free them in one call. Use large buffer reuse when you process streaming data and want to avoid repeated make calls. Use GODEBUG or //go:debug only when you are diagnosing a specific runtime behavior and have metrics to prove the default is wrong.
Pick the simplest thing that works. Optimize only when the profiler points to a bottleneck.