こんにちは！開発現場で日々コードと向き合っていると、ふと「自分が使っているツールやランタイムは、裏側でどうやって動いているんだろう？」と気になるときってありませんか？
今回は、Go言語の裏側を支える心臓部の一つ、「タイマーとタイムアウト（`time.Sleep`や`time.After`）の内部構造」についてお話しします。
「Goのタイマーって、とりあえず使えば便利だよね」で済ませていませんか？
実は、数万〜数十万個のタイマーを同時に扱うような高負荷なシステムでは、この仕組みを理解しているかどうかで、CPU使用率やレイテンシが劇的に変わってきます。
これをマスターすれば、あなたの書くGoコードのパフォーマンスと信頼性は一段と跳ね上がりますよ。難しい低レイヤの世界ですが、優しく噛み砕いて解説していくので、ぜひ最後までついてきてくださいね！
—
1. Goランタイムにおける「タイマー」の役割と基礎
Go言語といえば、軽量な「ゴルーチン（Goroutine）」ですよね。私たちは普段、以下のようにごく自然に時間を扱っています。
package main
import (
“fmt”
“time”
)
func main() {
// 1秒間、現在のゴルーチンをスリープさせる
time.Sleep(1 time.Second)
fmt.Println(“起きました！”)
}
この `time.Sleep` や `time.After` は、OSのタイマー機能をそのままベタに叩いているわけではありません。OSのスレッド（OS Thread）レベルでタイマーを何十万個も作ろうものなら、コンテキストスイッチのオーバーヘッドでOSが即座に音を上げてしまいます。
そこで、Goランタイムが独自のスケジューラとタイマー管理機構を持ち、ユーザーランド（Goの内部）で数百万個ものタイマーを効率よくさばいているのです。
—
2. 内部構造の秘密：なぜGoのタイマーは速いのか？
では、Goランタイムは裏側でどのようにタイマーを管理しているのでしょうか？ キーワードは 「最小ヒープ（Min-Heap）」 と 「ネットワーカー（Network Poller）の統合」 です。
従来のタイマー管理の苦悩
昔のGoバージョン（Go 1.13以前）では、すべてのゴルーチンが持つタイマーが一つの巨大なグローバル・タイマーヒープに突っ込まれていました。
何が問題かというと、タイマーを追加・削除・発火させるたびに、全プロセッサ（P）がそのグローバルなロック（Mutex）を取り合うことになり、コア数が増えれば増えるほどロック競合（Lock Contention）でCPUが「空回り」してしまうというジレンマがあったのです。
Go 1.14以降のモダンなタイマー構造
現在のGoランタイム（Go 1.14以降、およびGo 1.18以降の大規模な改修）では、このアーキテクチャが洗練され、各P（Processor）単位、あるいはグローバルに分散された効率的なタイマー管理が行われています。
1. 最小ヒープ（Min-Heap）による管理
タイマーは「次に発火する時間」が最も早いものを根（Root）にしたバイナリヒープ構造で管理されます。これにより、次にどのタイマーを処理すべきかを $O(1)$ で参照でき、追加や削除も $O(\log N)$ の超高速で処理されます。
2. タイマープロセッサ（`timerproc`）の不在とネットワーカーへの統合
昔はタイマー専用のゴルーチンやスレッドが動いていましたが、現在はEpoll/KqueueなどのI/O多重化を司る「ネットワーカー（sysmonやnetpoller）」の仕組みと巧みに統合され、CPUを無駄に消費しないスリープ＆ウェイクアップを実現しています。
—
3. 実践！タイマーの挙動を確かめるミニマムコード
百聞は一見にしかず。まずは、タイマーの仕組みを体感するための簡単な動作確認コードを書いてみましょう。
以下のコードを、ご自身の環境（Go 1.18以降推奨）で動かしてみてください。
package main
import (
“context”
“fmt”
“time”
)
func main() {
// コンテキストを使ってタイムアウトを制御する（実務で最も推奨される書き方）
ctx, cancel := context.WithTimeout(context.Background( ), 2time.Second)
defer cancel() // メモリリークを防ぐために必ずdeferでキャンセルを呼ぶ
// 3秒かかる重い処理（をシミュレート）
workDuration := 3 time.Second
fmt.Println(“タスクを開始します…”)
// チャネルを使った非同期処理の模倣
done := make(chan struct{})
go func() {
// 3秒かかる処理
time.Sleep(workDuration)
close(done)
}()
// select構文で「処理の完了」と「タイムアウト」を待ち受ける
select {
case <-done:
fmt.Println("タスクが正常に完了しました！")
case <-ctx.Done():
// タイムアウト（2秒）が先に訪れた場合
fmt.Printf("タイムアウトが発生しました: %v\n", ctx.Err())
}
}
実行コマンドとログの例
$ go run main.go
タスクを開始します…
タイムアウトが発生しました: context deadline exceeded
このコードでは、2秒のタイムアウトに対して処理が3秒かかったため、見事に `context.Done()` 側がフックされ、システムがハングアップするのを防いでいます。
—
4. 【現場で震えるほど役立つ知見】大量のタイマーを扱うときの落とし穴とベストプラクティス
ここからが本題です。マニュアルには書いていない、実務でハマりがちな「タイマーの罠」と、その回避策をお伝えします。
罠1：`time.After` のループ内使用によるメモリリーク
リアルタイム性の高いチャネル処理や、goroutineのポーリングループで、以下のようなコードを書いたことはありませんか？
// ❌ 絶対にやってはいけないアンチパターン
for {
select {
case <-msgChan:
// メッセージ処理
case <-time.After(1 time.Minute):
// 1分間メッセージが来なかったらタイムアウト
fmt.Println("タイムアウト処理")
}
}
なぜこれがダメなのか？
`time.After` は、内部で新しく `time.Timer` オブジェクトを生成し、それをランタイムのタイマーヒープに登録します。
もし `msgChan` にガンガンメッセージが流れてループが高速に回ると、メッセージが来るたびに不要なタイマーがヒープに積まれ続け、タイマーが発火する（1分経つ）までガベージコレクションされずにメモリ上に残り続けます。
これが、数万件のコネクションを扱うWebSocketサーバーなどで発生すると、瞬く間にメモリリーク（Out of Memory）を引き起こします。
💡 対策：`time.Timer` を使い回す
正解は、タイマーをループの外で一度だけ作り、`Reset` メソッドで再利用することです。
// ⭕️ 正しいベストプラクティス
timer := time.NewTimer(1 time.Minute)
defer timer.Stop() // 使い終わったら必ず止める
for {
// タイマーが発火する時間をリセットする
if !timer.Stop() {
select {
case <-timer.C:
default:
}
}
timer.Reset(1 time.Minute)
select {
case <-msgChan:
// メッセージ処理
case <-timer.C:
fmt.Println("タイムアウト処理")
}
}
少しボイラープレートが増えますが、高負荷環境ではこの差がシステムの生死を分けます。
---
まとめ
いかがでしたでしょうか？
- Goのタイマーは、ランタイム内の効率的な「最小ヒープ」で管理されているため非常に軽量。
- しかし、`time.After` をループ内で安易に使うと、タイマーの乱造によるメモリリークやCPU負荷の跳ね上がりを招く。
- 高負荷なシステムでは `time.NewTimer` と `Reset()` を組み合わせてタイマーを再利用する。
この仕組みを知っていれば、コードレビューで「あ、そこ `time.After` 使ってるから危ないよ」と自信を持って指摘できるようになりますし、何より自信を持って堅牢なバックエンドシステムを構築できるようになります。
毎日のコーディングが、少しでも深く、楽しく、ドラマチックになりますように。
それでは、次のアーキテクチャ解説でお会いしましょう！