1. 概述
当我们开始使用并行或并发编程时，通常遇到的第一个问题是两个并发（或并行）执行试图访问相同的资源（例如一个变量）。 互斥锁 是解决此问题的最简单解决方案之一。 在下面的教程中，我们将解释它的工作原理以及如何使用它。
2. 互斥锁解释
互斥锁究竟解决了什么问题？ 让我们想象一下早上 Scrum 每日会议，有五位开发人员和 Scrum Master。 其中一位正在喝咖啡，在他完全清醒之前无法说话。 另一位想回到桌子前完成 SQL 查询，而不是参加会议。 其余（全部三位）理解会议的目标，并且很高兴谈论他们所做的事情，因此他们开始同时说话。
这最终导致混乱，没有人理解任何内容。 Scrum Master 站起来给一位开发人员一个球，并说：“只有拿着球的人才能说话！”。 从那时起，他们互相理解，并能够迅速结束会议
如果我们仔细思考，SM 通过定义系统中的临界区解决了这个问题。 我们理解“临界”这个词，因为我们可以看到如果我们不正确地管理它会导向何方。 开发人员（参与者）使用球作为工具来向其他人发出信号，谁可以说话，谁必须等待。 换句话说，这个球相互排除了开发人员的发言权。 这种命名非常普遍，以至于人们开始缩写：互斥锁（互互排除 互斥）。
3. 我们在哪里使用？
这个概念可以应用于许多不同的情况，主要目标始终是能够定义临界区
多个线程访问具有读写权限的共享内存
多个进程访问公共资源（打印机和摄像头）
互斥锁的一种常见实现方式是锁，它可以被获取（进入临界区）和释放（离开临界区）
4. 属性
正如我们上面所说，临界区保证一次只能让一个参与者访问。 如果我们设计得很糟糕，最终可能会得到一个大的临界区，只有一名参与者可以工作，而所有其他参与者都必须一直等待互斥锁释放。
这与顺序执行没有区别，因此我们没有通过选择并发编程获得任何性能提升（想想看，我们的Scrum示例就是这样的）。 这显示了临界区定义的重要性。 在设计系统时，我们必须识别并定位公共资源，以便能够从并行执行中受益。
另一个常见问题是 死锁。 假设为了好玩，Scrum 团队决定开发人员只有在完全完成任务后才能将球传给其他人，但他们需要来自同事的一些信息。 会发生什么？
拿着球的人（“开发人员 A”）向“开发人员 B”提问并等待答案
“开发人员 B”（没有球）知道答案，但他等待球才能说话
“开发人员 A”不能在获得答案之前完成任务，因此无法传球
这种情况有解决办法吗？ 不幸的是没有。 我们的系统将永远挂起，换句话说，处于死锁状态。
死锁可能发生在具有多个锁的系统中。为了确保你的设计是无死锁的，你应该在每个 actor 中以相同的顺序获取锁。
类似的现象在进退两难 (catch-22) 困境中也有体现。
5. 结论
在本文中，我们总结了互斥锁 (Mutexes) 的定义和属性，并了解了使用它们可能遇到的问题。重要的是要注意，有一些设计模式试图以不同于互斥锁的方式解决 actor 之间的交互。理解问题对于设计最佳解决方案至关重要。