Diskussion: Goroutinen, Channels und das sync-Package: Nebenläufigkeit in Go im Überblick

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

Three version-bound facts the outline touches without dating. The loop-variable change in Go 1.22 (for modules whose `go.mod` says `go 1.22` or later) gives every iteration of `for i := range n` and `for _, v := range items` its own variable, so the classic bug of `go func() { use(v) }()` inside a loop, where every goroutine saw the last element, no longer occurs; on older module versions it still does and the fix is the `v := v` copy. Since Go 1.25, on Linux the runtime sets `GOMAXPROCS` from the cgroup CPU bandwidth limit when that is lower than the number of logical CPUs, so a container limited to two CPUs no longer runs with the host's core count worth of Ps; before 1.25 this needed `GOMAXPROCS` set by hand or by a library. The 'never copy sync values' rule is checked by `go vet`'s `copylocks` analyzer, which reports a `sync.Mutex` or `sync.WaitGroup` passed or assigned by value, including a struct that contains one, so a value-receiver method on such a struct is caught before the race detector would have to find it.