The Secret Life of Go: Goroutine Leaks

The zombie worker and the goroutine leak

#Go #GoRoutine #Concurrency #MemoryLeak

Eleanor is a senior software engineer. Ethan is her junior colleague. They work in a beautiful beaux arts library in Lower Manhattan — the kind of place where coding languages are discussed like poetry.

Episode 41

The library was quiet, save for the steady, low-frequency hum of the building’s HVAC system. Ethan was slumped in his chair, staring at a Grafana dashboard that looked like a slow-moving tide.

"It's not a spike this time, Eleanor," Ethan said, pointing to the memory usage graph. "It’s a slope. A perfect, forty-five-degree angle upward. I checked for slice leaks, I checked for open files, I even audited my defer calls. Everything is clean, but every hour, the service loses another fifty megabytes."

Eleanor set down a heavy folio of blueprinted maps. She walked over, her eyes moving not to the memory graph, but to the thread count. "The ghost isn't in your data, Ethan. It’s in your workforce."

She tapped the screen where a number was steadily climbing: Active Goroutines: 4,200.

"You're running a background check for every incoming request, aren't you?" she asked.

"Yes," Ethan replied. "I launch a goroutine to fetch metadata from the legacy API. If it takes too long, the main request just moves on. It’s supposed to be fire-and-forget."

The Zombie Worker

Eleanor pulled a small ledger from the table and opened it to a page of checked-out books. "In Go, there is no such thing as 'fire-and-forget.' Every goroutine you launch is a living thing. If you start a worker and don't give them an exit strategy, they don't just vanish when you're done with them. They sit there, blocked, waiting for a signal that will never come."

She drew a simple diagram on a scrap of paper.

func HandleRequest(id string) {
    ch := make(chan Result)
    
    go func() {
        // This goroutine is launched to do work
        res := fetchMetadata(id) 
        ch <- res // The worker tries to send the result
    }()

    // The main function times out and returns
    return 
}

"Look at the worker," Eleanor said. "You’ve returned from HandleRequest, but that goroutine is still trying to send a result into ch. But because no one is listening to that channel anymore, the worker is stuck. Forever. It’s a zombie—occupying stack space and memory, waiting for a handoff that will never happen."

📌 The Architect's Rule: Never start a goroutine without knowing how it will stop.

Ethan watched the goroutine count tick up to 4,201. "So every request I've handled today has left a ghost behind."

"Exactly," Eleanor said. "To fix this, we need a 'tether.' We use the context package to tell the worker when their time is up."

She guided his hands as he refactored the code to include a timeout.

func HandleRequest(ctx context.Context, id string) {
    // Create a tether that snaps after 2 seconds
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel() 

    ch := make(chan Result, 1) // Buffer the channel to prevent blocking
    
    go func() {
        res := fetchMetadata(id)
        ch <- res
    }()

    select {
    case res := <-ch:
        render(res)
    case <-ctx.Done():
        // The tether snapped. The main function exits, 
        // but the buffer ensures the worker doesn't hang.
        log.Println("Timeout reached")
    }
}

"By using context and a buffered channel," Eleanor explained, "you’ve ensured the worker has an out. Even if the main request times out, the worker can drop its result into the buffer and exit gracefully. The ghost is laid to rest."

The Return of the Shelf Space

Ethan ran the service again. The memory graph spiked during heavy traffic, but as soon as the load dropped, the line leveled off and stayed there. The active goroutine count finally began to fluctuate naturally, breathing in and out instead of just expanding.

"A goroutine is a commitment," Ethan realized.

"Precisely," Eleanor said, returning to her blueprints. "In this library, an unreturned book is a lost resource. In Go, an unreturned goroutine is a leak in the foundation. Always make sure your workers know the way home."

Key Concepts

The Goroutine Leak
A goroutine leak occurs when a goroutine is started but is unable to terminate. This usually happens because it is blocked on a channel operation (send or receive) or a network call that has no timeout. Because goroutines are not garbage collected until they exit, these "zombies" will consume memory until the application crashes.

Context as a Tether
The context package is the standard way in Go to signal cancellation and timeouts across API boundaries and goroutines. It allows a parent function to signal to all its children that their work is no longer needed.

Channel Buffering as an Exit Strategy
In many "fire-and-forget" patterns, using a buffered channel of size 1 ensures that a worker goroutine can always complete its send operation and exit, even if the receiver has already stopped listening.

Aaron Rose is a software engineer and technology writer at tech-reader.blog.

Catch up on the latest explainer videos, podcasts, and industry discussions below.

Search This Blog

Tech-Reader.blog