Go 1.14 后不存在四叉堆，真实机制是单最小堆加时间轮混合调度；所有 timer 和 ticker 共享同一 runtimeTimer 结构和全局最小堆，短期定时器走时间轮加速，Stop/Reset 的并发误用易致 panic 或泄漏。
go 1.14 后根本没有四叉堆，所谓“四叉堆存储优化”是误传 —— 当前（2026 年）真实机制是单最小堆 + 时间轮混合调度，由全局 timerproc goroutine 统一驱动。
为什么查到的“四叉堆”全是错的
你看到的“每个 P 存一个四叉堆”“64 个四叉堆”等说法，基本来自对 Go 1.10–1.13 临时方案的误读或过时资料：
- Go 1.10–1.13 确实用过最多 64 个
per-P 最小堆，但仍是“最小堆”，不是“四叉堆”；源码中无quadruple、four-way或类似逻辑 - Go 1.14 彻底移除了
timersBucket和所有 per-P 堆结构，合并为全局单棵最小堆pp.timers（注意：是pp，不是p），并引入时间轮加速短期定时器插入/删除 -
src/runtime/time.go中只有adjusttimers、runtimer、addtimer等函数，完全不涉及四叉堆操作
time.NewTimer 底层到底怎么存的
time.NewTimer 创建的 Timer 实际包装了一个 runtimeTimer 结构体，它不直接持有堆节点，而是通过 addtimer 注册进运行时调度系统：
- 注册时，
addtimer将其插入全局最小堆（堆顶始终是最近到期的 timer） - 若
when - now < 1ms，会走时间轮路径（wheel bucket），避免高频堆调整开销 - 所有 timer 和 ticker 共享同一套
runtimeTimer结构和同一棵堆，区别仅在回调函数是否自动重调度（addtimer(&t.r)） - 没有“Timer 存堆、Ticker 存轮”这种割裂设计 —— 时间轮只是最小堆的加速补丁，不是替代品
Stop/Reset 为什么容易 panic 和泄漏
这些操作的语义依赖底层堆行为，但文档没明说细节，导致高频踩坑：
-
Stop()是 O(log n) 删除：若 timer 已触发或正在被timerproc处理，Stop()返回false，但不会阻塞；忽略返回值会导致后续Reset()失效 -
Reset(d)等价于先Stop()再addtimer()：若原 timer 已触发，Reset()返回false，且不会重设 —— 不检查就等于放弃这次重置 - 并发调用
Reset()或Stop()+C读取，可能触发panic: send on closed channel，因为Timer.C关闭后仍可能有残留信号待投递 -
Ticker.Stop()后继续range ticker.C或select { case ，必然 panic —— 必须确保消费循环在 <code>Stop()后立即退出
真正要盯住的不是堆结构，而是 Stop/Reset 的返回值、channel 生命周期、以及任务执行是否超时 —— 这些才是线上故障的源头。时间轮和最小堆只是 runtime 的实现细节，对业务代码透明，但它们的行为边界决定了你该怎么写安全的定时逻辑。
