Go · Advanced interview

Go multiplexes goroutines (G) onto OS threads (M) via logical processors (P), where P count defaults to GOMAXPROCS. Each P has a local run queue of goroutines an M executes; when a goroutine blocks on a syscall the M can detach and another M serves the P, and idle Ps steal work from others (work-stealing). This lets millions of goroutines run efficiently on a few threads, with cheap, fast context switches in user space.

Go uses a concurrent, tri-color mark-and-sweep collector optimized for low latency — it runs mostly alongside your program with very short stop-the-world pauses (sub-millisecond). It trades some throughput and a bit of CPU for predictable, short pauses, tuned via GOGC (and a soft memory limit). The practical implication is you reduce GC pressure by minimizing heap allocations rather than tuning the collector heavily.

At compile time Go decides whether a value can live on the stack (cheap, freed automatically) or must 'escape' to the heap (GC-managed). A value escapes if its lifetime outlives the function — e.g. returning a pointer to a local, or storing it somewhere reachable later. Understanding it helps you reduce heap allocations and GC pressure; go build -gcflags=-m shows escape decisions.

Fan-out starts multiple goroutines reading from the same input channel to process work in parallel; fan-in merges their results into one output channel. You connect stages by channels so each stage transforms and forwards, and use a WaitGroup to close the merged channel once all workers finish. Context cancellation threads through so the whole pipeline can stop early.

Start a fixed number of worker goroutines that range over a jobs channel and send to a results channel; close jobs when done and use a WaitGroup to know when to close results. You bound concurrency to avoid exhausting memory, file descriptors, or overwhelming a downstream dependency — unbounded goroutine spawning is a common cause of resource blowups under load. The pool size becomes a tunable backpressure knob.

for i := 0; i < n; i++ {
  go func() { for j := range jobs { results <- do(j) } }()
}

Listen for SIGTERM via signal.NotifyContext, then on shutdown call server.Shutdown(ctx) to stop accepting new connections and let in-flight requests finish within a timeout, cancel the root context so background goroutines selecting on ctx.Done() exit, and wait (WaitGroup) for them before exiting. This drains work cleanly so deploys are zero-downtime and nothing is abandoned mid-flight.

Import net/http/pprof (or use runtime/pprof) to capture CPU, heap, goroutine, block, and mutex profiles, then analyze with go tool pprof — viewing top functions, flame graphs, and allocation sources. You measure first to find the real hotspot, then optimize. CPU profiles find compute hotspots; heap profiles find allocation sources driving GC; goroutine/block profiles find concurrency stalls.

Reduce allocations by reusing buffers, preallocating slices with the right capacity, avoiding unnecessary interface boxing and string/[]byte conversions, and keeping values on the stack (escape analysis). sync.Pool reuses temporary objects across goroutines to cut allocation and GC pressure for short-lived, frequently-allocated objects (like buffers) — but it's not a cache and pooled items can be collected, so use it only for genuinely reusable throwaway objects.

The race detector (go test -race / go run -race) instruments memory accesses at runtime to detect when two goroutines access the same memory concurrently with at least one write and no synchronization. It catches data races that are otherwise intermittent and hard to reproduce. You run it in tests and CI; it slows execution and uses more memory, so it's a testing tool, not a production build flag.

Pass context.Context as the first argument through every layer — handlers, services, database calls — so cancellation and deadlines flow end to end and a client disconnect or timeout aborts the whole chain. Don't store context in structs or pass nil; derive child contexts with timeouts where appropriate. Proper propagation is what stops a server doing work for requests no one is waiting on.

A goroutine leaks when it blocks forever — sending/receiving on a channel no one services, or waiting without honoring cancellation — so it never exits and its memory is never reclaimed. Prevent it by always giving goroutines a way to stop (select on ctx.Done()), ensuring channels have receivers or are buffered/closed appropriately, and using timeouts. You detect leaks with the goroutine profile showing a steadily growing count.

Wrap errors with context as they propagate (%w) so the final message is a readable trail, but don't double-log — handle or log an error once, at the boundary. Use sentinel errors or typed errors for conditions callers branch on (via errors.Is/As), keep error messages lowercase and without trailing punctuation by convention, and decide at the top layer how to map errors to responses/retries. Consistency in wrapping and where you handle is what keeps it maintainable.