登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go教程

Go atomic.Bool怎样安全切换进程运行状态怎样完成一个可复用的最小示例

来源:17golang原创

时间:2026-11-09 15:20:26 310浏览 收藏

我在给一个后台进程加“运行中/已停止”开关时,最先遇到的不是语法问题,而是多个 goroutine 同时读写普通 bool:一个协程准备启动,另一个协程也以为自己拿到了启动机会。这个场景适合把状态收敛成 sync/atomic 提供的 atomic.Bool。

结论很简单:用 Load 读取,用 CompareAndSwap(false, true) 抢占一次启动权,用 Swap(false) 完成停止并取得旧值。它只负责一个布尔状态,不负责替代互斥锁、任务队列或整套配置。

官方文档:https://pkg.go.dev/sync/atomic

先把运行状态定义成一个原子开关

从架构上看,进程状态只有一个事实源:服务对象里的 running atomic.Bool。工作协程只通过 Load 观察它,启动和停止也只通过服务方法改变它。这样可以避免一部分代码使用普通字段、另一部分代码使用原子字段,造成读写协议不一致。

入口原子操作适合表达的意图
IsRunningLoad只读当前状态
StartCompareAndSwap只有一个调用者取得启动权
StopSwap切换为停止并获得旧状态
Service与atomic.Bool及并发访问入口的静态结构关系
图1:静态结构说明图,查看运行状态开关与并发读取、启动、停止入口的关系。

用 CAS 和 Swap 处理启动与停止

下面的封装把状态切换集中在三个方法里。Start 使用 CAS,只有值仍为 false 时才改成 true;如果两个 goroutine 同时调用,至多一个调用返回 true。Stop 使用 Swap(false),一次操作同时完成写入和旧值读取,适合判断“这次是否真的停止了运行中的服务”。

package main

import (
    "fmt"
    "sync/atomic"
)

// Service 只把运行状态作为一个原子布尔值暴露给并发调用方。
type Service struct {
    running atomic.Bool
}

// IsRunning 只读当前状态,不修改任何字段。
func (s *Service) IsRunning() bool {
    return s.running.Load()
}

// Start 只允许从停止状态切换到运行状态,返回值表示是否抢到启动权。
func (s *Service) Start() bool {
    return s.running.CompareAndSwap(false, true)
}

// Stop 把状态切换为停止,并返回切换前的值。
func (s *Service) Stop() bool {
    return s.running.Swap(false)
}

func main() {
    var service Service

    // 第一次调用从 false 切到 true,第二次不会重复启动。
    fmt.Println(service.Start())
    fmt.Println(service.Start())
    fmt.Println(service.IsRunning())

    // Swap 返回旧值,便于区分“真的停止”与重复停止。
    fmt.Println(service.Stop())
    fmt.Println(service.Stop())
}

这个例子没有把启动动作本身放进 Start,这是刻意留下的边界:CAS 只负责争抢状态,真正创建 worker、打开监听器或注册定时器时,仍要设计对应的失败回滚和资源清理。如果后续动作失败,应把状态恢复为 false,避免出现“标记运行但实际没有任务”的半完成状态。

CompareAndSwap与Swap连接启动权和旧值结果的静态关系
图2:静态关系说明图,查看 CAS 的启动权判断与 Swap 的停止结果如何围绕同一状态开关工作。

为什么不能把普通 bool 混进同一条路径

并发访问同一个状态时,读和写必须遵守同一套同步协议。不要在 IsRunning 里使用普通字段缓存,也不要先用 Load 判断为 false,再单独 Store(true) 来实现“只启动一次”:这两步之间可能被另一个调用插入,两个调用都可能继续执行启动逻辑。

如果只是无条件切换,可以使用 Store;如果必须根据旧值做决策,就使用 CompareAndSwap 或 Swap。这三个操作的选择取决于业务意图,而不是写法偏好。初始化时也应先确定默认状态,零值 false 正好适合“服务尚未启动”的模型。

按负载和约束判断它是否够用

对“一个开关、多个观察者、少量切换”的服务状态,atomic.Bool 通常比为一个字段包一把锁更直接。它不会替你保护旁边的 map、连接句柄或任务列表;如果状态变化必须和这些资源的修改保持一个不可分割的事务,就应把整个临界区交给 sync.Mutex 或更高层的状态机。

  • 只需要读写一个开关:优先考虑 Load、Store、Swap。
  • 需要“检查后占用”:使用 CompareAndSwap,不要拆成检查再写入。
  • 需要同步多个字段或资源:使用互斥锁,别把多个原子字段假装成一个事务。
  • 停止后还要等待 worker 退出:另行配合 channel、context 或 sync.WaitGroup,原子布尔值只表达状态。

atomic.Bool 能替代互斥锁吗?只能在共享对象确实是单一布尔状态时替代这一个字段的锁保护,不能保护关联资源。为什么 Start 要用 CAS?因为它把“仍为停止状态”和“切换为运行状态”合成一次条件更新。Stop 为什么适合 Swap?它能直接得到旧值,重复停止时可以返回 false。状态变化后如何让 worker 退出?让 worker 周期性读取状态,或通过 context/channel 发送停止信号,再用等待机制确认退出。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>