How to wait for goroutines to finish in Go

1Why a bare go f() prints nothing

Start with the bug. This program launches three goroutines and then falls off the end of main. There is no join, no Wait, nothing that makes main pause — so the runtime tears the process down while the workers are still queued. The Go spec is explicit about it: when the main function returns, the program exits; it does not wait for other goroutines to complete.

package main

import "fmt"

func work(id int) {
	fmt.Println("worker", id, "finished")
}

func main() {
	fmt.Println("main: starting 3 workers")
	for i := 1; i <= 3; i++ {
		go work(i)
	}
	// main returns here, so the process exits immediately.
}

The only line printed is main: starting 3 workers. Not one worker gets to run. Note what this program is not: it is not deterministic by contract. Nothing stops a worker from sneaking a line out before the process dies — it just almost never wins the race, which is precisely what makes the bug so nasty in production. The cure is never time.Sleep; it is to make the waiting explicit.

2sync.WaitGroup — Add, Done, WaitRecommended

A sync.WaitGroup is a counter guarded by the runtime. Add(n) raises it, Done() lowers it by one, and Wait() blocks until it hits zero. Three rules make it safe: call Add in the parent, before the go statement — never inside the goroutine, or Wait can return before the goroutine has even registered; always defer wg.Done() as the first statement, so it fires on every return path and on a panic; and pass the WaitGroup by pointer if it crosses a function boundary — copying one breaks it silently.

package main

import (
	"fmt"
	"sync"
)

func fetch(path string) string {
	return "200 OK " + path
}

func main() {
	paths := []string{"/home", "/about", "/pricing"}

	var wg sync.WaitGroup
	statuses := make([]string, len(paths))

	for i, p := range paths {
		wg.Add(1) // 1. count the goroutine BEFORE you start it
		go func(i int, p string) {
			defer wg.Done() // 2. always release the count, even on panic
			statuses[i] = fetch(p)
		}(i, p)
	}

	fmt.Println("main: waiting for", len(paths), "goroutines")
	wg.Wait() // 3. block until the counter is back to zero

	for _, s := range statuses {
		fmt.Println(s)
	}
}

Prints main: waiting for 3 goroutines and then 200 OK /home, 200 OK /about, 200 OK /pricing — in that order, every run, because the printing happens in main after Wait. The loop variables are handed to the closure as arguments (i, p) rather than captured. Go 1.22 made each iteration get its own copy, so capturing is fine on modern toolchains, but passing explicitly is unambiguous and behaves the same on every Go version and interpreter. Go 1.25 also added wg.Go(func(){…}), which folds Add and Done into one call; the engine behind this page runs an older Go, so the snippets here use the classic form.

3Collecting results without a data race

The natural next question is how to get values out. The wrong answers are famous: append to a shared slice (two goroutines can grab the same index and one write is lost) or write into a shared map (Go detects that and kills the program with fatal error: concurrent map writes). The right answer needs no lock at all — pre-size a slice to len(input) and give each goroutine one index it alone owns. Distinct elements of a slice are distinct memory, so the writes cannot collide, and Wait establishes the happens-before edge that makes it legal to read them afterwards.

package main

import (
	"fmt"
	"strings"
	"sync"
)

type result struct {
	word  string
	upper string
	n     int
}

func main() {
	words := []string{"go", "concurrency", "waitgroup", "channel"}

	results := make([]result, len(words)) // one slot per goroutine
	var wg sync.WaitGroup

	for i, w := range words {
		wg.Add(1)
		go func(i int, w string) {
			defer wg.Done()
			// This goroutine owns results[i] and nothing else, so the
			// slots never overlap and no lock is needed.
			results[i] = result{word: w, upper: strings.ToUpper(w), n: len(w)}
		}(i, w)
	}

	wg.Wait() // every write above happens-before Wait returns

	total := 0
	for _, r := range results {
		fmt.Printf("%-12s %-12s %d\n", r.word, r.upper, r.n)
		total += r.n
	}
	fmt.Println("total letters:", total)
}

The rows come out in input order — go, concurrency, waitgroup, channel — followed by total letters: 29, no matter which goroutine actually ran first. That ordering is free: it comes from the index, not from the scheduler. Run this with go run -race results.go locally and it stays silent; swap the indexed write for results = append(results, …) and the race detector lights up immediately.

4Shared counters: sync.Mutex and atomic

Sometimes the goroutines really do share one accumulator — a tally, a running total, a cache. Then a WaitGroup is not enough: it tells you when everyone finished, not that their writes were safe. Wrap the shared state in a sync.Mutex and take the lock around every read and write. If the shared state is a single integer, skip the mutex and use sync/atomic — atomic.Int64 is lock-free and its Add / Load methods cannot be used incorrectly the way a bare int64 can.

package main

import (
	"fmt"
	"sort"
	"sync"
	"sync/atomic"
)

// tally guards its map with a mutex, so many goroutines can update it.
type tally struct {
	mu sync.Mutex
	n  map[string]int
}

