Concurrency

It runs that call in a new goroutine and returns immediately, so the caller carries on without waiting. It is a statement, not an expression: it produces no value, no handle and no id you can hold on to.

A goroutine leak is a goroutine that never returns because it is blocked forever on an operation nobody will ever complete. The runtime cannot reclaim it, so its stack and everything it references stay alive until the process exits.

You cannot stop it from the outside. Pass the goroutine a stop signal it watches itself, either a context.Context or a done channel of type chan struct{}, and write the goroutine so it returns when that signal fires.

The whole process dies, not just that goroutine. The runtime prints the panic value and a stack trace and exits with status 2. Other goroutines are killed where they stand and their deferred functions never run.

Immediately, in the calling goroutine, at the go statement itself; only the call runs in the new goroutine. So go f(x) snapshots x on the spot, while go func(){ f(x) }() reads x later, whenever the goroutine happens to run.

A send on a channel made with make(chan int) blocks until another goroutine is ready to receive. With make(chan int, 3) the send returns immediately while the buffer holds fewer than three values, and blocks only once it is full.

A channel send copies the value. The receiver gets its own copy of the struct, so later writes by the sender are invisible. The copy is shallow: pointer, slice and map fields still refer to the same underlying data.

close(ch) marks a Go channel as finished. Receives stop blocking: they deliver any values still buffered, then return the element type's zero value with ok false, and a for range loop over the channel exits.

Both operations block forever. A send on a nil channel and a receive from a nil channel park the goroutine permanently, because no counterparty can ever exist. Closing a nil channel panics instead.

A default case makes the select non-blocking. If no other case can proceed at that instant, Go runs default immediately instead of waiting. Without a default, the select parks the goroutine until one of its cases is ready.

atomic.Int64.Add performs the read, the increment and the write as one indivisible step, so no update is lost. A plain hits++ is three separate steps and is a data race: the -race detector reports it and the total comes out too low.

sync.NewCond(l) builds a *sync.Cond over any sync.Locker, stored in its L field. Wait must be called with c.L already held: it atomically unlocks c.L and parks the goroutine, then re-locks c.L before returning to the caller.

A deferred unlock runs when the whole function returns, not when a block ends, so encoding, file or network work written after it still holds the mutex. Narrow it with an inner function or an early unlock.

sync.Map is a map in Go's sync package whose methods — Load, Store, LoadOrStore, Range — are safe to call from many goroutines with no lock of your own. A plain Go map is not: concurrent access with a writer is a data race.

A sync.Mutex zero value is already an unlocked, usable lock, so a plain declaration needs no constructor. Idiomatic use is mu.Lock() followed immediately by defer mu.Unlock(), which releases it on every return path, panics included.

context.Context carries a cancellation signal, an optional deadline and request-scoped values across API boundaries. Go has no goroutine-local storage, so it is threaded explicitly through every call, first in the parameter list and named ctx.

context.WithCancel(parent) returns a derived Context plus a cancel function. Calling cancel closes that context's Done channel and detaches it from its parent. Skipping the call leaves the child attached to a long-lived parent, so its memory is retained.

context.WithTimeout takes a duration and expires that far from now; context.WithDeadline takes an absolute time.Time and expires at that instant. WithTimeout is defined as WithDeadline with time.Now() plus the duration.

Only the calls you handed the context to. database/sql's QueryContext, http.NewRequestWithContext, net.Dialer.DialContext and exec.CommandContext abort. Anything with no ctx parameter, such as os.File.Read, io.Copy or time.Sleep, runs to completion.

Context values share one namespace across every package in a program. A key of an unexported type cannot be constructed or matched by any other package, so two libraries that both use the string "userID" cannot overwrite each other's value.

errgroup joins goroutines like sync.WaitGroup, but each task is a func() error. Group.Wait blocks until every task has returned and gives back the first non-nil error, and errgroup.WithContext also cancels the siblings when one task fails.

Start one forwarding goroutine per source that copies every value into a single shared output channel, and start one extra goroutine that waits for all forwarders to finish and then closes that output exactly once.

A stage owns the one channel it creates and sends on, so only it may close that channel, in a defer when its input runs dry. Returning that channel receive-only makes any downstream close or send a compile error.

Allow never blocks: it takes a token if one is free and returns true, otherwise false, so the caller must shed or retry. Wait blocks until a token is free, the context is cancelled, or its deadline passes.

A buffered channel of capacity N holds N permits. Sending an empty struct takes a permit and blocks once N are outstanding; a receive in a defer gives it back. At most N goroutines run the guarded work.

counter++ is a load, an add and a store, not one step. Two goroutines can load the same old value and store the same result, losing an update. Unsynchronized concurrent access with at least one writer is a data race.

An unbuffered channel holds nothing, so a send blocks until another goroutine is ready to receive. The only receive here is the next line of the same goroutine, which cannot run until the send finishes.

go test -race builds an instrumented test binary that watches memory accesses while the tests run. When two goroutines touch the same memory unsynchronized and at least one writes, it prints WARNING: DATA RACE with a stack for each access, and the test fails.

Let the goroutine signal on a channel and have the test receive from it, so the test unblocks exactly when the work is done. Add a select with a time.After case so a hang fails the test instead of stalling it.

A WaitGroup is only a counter: Add raises it, Done lowers it, Wait blocks until it reaches zero. A worker that returns before reaching its Done leaves the counter above zero, so Wait never unblocks. Put Done in a defer.

A sync.WaitGroup's Wait returns the moment its counter reaches zero, which can happen in a lull between two submissions. Refusing new work first makes the counter only fall, so Wait returning really means nothing is left in flight.

A goroutine cannot return anything to whoever started it. The usual answer is a channel: a small wrapper goroutine calls the worker function and sends its returned error on a chan error, and the supervisor waits on that channel.

They are dropped. The loop body is sequential, so nothing receives while the run is in progress, and a time.Ticker keeps at most one pending tick rather than a backlog. The daemon quietly settles at one run every 90 seconds.

Tear down in the direction data flows: stop accepting, let each sending goroutine return, close its output channel from that sending side, wait for the receivers to drain it, then release shared resources like a flusher last.

A ticker delivers its first value one full interval after it is created, never at time zero. To act at startup, do the work once before the loop, or put the work first in the loop body and the tick wait last.