You Can Have a Goroutine Leak Without Having a Memory Leak

Your Go application’s memory usage looks completely normal.

Heap is stable.

RSS isn’t climbing.

GC looks healthy.

There is no obvious memory leak.

But the number of goroutines keeps increasing:

Goroutines

10,000
  ↓
20,000
  ↓
40,000
  ↓
80,000

Eventually the service becomes slower.

Maybe requests start timing out.

Maybe CPU increases.

Maybe scheduling overhead appears.

Maybe file descriptors or network resources become exhausted.

You investigate the heap.

Nothing.

That’s because a goroutine leak is not necessarily a memory leak.

A memory leak means memory that should no longer be needed remains reachable or otherwise unavailable for reclamation.

A goroutine leak means:

A goroutine that should have stopped is still running or blocked indefinitely.

The two problems can happen together.

But they don’t have to.

And understanding that distinction changes how you debug Go production systems.