
A `time.Timer` fires once after a specified duration. It exposes a channel `C` that receives a value when the timer expires. Call `Stop` to cancel before it fires.

<ExamplePair>
<ExampleProse>

Create a timer that fires after two seconds. Block on `timer.C` to wait for it. Use `Stop` in a second goroutine to cancel a timer before it fires - `Stop` returns `false` if the timer already fired.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "time"
)

func main() {
    t1 := time.NewTimer(2 * time.Second)
    <-t1.C
    fmt.Println("timer 1 fired")

    t2 := time.NewTimer(time.Second)
    go func() {
        <-t2.C
        fmt.Println("timer 2 fired")
    }()
    stopped := t2.Stop()
    if stopped {
        fmt.Println("timer 2 stopped before firing")
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`time.AfterFunc` runs a callback in a new goroutine when the timer expires - no channel receive required:

</ExampleProse>
<ExampleCode>

```go
t := time.AfterFunc(500*time.Millisecond, func() {
    fmt.Println("callback fired")
})
// t.Stop() cancels the callback if called before the timer fires
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

When you need a one-shot delay inside a `select` and you may cancel early, prefer `time.NewTimer` over `time.After`:

</ExampleProse>
<ExampleCode>

```go
timer := time.NewTimer(5 * time.Second)
defer timer.Stop() // prevent the timer goroutine from leaking

select {
case result := <-work:
    fmt.Println("got result:", result)
case <-timer.C:
    fmt.Println("timed out")
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Always call `timer.Stop()` and drain the channel if needed when cancelling early - the GC does not collect a timer that is still running. A common leak pattern: creating a timer in a loop without stopping the previous one before resetting it. If `Stop` returns `false` (the timer already fired), drain the channel to unblock future receives: `select { case <-t.C: default: }`.
</InProduction>


Schedule a one-shot event with time.NewTimer and cancel it early with Stop.

Timers


A `time.Ticker` fires on a regular interval. Unlike a timer (which fires once), a ticker keeps ticking until you call `Stop`. Use it to drive polling loops, heartbeats, and periodic flushing.

<ExamplePair>
<ExampleProse>

Create a ticker that fires every 500 ms. Run it for 1.6 seconds by combining a `select` with a `time.After` stop signal, then call `Stop` to release the ticker's resources.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "time"
)

func main() {
    ticker := time.NewTicker(500 * time.Millisecond)
    defer ticker.Stop()

    stop := time.After(1600 * time.Millisecond)

    for {
        select {
        case t := <-ticker.C:
            fmt.Println("tick at", t.Format("15:04:05.000"))
        case <-stop:
            fmt.Println("stopping")
            return
        }
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Tickers are commonly used for cache refresh, metrics flushing, or keepalive pings in a long-running goroutine:

</ExampleProse>
<ExampleCode>

```go
func startHeartbeat(ctx context.Context, conn net.Conn) {
    ticker := time.NewTicker(30 * time.Second)
    defer ticker.Stop()

    for {
        select {
        case <-ticker.C:
            conn.Write([]byte("ping"))
        case <-ctx.Done():
            return
        }
    }
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Tickers fire at wall-clock intervals regardless of how long the tick handler takes. If the handler takes longer than the interval, ticks queue (up to one) and then are dropped. For work that must not overlap, track the last run time and skip if the previous execution is still in flight - or use a timer that you reset after each handler completes rather than a ticker.
</InProduction>


Fire repeatedly at a fixed interval with time.NewTicker; stop it to release resources.

Tickers


A `for range` loop over a channel receives values until the channel is closed. This is the idiomatic way to consume a stream of values produced by a goroutine.

<ExamplePair>
<ExampleProse>

Launch a producer goroutine that sends values and then closes the channel. The consumer iterates with `for v := range ch` - the loop exits automatically when the channel closes.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func produce(ch chan<- int) {
    for i := 1; i <= 5; i++ {
        ch <- i
    }
    close(ch) // signals the range loop to stop
}

func main() {
    ch := make(chan int)
    go produce(ch)

    for v := range ch {
        fmt.Println(v)
    }
    fmt.Println("done")
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Range over channels composes naturally into pipeline patterns, where one goroutine's output channel feeds the next stage's input:

</ExampleProse>
<ExampleCode>

```go
func square(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        for v := range in {
            out <- v * v
        }
        close(out) // propagate the close downstream
    }()
    return out
}

nums := make(chan int)
go func() {
    for _, n := range []int{2, 3, 4} {
        nums <- n
    }
    close(nums)
}()

for sq := range square(nums) {
    fmt.Println(sq) // 4, 9, 16
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Range over a channel blocks until the channel is closed. If the sender never closes, the loop runs forever - a common goroutine leak. Always ensure the sending goroutine closes the channel, or give the loop an exit condition via a done channel or `context.Context` cancellation.
</InProduction>


Iterate over channel values until the channel is closed using a for-range loop.