
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 worker pool bounds concurrency by fanning N worker goroutines out over a shared jobs channel. Workers pull jobs until the channel closes, results flow back on a results channel, and a `sync.WaitGroup` ensures clean shutdown.

<ExamplePair>
<ExampleProse>

Create a `jobs` channel and a `results` channel. Launch 3 workers each reading from `jobs`. Send 5 jobs, close the channel so workers know when to stop, then collect all results.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
    defer wg.Done()
    for j := range jobs {
        fmt.Printf("worker %d started job %d\n", id, j)
        time.Sleep(time.Second) // simulate work
        fmt.Printf("worker %d finished job %d\n", id, j)
        results <- j * 2
    }
}

func main() {
    const numWorkers = 3
    const numJobs = 5

    jobs := make(chan int, numJobs)
    results := make(chan int, numJobs)

    var wg sync.WaitGroup
    for w := 1; w <= numWorkers; w++ {
        wg.Add(1)
        go worker(w, jobs, results, &wg)
    }

    for j := 1; j <= numJobs; j++ {
        jobs <- j
    }
    close(jobs) // signal workers to stop after draining

    // close results once all workers are done
    go func() {
        wg.Wait()
        close(results)
    }()

    for r := range results {
        fmt.Println("result:", r)
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

For pure fan-out with no results collection, skip the results channel and close when the WaitGroup finishes:

</ExampleProse>
<ExampleCode>

```go
var wg sync.WaitGroup
for w := 0; w < numWorkers; w++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        for job := range jobs {
            process(job)
        }
    }()
}
wg.Wait()
```

</ExampleCode>
</ExamplePair>

<InProduction>
The worker pool pattern bounds concurrency for CPU-bound or rate-limited work. Size the pool to the bottleneck: CPU-bound work should use `runtime.GOMAXPROCS(0)` workers; I/O-bound work (HTTP, DB calls) should be tuned empirically with load testing. A pool of 100 goroutines hitting a database with `max_connections = 20` will queue at the DB level anyway - size the pool to match external resource limits, not to "be safe with more threads."
</InProduction>


Fan out work across N goroutines reading from a shared jobs channel to bound concurrency.

Worker Pools


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.