Eric Campbell 6 min read Go

Go Memory Management: Stack vs Heap Allocation

Go abstracts away manual memory management, but that doesn't mean you should ignore where your data lives. Every variable in your program is allocated either on the stack or the heap, and this...

Key Insights

  • Go’s escape analysis automatically determines whether variables live on the stack or heap—understanding this mechanism helps you write more performant code without manual memory management
  • Stack allocation is orders of magnitude faster than heap allocation and creates zero garbage collection pressure, making it the preferred choice when possible
  • Using go build -gcflags='-m' to view escape analysis decisions and benchmarking with pprof are essential tools for identifying and fixing unnecessary heap allocations

Introduction to Memory Allocation in Go

Go abstracts away manual memory management, but that doesn’t mean you should ignore where your data lives. Every variable in your program is allocated either on the stack or the heap, and this decision has significant performance implications. The stack is fast, predictable, and self-cleaning. The heap is flexible but requires garbage collection, which can introduce latency spikes and memory overhead.

The Go compiler uses escape analysis to determine allocation locations automatically. When a variable’s lifetime is confined to a function’s scope, it lives on the stack. When it needs to outlive the function or when the compiler can’t prove its scope is limited, it “escapes” to the heap. Understanding this mechanism lets you write code that naturally favors stack allocation, resulting in faster programs with less GC pressure.

Stack Allocation Fundamentals

The stack is a LIFO (Last In, First Out) data structure where each goroutine gets its own stack, starting at 2KB and growing as needed. When you call a function, Go allocates a stack frame containing local variables, function parameters, and return values. When the function returns, the entire frame is reclaimed instantly—no garbage collector needed.

Stack allocation is incredibly fast because it’s just pointer arithmetic. The stack pointer moves down to allocate space and moves up to deallocate. There’s no need to search for free memory or track object lifetimes.

func calculateSum(a, b int) int {
    result := a + b  // stack allocated
    temp := result * 2  // also stack allocated
    return temp
}

func processData(count int) {
    var buffer [1024]byte  // stack allocated array
    total := 0  // stack allocated
    
    for i := 0; i < count; i++ {
        total += i
    }
    // All variables automatically cleaned up when function returns
}

In these examples, all variables are stack-allocated because they don’t escape the function scope. The compiler can prove they’re not needed after the function returns, so they live and die with the stack frame.

Heap Allocation Fundamentals

The heap is where dynamically allocated memory lives. Unlike the stack, heap memory persists beyond function boundaries and requires explicit tracking. Go’s garbage collector periodically scans heap memory to identify and reclaim objects that are no longer referenced.

Heap allocation happens when the compiler can’t prove a variable’s lifetime is limited to its declaring function. The most obvious case is returning a pointer to a local variable:

type User struct {
    Name  string
    Email string
    Age   int
}

func createUser(name string) *User {
    user := &User{Name: name}  // escapes to heap
    return user
}

func createUsers(count int) []*User {
    users := make([]*User, 0, count)  // slice header on stack, backing array on heap
    for i := 0; i < count; i++ {
        u := &User{Name: fmt.Sprintf("User%d", i)}  // each User escapes to heap
        users = append(users, u)
    }
    return users
}

The user variable in createUser must escape to the heap because we’re returning a pointer to it. If it stayed on the stack, the pointer would reference invalid memory after the function returns. The garbage collector manages its lifetime instead.

Escape Analysis in Action

The Go compiler’s escape analysis determines allocation locations at compile time. You can view these decisions using the -gcflags='-m' flag:

go build -gcflags='-m' main.go

Let’s examine different scenarios that cause variables to escape:

package main

import "fmt"

// Example 1: Pointer return causes escape
func newInt() *int {
    x := 42  // escapes to heap
    return &x
}

// Example 2: Value return keeps it on stack
func newIntValue() int {
    x := 42  // stays on stack
    return x
}

// Example 3: Interface assignment causes escape
func printValue(v interface{}) {
    fmt.Println(v)
}

func testInterface() {
    x := 100  // escapes to heap due to interface conversion
    printValue(x)
}

// Example 4: Slice assignment
func createSlice() []int {
    s := make([]int, 100)  // backing array escapes to heap
    return s
}

// Example 5: Closure capture
func makeCounter() func() int {
    count := 0  // escapes to heap (captured by closure)
    return func() int {
        count++
        return count
    }
}

