Il panic viene sollevato quando il metodo 'wg.Done()' o 'wg.Add(-1)' viene invocato un numero di volte superiore rispetto ai job registrati con 'wg.Add()', portando il contatore interno sotto zero.
PANIC_WAITGROUP_NEGATIVE
→
Invocare 'mu.Unlock()' su un sync.Mutex o sync.RWMutex che non è stato preventivamente acquisito con 'mu.Lock()' innesca un panic fatale nel runtime.
PANIC_MUTEX_UNLOCK
→
Invocare 'wg.Add()' su una variabile sync.WaitGroup mentre un'altra goroutine è ancora in attesa su 'wg.Wait()' senza aver completato il ciclo precedente genera panic per violazione di consistenza.
PANIC_WAITGROUP_REUSED
→
La struttura 'atomic.Value' richiede che tutte le chiamate successive a '.Store()' ricevano sempre esattamente lo stesso tipo concreto della prima memorizzazione; memorizzare tipi diversi genera panic.
PANIC_ATOMIC_TYPE
→
L'anomalia si verifica quando un canale con buffer limitato si riempie completamente perché la goroutine produttrice genera messaggi più velocemente di quanto il consumer riesca a smaltirli.
CHANNEL_BUFFER_FULL
→
Il race detector di Go ('go run -race' o 'go test -race') segnala che due goroutine hanno effettuato accessi simultanei alla stessa variabile di memoria e almeno uno di essi è una scrittura non sincronizzata.
DATA_RACE_DETECTED
→