When concurrency slows you down
You built a Go service that handles API requests. It feels snappy during local testing. You deploy it, traffic hits, and suddenly latency spikes. The CPU graph looks like a heartbeat monitor during a panic. You added goroutines to speed things up, but the program is now slower than the sequential version. Concurrency didn't help. It hurt.
The issue is rarely the goroutines themselves. Goroutines are cheap. The problem is how they share state, how they allocate memory, and how they block each other. Optimization in concurrent Go means reducing contention, cutting allocation pressure, and ensuring goroutines spend their time doing work instead of waiting.
The kitchen analogy
Concurrency is like a busy kitchen. Goroutines are chefs. CPU cores are burners. If you have ten chefs but only one stove, they spend all their time bumping into each other. If they all need the same knife at the same time, they stop cooking and wait. If every chef throws away a cutting board after one chop, the trash can overflows and the kitchen grinds to a halt.
Optimization means giving chefs their own knives, making sure they don't block the pass, and reusing equipment so the dishwasher doesn't become the bottleneck. In Go, knives are locks, the pass is channels, and the cutting boards are heap allocations.
Shared state and lock contention
When multiple goroutines update the same variable, you need synchronization. The most common tool is sync.Mutex. A mutex ensures only one goroutine accesses the critical section at a time. This prevents data races, but it introduces contention. If many goroutines hit the same lock, they queue up. The CPU switches context, wasting cycles.
Here's a basic concurrent counter that works but creates contention under load.
package main
import (
"fmt"
"sync"
)
// Counter tracks a value with mutual exclusion.
type Counter struct {
mu sync.Mutex
val int
}
// Increment updates the counter safely.
func (c *Counter) Increment() {
c.mu.Lock()
defer c.mu.Unlock()
c.val++
}
func main() {
var wg sync.WaitGroup
c := &Counter{}
for i := 0; i < 100; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for j := 0; j < 1000; j++ {
c.Increment()
}
}()
}
wg.Wait()
fmt.Println(c.val)
}
The mutex serializes access. Only one goroutine holds the lock. Others wait. On a multi-core machine, this looks like a bottleneck. The runtime puts waiting goroutines to sleep and wakes them when the lock is released. Context switching adds overhead. If the critical section is large, the program spends more time managing the lock than doing work.
Locks are expensive. Keep the critical section small.
False sharing and cache lines
There's a hidden cost even when locks are fast. Modern CPUs use cache lines, typically 64 bytes. When a core modifies a variable, it invalidates the cache line on other cores. If two unrelated variables sit on the same cache line, and two different cores update them independently, the cores constantly invalidate each other's cache. This is false sharing.
False sharing makes concurrent code slow without any locks. The fix is padding. Place frequently written variables in separate cache lines by adding padding fields or using alignment. The atomic package helps here, but you still need to watch layout.
Convention aside: receiver names are usually one or two letters matching the type. Use (c *Counter) not (this *Counter) or (self *Counter). This keeps code compact and matches the standard library style.
Reusing objects with sync.Pool
Allocating memory is not free. Every allocation requires the runtime to find space, update bookkeeping, and eventually run the garbage collector. High allocation rates increase GC pressure. GC pauses stop all goroutines briefly. In a latency-sensitive service, those pauses add up.
sync.Pool lets you reuse objects. You store temporary objects in the pool after use. Other goroutines grab them from the pool instead of allocating fresh ones. This cuts down on heap traffic and reduces GC work.
Here's how to reuse buffers to cut down on allocations and garbage collection pauses.
package main
import (
"fmt"
"sync"
)
// Buffer holds reusable data.
type Buffer struct {
data []byte
}
// pool caches buffers to avoid allocation.
var pool = sync.Pool{
New: func() any {
return &Buffer{
data: make([]byte, 1024),
}
},
}
func process() {
buf := pool.Get().(*Buffer)
defer pool.Put(buf)
copy(buf.data, []byte("work"))
fmt.Println(buf.data[:4])
}
func main() {
for i := 0; i < 5; i++ {
process()
}
}
The New function runs only when the pool is empty. Get checks the pool first. If an item is available, it returns it instantly. If not, it calls New. Put returns the item for reuse. The pool is per-processor, so access is fast and contention-free in most cases.
Pools reduce allocation pressure. They do not replace design.
Pool behavior and GC
sync.Pool is not a permanent cache. Items can be discarded at any time, especially during garbage collection. The runtime clears the pool between GC cycles to prevent memory leaks. This means Get might call New even if you just put an item back. Design your code to handle this. The New function should always produce a valid object.
Convention aside: context.Context always goes as the first parameter, conventionally named ctx. Functions that take a context should respect cancellation and deadlines. Context is plumbing. Run it through every long-lived call site. If a request cancels, stop work early. Stopping work saves resources and reduces contention.
Pitfalls and runtime errors
Concurrency bugs are subtle. A program can pass tests and fail in production under load. The worst goroutine bug is the one that never logs.
Deadlocks happen when goroutines wait for each other in a cycle. If a goroutine holds a lock and tries to acquire it again, or if two goroutines hold locks A and B while waiting for B and A, progress stops. The runtime detects this and panics with fatal error: all goroutines are asleep - deadlock!. This error means no goroutine can make progress. Check lock ordering and avoid holding locks across blocking calls.
Goroutine leaks happen when a goroutine waits on a channel that never gets closed. If you spawn a goroutine to read from a channel, and the sender stops sending without closing the channel, the receiver blocks forever. The goroutine stays in memory. Over time, the program consumes resources and slows down. Always have a cancellation path. Use context or close channels when done.
If you forget to capture a loop variable correctly, the compiler rejects the program with loop variable i captured by func literal in Go 1.22+. Earlier versions allowed this, leading to bugs where all goroutines shared the final value of the loop variable. Capture the variable by passing it as an argument or assigning it to a new variable inside the loop.
Convention aside: if err != nil { return err } is verbose by design. The community accepts the boilerplate because it makes the unhappy path visible. Don't hide errors. Handle them explicitly.
Decision matrix
Pick the right tool for the job. Concurrency primitives solve specific problems. Using the wrong one adds complexity without benefit.
Use a mutex when multiple goroutines must update shared state atomically and the critical section is tiny.
Use sync.Pool when you allocate and discard the same object type repeatedly in a hot path.
Use a channel when goroutines need to coordinate data flow or signal completion.
Use sync.Map when you have high read concurrency with few writes to a map.
Use atomic operations when you need lock-free counters or flags and the logic is a single variable update.
Use sequential code when the overhead of concurrency exceeds the benefit of parallelism.
Profile before you optimize. Guessing is just slower code with more bugs.