在半导体制造中，多个设备需要竞争共享资源（如清洗机），请设计一个分布式锁机制，并说明如何避免死锁和竞态条件，以及在高并发下的性能表现。
答案
1) 【一句话结论】采用基于Redis的分布式锁方案（结合SETNX原子操作与过期时间），通过原子性保证互斥访问，设置合理超时避免死锁，结合集群部署与Redlock算法提升高并发下的性能与容错性。
2) 【原理/概念讲解】分布式锁的核心是确保同一时间仅一个设备能访问共享资源（如清洗机）。以Redis为例，SETNX（Set if Not Exist）命令原子性地尝试设置键值，若键不存在则成功（返回1），否则失败（返回0）；结合EXPIRE设置锁的过期时间（如10秒），防止设备异常导致锁永久占用。设备完成操作后，通过DEL释放锁。类比：抢火车票，多个用户同时点击“抢票”，只有第一个成功（SETNX返回1），然后设置超时（若用户未付款，票自动放回），最后付款后释放票（DEL）。
3) 【对比与适用场景】
| 方案 | 定义 | 核心机制 | 适用场景 | 注意点 |
|---|---|---|---|---|
| Redis分布式锁 | 基于Redis的原子性操作+过期时间 | SETNX尝试设置键，EXPIRE设置超时 | 对性能要求高（如清洗机调度），需快速获取锁的场景 | 需合理设置超时时间，单实例故障可能导致锁失效 |
| ZooKeeper分布式锁 | 基于ZooKeeper的临时顺序节点 | 创建临时顺序节点，监听节点变化 | 需复杂锁管理（如公平锁、可重入锁），容错性要求高的场景 | 依赖ZooKeeper集群，性能相对较低但更可靠 |
4) 【示例】（Redis实现伪代码）：
- 设备A获取锁：
SETNX lock_key 1 EX 10（成功则设置10秒过期时间） - 设备A操作后释放：
DEL lock_key - 设备A超时未释放：锁自动过期，其他设备可重新获取。
5) 【面试口播版答案】
面试官您好，针对半导体制造中设备竞争共享资源（如清洗机）的分布式锁问题，我建议采用基于Redis的分布式锁方案。核心思路是通过Redis的原子性SETNX命令尝试获取锁，并设置合理的过期时间（比如10秒），防止设备异常导致死锁。具体来说，设备在操作前执行SETNX lock_key 1 EX 10，成功则获取锁并开始操作，操作完成后执行DEL lock_key释放锁。如果设备在操作过程中超时，锁会自动过期，其他设备可以重新获取。这种方案利用Redis的高性能（如集群部署），在高并发下能快速响应，同时结合Redlock算法（使用5个Redis实例）提升容错性，避免单点故障导致锁失效。总结来说，通过原子操作+过期时间+集群部署，既能保证互斥访问，又能避免死锁和竞态，满足高并发下的性能需求。
6) 【追问清单】
- 问：如何避免死锁？答：通过设置锁的过期时间，确保设备异常后锁自动释放，其他设备可重新获取。
- 问：锁的粒度如何选择？答：根据共享资源使用情况，如清洗机操作时间长，设置较粗粒度（整个清洗机），避免频繁获取释放影响性能。
- 问：如果多个设备同时尝试获取锁，如何保证公平性？答：Redis的
SETNX是先到先得，ZooKeeper的临时顺序节点可实现更严格的公平锁，按创建顺序分配。 - 问：高并发下如何优化性能？答：使用Redis集群分片锁key，减少单点压力；或优化持久化（如RDB/AOF），避免数据丢失影响锁状态。
- 问：Redis实例故障时锁会失效吗？答：采用Redlock算法，通过多个实例尝试获取锁，多数成功则认为获取成功，提升容错性。
7) 【常见坑/雷区】
- 忽略锁的过期时间：导致设备异常后锁永久占用，引发死锁。
- 锁粒度设置不当：粒度过细（如每操作都锁）导致频繁竞争；粒度过粗（如全系统锁）降低并发度。
- 未考虑网络延迟：设备获取锁后网络延迟导致超时，其他设备误判为释放，引发竞态。
- 忽略锁释放：设备完成操作后未释放锁，影响后续设备访问。
- 使用单实例Redis：高并发下成为瓶颈，故障导致锁失效。