func (t *tally) add(key string, delta int) {
	t.mu.Lock()
	defer t.mu.Unlock()
	t.n[key] += delta
}

func main() {
	t := &tally{n: make(map[string]int)}
	var calls atomic.Int64 // a plain counter needs no mutex

	var wg sync.WaitGroup
	for i := 1; i <= 100; i++ {
		wg.Add(1)
		go func(i int) {
			defer wg.Done()
			calls.Add(1)
			if i%2 == 0 {
				t.add("even", i)
			} else {
				t.add("odd", i)
			}
		}(i)
	}
	wg.Wait()

	// Ranging a map is unordered -- sort the keys to get stable output.
	keys := make([]string, 0, len(t.n))
	for k := range t.n {
		keys = append(keys, k)
	}
	sort.Strings(keys)
	for _, k := range keys {
		fmt.Println(k, "sum:", t.n[k])
	}
	fmt.Println("goroutines that ran:", calls.Load())
}

One hundred goroutines, and the sums are exact every time: even sum: 2550, odd sum: 2500, goroutines that ran: 100. Two details are doing real work here. The mutex lives inside the struct it protects, which is why t is a pointer — copying a sync.Mutex copies its lock state and is a bug (go vet catches it). And the map keys are sorted before printing: map iteration order is deliberately randomised in Go, so ranging t.n directly would shuffle the output between runs even though the numbers are correct.

5Waiting with a channel instead

A channel can do the waiting too, and it carries the results at the same time. The idiom is fan-in: every worker sends on one channel, a small closer goroutine does wg.Wait() and then close(out), and the consumer ranges until the channel is closed and drained. The closer belongs in its own goroutine: if you call wg.Wait() on the main goroutine before you start ranging, then any time the channel can fill up — it is unbuffered, or its buffer is smaller than the number of sends — the workers block on the send while you block on Wait, and nothing can ever drain it. That is a deadlock, and Go will kill the program with all goroutines are asleep. Buffering to len(jobs) below dodges that specific case, but the closer goroutine is the shape that keeps working when you don't know the result count up front.

package main

import (
	"fmt"
	"sort"
	"sync"
)

func main() {
	jobs := []int{5, 2, 9, 4}

	// Buffered to len(jobs), so no worker ever blocks on the send.
	out := make(chan string, len(jobs))

	var wg sync.WaitGroup
	for _, n := range jobs {
		wg.Add(1)
		go func(n int) {
			defer wg.Done()
			out <- fmt.Sprintf("%d squared is %d", n, n*n)
		}(n)
	}

	// A closer goroutine does the waiting; closing is what ends the range.
	go func() {
		wg.Wait()
		close(out)
	}()

	var lines []string
	for line := range out { // stops when out is closed and drained
		lines = append(lines, line)
	}

	sort.Strings(lines) // arrival order is undefined -- sort for reproducibility
	for _, line := range lines {
		fmt.Println(line)
	}
}

Prints 2 squared is 4, 4 squared is 16, 5 squared is 25, 9 squared is 81. That order comes from sort.Strings (see sorting a slice in Go), not from the goroutines — the arrival order on a channel is whatever the scheduler decides, so any program that prints as values arrive has output that changes between runs. If you need input order back, use the indexed-slice pattern from section 3 instead; if you genuinely want streaming, sort or key the results at the end.

6Which should you use?

7Getting errors out of goroutines

A goroutine cannot return anything — go f() discards the result — so an error has to be written somewhere the caller can read after Wait. The same one-slot-per-goroutine trick works: an []error sized to the input, then errors.Join to collapse it. Join drops the nils, returns nil if they were all nil, keeps input order, and the joined error still answers errors.Is and errors.As for each wrapped cause.

package main

import (
	"errors"
	"fmt"
	"sync"
)

func check(service string) error {
	if service == "db" {
		return errors.New("connection refused")
	}
	return nil
}

func main() {
	services := []string{"cache", "db", "queue"}

	errs := make([]error, len(services)) // one slot each -- no lock needed
	var wg sync.WaitGroup

	for i, s := range services {
		wg.Add(1)
		go func(i int, s string) {
			defer wg.Done()
			if err := check(s); err != nil {
				errs[i] = fmt.Errorf("%s: %w", s, err)
			}
		}(i, s)
	}
	wg.Wait()

	for i, s := range services {
		if errs[i] == nil {
			fmt.Println(s, "ok")
		}
	}

	// errors.Join drops the nils and keeps the input order.
	if err := errors.Join(errs...); err != nil {
		fmt.Println("health check failed:")
		fmt.Println(err)
	}
}

Prints cache ok, queue ok, then health check failed: and db: connection refused — the %w verb wrapped the cause with the service name, so the joined message says which check failed. This is golang.org/x/sync/errgroup written by hand; the real package adds two things worth having in production — it returns only the first error, and its WithContext constructor cancels the remaining goroutines as soon as one fails. It is not in the standard library, so it cannot run on this page, but the shape above is what it does underneath. To cap how many run at once, add a buffered chan struct{} as a semaphore around the body.