Leggere da un canale chiuso ('val := <-ch') non blocca la goroutine ma restituisce immediatamente il valore zero del tipo; se eseguito in un ciclo senza verificare il secondo valore booleano 'val, ok := <-ch', genera un loop infinito a consumo 100% CPU.
CLOSED_CHANNEL_ZERO_VALUE_LOOP
→
Un 'sync.Mutex' non deve mai essere copiato per valore: passare una struct contenente un mutex a una funzione o ricevitore senza puntatore ('(s MyStruct) Func()') crea una copia disallineata del lock distruggendo la mutua esclusione.
MUTEX_COPIED_BY_VALUE
→
Passare una variabile 'sync.WaitGroup' a una goroutine per valore anziché per puntatore ('*sync.WaitGroup') fa sì che il metodo 'Done()' decrementi una copia locale, lasciando il 'Wait()' principale bloccato per sempre in deadlock.
WAITGROUP_COPIED_BY_VALUE
→
L'operazione 'slice = append(slice, item)' non è atomica: se eseguita da più goroutine contemporaneamente senza sincronizzazione con mutex, sovrascrive elementi o corrompe il puntatore alla backing array.
SLICE_APPEND_DATA_RACE
→
Tentare di scrivere su un canale non bufferizzato ('ch <- val') prima di avviare una goroutine ricevente indipendente blocca la goroutine corrente all'infinito, provocando l'intervento del rilevatore di deadlock.
SAME_GOROUTINE_CHANNEL_DEADLOCK
→
Se la funzione passata a 'once.Do(f)' richiama a sua volta 'once.Do()' sulla medesima istanza di sync.Once, l'esecuzione rimane bloccata in attesa del mutex interno già acquisito.
SYNC_ONCE_RECURSIVE_DEADLOCK
→
L'anomalia si manifesta quando una goroutine tenta di inviare dati su un canale senza buffer che nessun consumer sta più leggendo, rimanendo residente in memoria per l'intera durata dell'applicazione.
GOROUTINE_LEAK
→
Un'istanza di 'recover()' posizionata nella goroutine genitrice (o nel thread principale) non può intercettare i panic delle goroutine secondarie avviate con 'go func()'; ogni goroutine deve implementare il proprio 'defer recover()'.
GOROUTINE_PANIC_CRASHES_PROCESS
→