Go 的 sync.Mutex 包含状态机、自旋、信号量和饥饿模式四层逻辑，非简单 CAS；Lock() 性能波动源于状态切换，其 state 字段位布局稳定但不可直接操作，应避免手写锁逻辑。
Go 的 sync.Mutex 不是简单用一个 int32 标志位 + 原子操作就完事的，它有状态机、自旋、信号量、饥饿模式四层逻辑，直接照着教科书式 CAS 实现会掉进调度和公平性陷阱。
为什么 Lock() 有时快有时慢？看状态机切换
每个 sync.Mutex 内部是 state int32 + sema uint32 两个字段。state 低 3 位分别是 mutexLocked、mutexWoken、mutexStarving，高位存等待 goroutine 数。它不是只靠“抢到就赢”，而是分三种路径：
- 无竞争：直接 CAS 设置
mutexLocked，毫秒级完成 - 轻度竞争（runtime_doSpin），靠 CPU 空转等锁释放，避免上下文切换开销
- 重度竞争或自旋失败：调用
sema进入系统级休眠，走gopark→ 等待唤醒 → 重新竞争
Unlock() 唤醒谁？不是随便挑一个
Unlock() 不是简单把 mutexLocked 清零就结束。它要检查当前是否处于 mutexStarving 模式：
- 正常模式：用
semawakeup唤醒一个等待者，但新来的 goroutine 仍可参与竞争（可能插队） - 饥饿模式：跳过新 goroutine，直接把锁交给等待队列头的 goroutine（FIFO），且唤醒时不会设置
mutexWoken - 唤醒后若发现等待数为 0，就清掉
mutexStarving位，切回正常模式
这个机制防止某个 goroutine 因持续被插队而“饿死”，但代价是吞吐略降 —— 饥饿模式下自旋被禁用，所有等待都走系统调用。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
sync.RWMutex 的读锁为啥不阻塞读？但写锁容易饿死
RWMutex 本质是用一个 readerCount int32 计数器做乐观并发控制：
-
RLock()：原子加 1；如果结果 readerSem 排队 -
RUnlock()：原子减 1；如果减完等于 0 或触达负阈值（-rwmutexMaxReaders），就唤醒一个 writer - 写锁饥饿根源：只要不断有新 reader 到来，
readerCount就一直 > 0，writer 永远卡在writerSem上等不到机会
没有内置的写优先策略，应用层需自己控制读频次或加超时，否则高读场景下写操作可能延迟数秒甚至更久。
别手动实现锁逻辑，sync.Mutex 的 state 位布局是稳定 ABI
虽然文档没公开 state 各 bit 含义，但 Go 运行时源码中这些常量（如 mutexStarving、mutexWaiterShift）已在多个版本保持兼容。你如果绕过 Lock()/Unlock() 直接操作 state 字段：
- Go 1.21+ 可能因新增状态位（比如调试支持）导致位移错乱
- 跨平台（Windows/ARM64）下
sema行为不一致，裸调runtime_SemacquireMutex极易死锁 - race detector 无法识别手写锁逻辑，竞态问题彻底隐身
真正需要定制行为时，优先组合 sync.Mutex + time.AfterFunc 或封装带超时的 TryLock，而不是重造轮子。
