Go atomic.Bool怎样安全切换进程运行状态怎样在批处理代码中减少额外分配

我在把一个定时批处理服务改成可暂停、可恢复时，最先遇到的并不是循环本身，而是“谁来保存运行状态”。如果控制 goroutine 写入状态，工作 goroutine 同时读取状态，普通 bool 既不能表达安全的并发访问，也会让竞态问题藏在很短的代码里。这个场景用 sync/atomic 的 atomic.Bool 更合适：控制入口调用 Store，工作循环调用 Load，状态对象只创建一次。

官方地址：https://pkg.go.dev/sync/atomic

如果只是共享一个“运行/停止”开关，推荐把状态定义为一个长期存在的 atomic.Bool，通过 Load 读取、Store 写入；批处理循环里不要反复创建包装对象。需要“只有一个控制方能切换”时，再使用 CompareAndSwap。

先看清 atomic.Bool 带来的变化

atomic.Bool 在 Go 1.19 加入 sync/atomic，零值是 false，提供 Load、Store、Swap 和 CompareAndSwap。官方文档还特别说明，实例第一次使用后不能再复制。它解决的是一个原子布尔值的并发读写，不是整个任务生命周期的锁，也不是对业务数据的事务保护。

这次迁移的重点可以压缩成一张表：

普通 bool 为什么不适合这个开关

下面的代码看起来很直观，但 running 会被两个 goroutine 并发访问：

// 普通 bool 不能为并发读写提供同步语义。
type Service struct {
    running bool
}

func (s *Service) Pause() {
    // 控制 goroutine 可能与工作 goroutine 同时访问这个字段。
    s.running = false
}

func (s *Service) RunOnce() bool {
    // 这里的读取没有和 Pause 建立同步关系。
    return s.running
}

如果把这类代码交给竞态检测，问题会暴露出来；即便暂时没有报错，也不能把“当前读到了 true”理解成后续整段任务都会继续运行。状态读取只应决定下一次循环是否开始，单次任务内部还要自行处理取消、超时和资源释放。

把状态封装成一次初始化、重复读取的对象

迁移时我会把状态字段改成指针，并让构造过程只负责初始化一次。下面的示例没有把 atomic.Bool 放进每轮任务的局部变量中，这既保留了对象身份，也避免循环中产生没有必要的包装值：

package main

import (
    "fmt"
    "sync/atomic"
)

type BatchService struct {
    // state 的零值为 false，这里显式 Store 让初始意图更清楚。
    state atomic.Bool
}

func NewBatchService() *BatchService {
    service := &BatchService{}
    // 服务创建后才允许工作循环进入处理段。
    service.state.Store(true)
    return service
}

func (s *BatchService) SetRunning(value bool) {
    // Store 是原子写入；它不会复制 atomic.Bool。
    s.state.Store(value)
}

func (s *BatchService) Running() bool {
    // Load 是工作循环唯一需要的原子读取入口。
    return s.state.Load()
}

func main() {
    service := NewBatchService()
    fmt.Println(service.Running())
    service.SetRunning(false)
    fmt.Println(service.Running())
}

这里的“减少额外分配”不是说原子操作本身免费，而是避免为了传递一个开关，在循环里不断创建临时结构、闭包或指针。状态是服务的一部分，生命周期与服务一致；工作循环只调用方法读取它。

在批处理循环里只读取一次状态

一个常见误区是在同一轮处理里多次调用 Load，并把每次读取当作同一个快照。更容易理解的写法是每轮先读入局部变量，再用这次读取决定是否进入处理段：

func (s *BatchService) Run(items 

如果停止操作要求立即打断当前项目，单靠 atomic.Bool 不够，需要把 context.Context 或取消通道传入 process。也就是说，原子布尔值适合做“是否允许下一轮开始”的轻量信号，不应该冒充完整的取消协议。

需要抢占式切换时使用 CompareAndSwap

如果只有一个控制入口，Store 通常足够；如果多个入口都可能启动服务，就要避免两个入口同时把“未运行”改成“运行中”。CompareAndSwap(false, true) 会把“检查旧值”和“写入新值”合并成一次原子条件操作：

func (s *BatchService) TryStart() bool {
    // 只有仍为 false 时才切换成功；返回值用于拒绝重复启动。
    return s.state.CompareAndSwap(false, true)
}

func (s *BatchService) Stop() bool {
    // 只有运行中才能切到停止，调用方可据此记录状态变化。
    return s.state.CompareAndSwap(true, false)
}

不要写成“先 Load 再 Store”来代替 CAS。两个入口可能在两次操作之间交错，导致双方都认为自己获得了切换权。CAS 的返回值才是本次切换是否成功的依据。

这次迁移需要回归哪些边界

• 版本：项目要使用 Go 1.19 或更高版本；更低版本不能直接引用 atomic.Bool，需要评估旧的 atomic.LoadUint32 方案或升级工具链。
• 不可复制：不要按值返回、按值传参或把使用中的服务结构放入会复制元素的容器；让状态对象保持稳定地址。
• 状态语义：false 只表示“不允许开始下一项”，不自动撤销已经提交的外部操作。
• 组合数据：如果状态和配置、计数器必须保持一致，优先考虑互斥锁、channel 或更高层的状态机，不要拼接多个原子字段假装事务。
• 性能判断：减少分配要靠复用对象和缩短热路径；不要因为用了原子类型就宣称批处理一定更快，实际收益仍取决于任务本身。

我会留下的迁移清单

1. 把共享的普通 bool 替换为生命周期稳定的 atomic.Bool 字段。
2. 所有并发读取统一走 Load，所有直接切换统一走 Store。
3. 需要“旧值满足条件才切换”时使用 CompareAndSwap，并检查返回值。
4. 把 Load 的结果保存为本轮局部快照，避免在同一轮重复读取。
5. 用取消上下文处理正在运行的单项任务，用 atomic.Bool 只承担轻量开关职责。
6. 检查 Go 工具链版本，并确认使用后的对象没有被复制。

相关问题

atomic.Bool 能替代 mutex 吗？

不能。它适合一个独立布尔状态的原子读写；如果要保护多个字段的一致性，仍应使用互斥锁或其他同步结构。

Store(false) 会立即停止正在处理的任务吗？

不会。它只改变共享开关；当前任务是否中断，要由任务代码配合 context、超时或取消信号决定。

为什么不继续用 atomic.Uint32？

旧方案仍可维护，但它需要约定 0 和 1 的含义。对于单纯的布尔状态，atomic.Bool 让接口直接表达意图，迁移后的代码更不容易把数值状态写错。