互斥锁通过加锁→访问资源→解锁的串行化机制确保临界区独占访问，防止数据竞争；需全覆盖、及时释放、粒度适中，并规避死锁与锁内阻塞等陷阱。
互斥锁是解决线程并发中数据破坏最直接、最常用的方法。它通过强制“串行化访问”临界区，确保任意时刻最多只有一个线程能读写共享资源，从而从根源上切断数据竞争的执行路径。
互斥锁怎么起作用
它的核心行为非常明确：加锁 → 访问资源 → 解锁。只要所有访问该资源的代码路径都严格遵循这个流程，数据就不会被多个线程交错修改。
- 加锁失败时，线程会主动等待（阻塞），而不是强行读写，避免了竞态时序错乱
- 锁的状态是全局可见的，底层依赖原子指令（如 compare-and-swap）保证判断和设置的不可分割性
- 一个典型的破坏场景是 counter++：它实际包含“读-改-写”三步。没有锁时，两个线程可能同时读到旧值，各自加1后写回，结果只+1而非+2——互斥锁把这三步整体包裹成原子操作单元
关键使用原则
锁本身不难用，但用错会导致死锁、漏锁或性能瓶颈。真正起效的前提是规范使用。
- 全覆盖：所有读、写该共享变量的地方都必须加同一把锁，包括看似只读的检查逻辑（比如“if (balance > amount) then withdraw”）
- 及时释放：加锁后必须有对应解锁，且不能因异常、return 或 break 跳过。推荐用 RAII 方式（如 C++ 的 std::lock_guard、Python 的 with lock:）自动管理生命周期
- 粒度适中：锁太粗（比如整个函数加一把锁）会降低并发度；锁太细（比如每行代码都锁一次）又增加开销。应围绕“逻辑上不可分割的一组操作”划定临界区
常见陷阱与规避方式
很多数据破坏不是因为没加锁，而是锁的使用方式埋下了隐患。
- 忘记加锁：新增代码绕过原有同步逻辑。建议把共享资源封装成类，所有访问都走带锁的方法接口
- 死锁：多个线程按不同顺序请求多把锁（如线程A先锁mutex1再锁mutex2，线程B反之）。统一按固定顺序（如地址大小）加锁，或用 std::scoped_lock（C++17）/ threading.RLock（Python 可重入锁，仅限同一线程多次进入）辅助
- 锁内调用阻塞操作：比如在持有锁时做文件 I/O、网络请求或调用未知第三方函数，会拖慢其他线程。应把耗时操作移出临界区，只在锁内做内存计算和状态更新
它不是万能的，但不可或缺
互斥锁解决的是“谁可以访问”的问题，不负责“什么时候访问合适”。如果业务逻辑需要等待某个条件成立（比如“库存大于0才扣减”），单靠互斥锁不够，得配合条件变量；如果只是计数器累加，std::atomic 可能更轻量高效。但它仍是构建线程安全程序的地基——稳、准、可预期。
