Antwoord.

Achtergrond van de vraag:

Vanaf het begin heeft de taal Go het time-pakket aangeboden, waarin de belangrijkste functies voor tijdbeheer zijn ondergebracht — time.Sleep en time.After. In tegenstelling tot talen met systeemslaap (System.sleep), implementeert Go asynchrone timers via zijn eigen primitieve functies, wat belangrijk is voor multithreaded werk.

Probleem:

Ontwikkelaars gebruiken vaak time.Sleep verkeerd voor het implementeren van pauzes tussen taken, wat ongewenst is in concurrerende programma's. In de Go-paradigma is het beter om het wachten op gebeurtenissen te beheren via kanalen en time.After voor integratie met select/kanalen.

Oplossing:

time.Sleep(d) blokkeert de huidige goroutine voor d tijd, dit is een directe "slaap". time.After(d) retourneert een kanaal waarop na d een tijd-gebeurtenis verschijnt. De laatste optie is veel flexibeler in select over kanalen, en handig voor onderbroken wachttijden en time-outs.

Voorbeeldcode:

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

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

Belangrijke kenmerken:

time.After combineert uitstekend met select voor het implementeren van time-outs.
time.Sleep blokkeert alleen de huidige goroutine, niet de thread/proces.
time.After creëert elke keer een nieuw kanaal, oude worden niet vrijgegeven totdat de waarde is gelezen.

Vragen met een valkuil.

Kun je time.Sleep gebruiken om de uitvoering van het hele programma te blokkeren?

Nee, time.Sleep "laat" alleen één goroutine in slaap vallen, de andere gaan door met werken.

Kan time.After leiden tot geheugenlekken als het kanaal niet wordt gelezen?

Ja, de timer blijft hangen totdat de waarde is gelezen — als er geenLeesbewerking is, zal de garbage collector het object niet verwijderen.

Voorbeeldcode:

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

Hoe kun je het wachten op time.After correct annuleren bij het niet ontvangen van een gebeurtenis?

Het is beter om time.Timer te gebruiken en handmatig te stoppen als je het wachten voor de deadline wilt beëindigen:

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

Typische fouten en anti-patronen

Gebruik time.Sleep in werkende goroutines in plaats van kanalen en select.
Niet lezen van time.After, wat leidt tot timer-lekken.
time.After in een lus creëren zonder waarden te consumeren.

Voorbeeld uit het leven

Negatief geval

Een goroutine wacht op een signaal van werk, en voor het geval van een time-out doet het dit:

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

Voordelen:

Het is eenvoudig om een tijdpauze toe te voegen.

Nadelen:

Als het signaal al is ontvangen of er niet gewerkt hoeft te worden — onnodige slaap, kans op timingbugs.
Alles is onomkeerbaar, het is moeilijk om te "wakker te worden" als de annulering sneller plaatsvond dan de time-out.

Positief geval

De code is opgebouwd via select en time.After:

select {
case <-workSignal:
    // Uitvoeren
case <-time.After(10 * time.Second):
    // Doen naar de time-out
}