Inviare un valore su un canale non inizializzato ('var ch chan int; ch <- 1') non produce panic ma blocca permanentemente la goroutine; è una caratteristica usata nei costrutti 'select' ma causa gravi leak se accidentale.
NIL_CHANNEL_SEND_HANG
→
All'interno di un ciclo 'for { select { case <-time.After(5*time.Minute): ... } }', ogni iterazione alloca un nuovo timer che non viene deallocato dal garbage collector fino allo scadere dei 5 minuti; si risolve riutilizzando un 'time.NewTimer()' con '.Reset()'.
TIME_AFTER_MEMORY_LEAK
→
Tentare di leggere dati da un canale il cui valore è 'nil' sospende la goroutine all'infinito senza mai sbloccarsi o restituire un errore.
NIL_CHANNEL_RECV_HANG
→
Il metodo 'cond.Wait()' rilascia atomicamente il locker associato ('cond.L') e sospende la goroutine; se il lock non è stato preventivamente acquisito con 'cond.L.Lock()', l'invocazione di Wait() scatena un panic fatale.
SYNC_COND_LOCK_MISSING
→
L'errore viene restituito da chiamate HTTP, query a database o operazioni gRPC quando il tempo massimo allocato da 'context.WithTimeout' scade prima che l'operazione sia completata.
CONTEXT_DEADLINE_EXCEEDED
→
Quando si crea un contesto derivato ('ctx, cancel := context.WithTimeout(...)'), omettere l'istruzione 'defer cancel()' lascia attivi i timer e le goroutine interne del context package fino alla scadenza del timeout, sprecando memoria.
CONTEXT_LEAK_MISSING_CANCEL
→
Il runtime di Go rileva quando tutte le goroutine attive nel programma sono bloccate in attesa di canali o lock senza che alcuna goroutine possa sbloccarle, arrestando il processo.
FATAL_DEADLOCK
→
Inserire un costrutto 'select' con un ramo 'default' vuoto all'interno di un ciclo 'for' infinito causa un consumo del 100% di una CPU (busy loop) senza mai cedere il controllo allo scheduler del runtime.
SELECT_DEFAULT_BUSY_WAIT
→