// Example 6: Large local variable
func processLargeData() {
    var data [1024 * 1024]byte  // likely escapes due to size
    _ = data
}

Running escape analysis on this code reveals:

./main.go:6:2: x escapes to heap
./main.go:17:2: x escapes to heap
./main.go:22:11: make([]int, 100) escapes to heap
./main.go:27:2: count escapes to heap
./main.go:35:6: data escapes to heap

Performance Implications

The performance difference between stack and heap allocation is substantial. Let’s measure it:

package main

import "testing"

type Point struct {
    X, Y, Z float64
}

// Stack allocation version
func sumPointsStack(count int) float64 {
    sum := 0.0
    for i := 0; i < count; i++ {
        p := Point{X: 1.0, Y: 2.0, Z: 3.0}  // stack allocated
        sum += p.X + p.Y + p.Z
    }
    return sum
}

// Heap allocation version
func sumPointsHeap(count int) float64 {
    sum := 0.0
    for i := 0; i < count; i++ {
        p := &Point{X: 1.0, Y: 2.0, Z: 3.0}  // heap allocated
        sum += p.X + p.Y + p.Z
    }
    return sum
}

func BenchmarkStackAlloc(b *testing.B) {
    for i := 0; i < b.N; i++ {
        sumPointsStack(1000)
    }
}

func BenchmarkHeapAlloc(b *testing.B) {
    for i := 0; i < b.N; i++ {
        sumPointsHeap(1000)
    }
}

Running these benchmarks shows dramatic differences:

BenchmarkStackAlloc-8    500000    2847 ns/op    0 B/op    0 allocs/op
BenchmarkHeapAlloc-8      50000   38291 ns/op   24000 B/op  1000 allocs/op

The heap version is 13x slower and generates 24KB of garbage per operation. This garbage creates GC pressure, potentially causing pause times that affect application latency.

Optimization Strategies

Knowing the performance impact, here are practical strategies to minimize heap allocations:

Use value receivers when possible:

// Causes less heap allocation
func (p Point) Distance() float64 {
    return math.Sqrt(p.X*p.X + p.Y*p.Y + p.Z*p.Z)
}

// Use pointer receivers only when needed (large structs, mutations)
func (u *User) UpdateEmail(email string) {
    u.Email = email
}

Leverage sync.Pool for frequently allocated objects:

var bufferPool = sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer)
    },
}

func processRequest(data string) string {
    buf := bufferPool.Get().(*bytes.Buffer)
    defer bufferPool.Put(buf)
    buf.Reset()
    
    buf.WriteString(data)
    // ... process ...
    return buf.String()
}

Preallocate slices with known capacity:

// Bad: causes multiple allocations as slice grows
func buildList(count int) []int {
    var result []int
    for i := 0; i < count; i++ {
        result = append(result, i)
    }
    return result
}

// Good: single allocation
func buildListOptimized(count int) []int {
    result := make([]int, 0, count)
    for i := 0; i < count; i++ {
        result = append(result, i)
    }
    return result
}

Common Pitfalls and Best Practices

Don’t fall into premature optimization. Profile first, optimize second. Use pprof to identify actual allocation hotspots:

import _ "net/http/pprof"

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

Then analyze with: go tool pprof http://localhost:6060/debug/pprof/heap

Before optimization:

func processUsers(users []string) []*User {
    result := []*User{}
    for _, name := range users {
        u := &User{Name: name}  // heap allocation
        result = append(result, u)
    }
    return result
}

After optimization (when appropriate):

func processUsersOptimized(users []string) []User {
    result := make([]User, len(users))
    for i, name := range users {
        result[i] = User{Name: name}  // stack allocated, then copied
    }
    return result
}

This eliminates pointer indirection and heap allocations, but only do this when profiling shows it matters. The original version might be clearer and perfectly adequate for your use case.

Remember that Go’s escape analysis is conservative. It will choose heap allocation when it can’t prove stack safety. Sometimes accepting heap allocation is the right choice—especially when it makes code clearer or when the allocation isn’t in a hot path. Use escape analysis and profiling as tools to make informed decisions, not as mandates to eliminate every heap allocation.

Liked this? There's more.

Every week: one practical technique, explained simply, with code you can use immediately.