Risposta.

Storia della questione:

Fin dall'inizio, il linguaggio Go ha fornito il pacchetto time, all'interno del quale ci sono le funzioni principali per la gestione del tempo — time.Sleep e time.After. A differenza dei linguaggi con sonno di sistema (System.sleep), Go implementa timer asincroni tramite i suoi primitivi, il che è importante per il lavoro multithread.

Problema:

Spesso gli sviluppatori utilizzano in modo errato time.Sleep per implementare pause tra i compiti, il che è indesiderabile nei programmi concorrenti. Nella paradigmatica Go è più corretto costruire la gestione dell'attesa di eventi tramite canali e time.After per l'integrazione con select/canali.

Soluzione:

time.Sleep(d) blocca la goroutine corrente per d tempo, è un «sonno» diretto. time.After(d) restituisce un canale, sul quale dopo d apparirà un evento-tempo. Quest'ultima opzione è molto più flessibile in select per i canali, comoda per attese interrompibili e timeout.

Esempio di codice:

ch := make(chan struct{})
go func() {
    time.Sleep(2 * time.Second)
    ch <- struct{}{}
}()

select {
case <-ch:
    fmt.Println("fatto")
case <-time.After(1 * time.Second):
    fmt.Println("timeout")
}

Caratteristiche chiave:

time.After si combina ottimamente con select per implementare timeout.
time.Sleep blocca solo la goroutine corrente, non il thread/processo.
time.After crea ogni volta un nuovo canale, i vecchi non vengono liberati fino a quando il valore non viene letto.

Domande insidiose.

È possibile utilizzare time.Sleep per bloccare l'esecuzione dell'intero programma?

No, time.Sleep «addormenta» solo una goroutine, le altre continuano a lavorare.

Può time.After portare a perdite di memoria se il canale non viene letto?

Sì, il timer rimane attivo finché il valore non viene letto — in assenza di lettura, il garbage collector non elimina l'oggetto.

Esempio di codice:

func leak() {
    for {
        _ = time.After(time.Hour)
    }
}

Come interrompere correttamente l'attesa di time.After se non si riceve un evento?

È meglio utilizzare time.Timer e fermare manualmente, se è necessario concludere l'attesa prima della scadenza:

t := time.NewTimer(time.Minute)
if done {
    t.Stop()
}

Errori tipici e anti-pattern

Utilizzare time.Sleep nelle goroutine di lavoro invece di canali e select.
Non leggere da time.After, causando perdite di timer.
Creare time.After in un ciclo, senza consumare i valori.

Esempio di vita

Casi negativi

Una goroutine attende un segnale dal lavoro e nel caso di timeout fa così:

time.Sleep(10*time.Second)
doSomething()

Pro:

È semplice aggiungere una pausa temporale.

Contro:

Se il segnale è già stato ricevuto o non è necessario lavorare — un sonno superfluo, possibilità di bug temporali.
Tutto è irrinunciabile, difficile «svegliare» se l'annullamento avviene prima del timeout.

Casi positivi

Il codice è costruito tramite select e time.After:

select {
case <-workSignal:
    // Eseguire
case <-time.After(10 * time.Second):
    // Fare per timeout
}