Pattern QuestDesign Pattern · Java ⇄ GoDesign Patterns · Java ⇄ Go

#go
#concurrency
#goroutine-leak
#ticker
#context

Bẫy time.Ticker trong Go: Ngăn goroutine leak và dừng ticker đúng cáchGo time.Ticker Pitfall: Prevent Goroutine Leaks and Properly Stop Tickers

Giải thích nguyên nhân goroutine leak khi dùng time.Ticker và cách dùng context, defer, và stop để giải quyết. Áp dụng ngay trong code Go của bạn.Explain why goroutine leaks happen with time.Ticker and how to use context, defer, and Stop to fix them. Apply the pattern to your Go code today.

29 tháng 10, 2026October 29, 20264 phút đọc4 min read000

Mục lụcContents· 6

Nguyên nhân sâu xa
Cách sửa: dùng time.NewTicker và context
Kết hợp với errgroup để quản lý nhiều ticker cùng lúc
Quy tắc nhanh (Rule of thumb)
Khi nào nên dùng time.After thay cho ticker?
Tóm tắt

Bạn đang viết một service Go để thu thập metrics mỗi giây. Đoạn mã dưới đây trông rất gọn:

func startMetrics() {
    for range time.Tick(1 * time.Second) {
        collect()
    }
}

Nhưng khi service bị restart hoặc khi container dừng, các goroutine vẫn còn chạy trong nền, gây tăng CPU và

Bẫy time.Ticker trong Go: Ngăn goroutine leak và dừng ticker đúng cách · Pattern Quest

time.Tick

Ticker

Tick

Ticker.Stop()

func startMetrics(ctx context.Context) {
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop() // luôn dừng ticker khi hàm trả về

    for {
        select {
        case <-ctx.Done():
            // context đã bị hủy, thoát vòng lặp và giải phóng tài nguyên
            return
        case <-ticker.C:
            collect()
        }
    }
}

func runAll(ctx context.Context) error {
    g, ctx := errgroup.WithContext(ctx)

    g.Go(func() error { startMetrics(ctx); return nil })
    g.Go(func() error { startHealthCheck(ctx); return nil })

    // Khi một goroutine trả về lỗi hoặc context bị cancel, errgroup sẽ hủy toàn bộ các công việc còn lại
    return g.Wait()
}

You are writing a Go service that collects metrics every second. The snippet below looks tidy:

func startMetrics() {
    for range time.Tick(1 * time.Second) {
        collect()
    }
}

However, when the service is restarted or the container stops, the goroutine created by time.Tick keeps running in the background, pushing CPU and memory usage up until the production instance crashes. The culprit is that time.Tick returns a channel backed by an internal Ticker that is never stopped; each tick spawns a hidden goroutine that pushes a signal into the channel. If you never call Ticker.Stop(), that goroutine lives forever.

Why it happens under the hood#

time.Tick is a shortcut – it creates a Ticker and returns its channel, but hides the Stop method.
When startMetrics exits (e.g., because the surrounding context is cancelled), the for range loop stops, but the ticker keeps firing and the sending goroutine has no receiver → goroutine leak.
Spawning many such tickers across the codebase quickly inflates the hidden goroutine count, leading to higher p99 latency, out‑of‑memory, and sometimes a full service outage.

Fix: use `time.NewTicker` together with `context`#

func startMetrics(ctx context.Context) {
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop() // always stop the ticker when the function returns

    for {
        select {
        case <-ctx.Done():
            // parent context cancelled – cleanly exit
            return
        case <-ticker.C:
            collect()
        }
    }
}

time.NewTicker returns a *Ticker that exposes a Stop() method.
defer ticker.Stop() guarantees the ticker is stopped even if the function panics or returns early.
The select with ctx.Done() lets you propagate cancellation from higher layers (HTTP request, background job, etc.). When the context is cancelled, the loop exits immediately and the hidden goroutine disappears.

Managing several tickers with `errgroup`#

func runAll(ctx context.Context) error {
    g, ctx := errgroup.WithContext(ctx)

    g.Go(func() error { startMetrics(ctx); return nil })
    g.Go(func() error { startHealthCheck(ctx); return nil })

    // If any goroutine returns an error or the context is cancelled, errgroup cancels the rest
    return g.Wait()
}

With errgroup, you no longer have to worry about a single goroutine leaking when another fails; the group cancels the shared context, causing all tickers to stop via the pattern shown above.

Rule of thumb#

Never use time.Tick in production. Always create a ticker with time.NewTicker and defer ticker.Stop().
Pass context.Context down to long‑running functions and always check ctx.Done() inside a select.
When you have multiple long‑running goroutines, use errgroup or sync.WaitGroup to ensure they are waited on and cancelled cleanly.

Warning: Simply breaking out of the loop is not enough; if you don’t call Stop(), the internal goroutine stays alive.

When to prefer `time.After` instead of a ticker?#

If you need a one‑off delay, time.After or time.Sleep is simpler and does not spawn a hidden goroutine. Use a ticker only for periodic work.

Key takeaways#

time.Tick always leaks a goroutine because it lacks a stop mechanism.
Replace it with time.NewTicker + defer Stop() and listen to ctx.Done() in a select.
errgroup.WithContext helps you manage many tickers without accidental leaks.
Follow these rules to keep p99 latency low and avoid out‑of‑memory crashes in production.

Have you ever been bitten by a leaking ticker? Share your story in the comments!

Bẫy time.Ticker trong Go: Ngăn goroutine leak và dừng ticker đúng cáchGo time.Ticker Pitfall: Prevent Goroutine Leaks and Properly Stop Tickers

Bẫy time.Ticker trong Go: Ngăn goroutine leak và dừng ticker đúng cáchGo time.Ticker Pitfall: Prevent Goroutine Leaks and Properly Stop Tickers

Nguyên nhân sâu xa#

Cách sửa: dùng `time.NewTicker` và `context`#

Kết hợp với `errgroup` để quản lý nhiều ticker cùng lúc#

Quy tắc nhanh (Rule of thumb)#

Khi nào nên dùng `time.After` thay cho ticker?#

Tóm tắt#

Why it happens under the hood#

Fix: use `time.NewTicker` together with `context`#

Managing several tickers with `errgroup`#

Rule of thumb#

When to prefer `time.After` instead of a ticker?#

Key takeaways#

Thảo luậnDiscussion

Nguyên nhân sâu xa#

Cách sửa: dùng time.NewTicker và context#

Kết hợp với errgroup để quản lý nhiều ticker cùng lúc#

Quy tắc nhanh (Rule of thumb)#

Khi nào nên dùng time.After thay cho ticker?#

Tóm tắt#

Why it happens under the hood#

Fix: use time.NewTicker together with context#

Managing several tickers with errgroup#

Rule of thumb#

When to prefer time.After instead of a ticker?#

Key takeaways#

Bài học liên quanRelated lessons

Cancellation / Context

Worker Pool

Thảo luậnDiscussion

Cách sửa: dùng `time.NewTicker` và `context`#

Kết hợp với `errgroup` để quản lý nhiều ticker cùng lúc#

Khi nào nên dùng `time.After` thay cho ticker?#

Fix: use `time.NewTicker` together with `context`#

Managing several tickers with `errgroup`#

When to prefer `time.After` instead of a ticker?#