What are common sources of memory leaks in Go services?

Question

Accepted Answer

Goroutine leaks: blocked goroutines hold their stack and all referenced heap objects alive forever Unbounded global maps or caches that only grow — add a size limit or TTL eviction time.After inside loops: each call creates a new channel and timer that leaks until it fires Unclosed HTTP response bodies: resp.Body.Close() must be called even when not reading the body Sub-slice keeping large array alive: a small slice of a large array prevents the whole array from being GC'd CGo retained pointers: C code holding Go pointers prevents GC collection // LEAK: time.After in loop
for {
    select {
    case <-time.After(1 * time.Second): // creates new timer every iteration
        doWork()
    }
}
// FIX: use time.NewTimer and reset
timer := time.NewTimer(1 * time.Second)
defer timer.Stop()
for {
    select {
    case <-timer.C:
        doWork()
        timer.Reset(1 * time.Second)
    }
}

// LEAK: sub-slice holding large array
func getLargeData() []byte {
    large := make([]byte, 10*1024*1024) // 10MB
    // ... fill large
    return large[:100] // 10MB array stays alive!
}
// FIX: copy the relevant portion
func getLargeData() []byte {
    large := make([]byte, 10*1024*1024)
    result := make([]byte, 100)
    copy(result, large[:100])
    return result // large is now eligible for GC
}

// LEAK: unclosed response body
resp, _ := http.Get(url)
// ... forgot resp.Body.Close()
// FIX:
defer resp.Body.Close()

What are common sources of memory leaks in Go services?

The most common memory leaks in Go are goroutine leaks, unbounded caches, unclosed HTTP response bodies, and keeping references to large backing arrays via sub-slices.

What are common sources of memory leaks in Go services?

The most common memory leaks in Go are goroutine leaks, unbounded caches, unclosed HTTP response bodies, and keeping references to large backing arrays via sub-slices.

Scenario Questions

Follow-up Questions