5个高频面试题拆解大雪中的山庄源码逻辑

看了一堆教程还是不会写项目？别慌，这不是你的问题，是教程没带你进源码深处。

很多开发者卡在“知道API怎么用，但不知道底层怎么跑”。今天拿《大雪中的山庄》这个经典案例，拆透它背后的并发控制与状态机设计。

这不是小说情节，而是高频面试题里关于“临界区保护”与“资源竞争”的实战映射。

入口定位：从NPM包看真实场景

在NPM官方包great-house-snow（假设包名，实际指代该类并发模型）的index.js入口中，我们能看到最真实的业务场景。

// 入口文件：init.js
const EventEmitter = require('events');class GreatHouse {constructor(config) {this.config = config;this.state = 'IDLE'; // 初始状态：空闲this.queue = [];    // 等待队列this.emitter = new EventEmitter();}// 核心方法：进入山庄enter(visitor) {if (this.state === 'BUSY') {this.queue.push(visitor);return 'QUEUED';}this.state = 'BUSY';this.emitter.emit('visitor-entered', visitor);return 'ENTERED';}
}module.exports = GreatHouse;

逐行拆解：

const EventEmitter = require('events');：引入Node.js内置事件模块，用于解耦状态变更通知。
this.state = 'IDLE';：状态机初始化，这是并发控制的核心，避免多访客同时进入导致数据脏读。
this.queue = [];：FIFO队列，保证公平性，防止饥饿现象。
if (this.state === 'BUSY')：这是临界区检查的关键，单线程环境下看似没问题，但在异步IO中可能失效。

核心片段：状态机的原子性陷阱

很多新手以为JavaScript单线程就安全了，大错特错。异步操作会打断同步逻辑。

看这段核心源码，来自stateMachine.js：

// 状态机核心：transition.js
async function transition(currentState, action) {// 模拟异步耗时操作，如数据库查询await simulateIO(50); if (currentState === 'IDLE' && action === 'ENTER') {return 'BUSY';} else if (currentState === 'BUSY' && action === 'LEAVE') {return 'IDLE';}throw new Error('Illegal State Transition');
}function simulateIO(ms) {return new Promise(resolve => setTimeout(resolve, ms));
}

逐行拆解：

await simulateIO(50);：这是Bug高发区。在await之前，currentState是IDLE，但await让出了执行权，其他任务可能修改了状态。
if (currentState === 'IDLE' ...)：这里的判断基于过期的快照。如果在await期间，另一个访客已经进入，状态变成BUSY，这里仍会返回BUSY，导致两个访客同时“进入”。
throw new Error('Illegal State Transition');：错误处理过于粗暴，生产环境应记录日志并回滚。

设计思想：

《大雪中的山庄》隐喻的是互斥锁（Mutex）。山庄只有一个门，同一时间只能有一人通过。但异步IO就像门轴松动，需要更严密的校验机制。

手写简化版：用Promise解决竞争

怎么修？别急着上Redis分布式锁，先搞定单机并发。

// 修复版：safeEnter.js
class SafeGreatHouse {constructor() {this.state = 'IDLE';this.queue = [];this.isProcessing = false; // 关键：处理中标志}async enter(visitor) {// 使用while循环，确保状态检查的原子性while (this.isProcessing) {await this._wait();}if (this.state !== 'IDLE') {this.queue.push(visitor);return 'QUEUED';}this.isProcessing = true;this.state = 'BUSY';try {// 模拟业务逻辑await this._doWork(visitor);} finally {this.state = 'IDLE';this.isProcessing = false;this._processNext();}}_wait() {return new Promise(resolve => setTimeout(resolve, 10));}_processNext() {if (this.queue.length > 0) {const next = this.queue.shift();this.enter(next);}}async _doWork(visitor) {console.log(`Visitor ${visitor.id} inside`);await new Promise(r => setTimeout(r, 100));}
}

关键改进：

while (this.isProcessing)：自旋等待，避免竞态条件。
finally块：确保状态一定被重置，即使业务抛异常。
_processNext：队列出队后递归调用，保证顺序执行。

避坑指南：

不要依赖if判断：异步环境下，if检查后状态可能已变，必须用while循环或锁机制。
队列去重：防止同一访客多次进入，需加Set去重。
超时机制：防止_doWork卡死，导致整个山庄瘫痪。

应用场景：从山庄到生产环境

这个模型在哪些地方用？

场景	对应概念	风险点
数据库连接池	山庄门	连接耗尽，新请求阻塞
文件上传	山庄内部	大文件传输中断，状态不一致
库存扣减	山庄资源	超卖，并发扣减为负
消息队列消费	山庄队列	消息丢失，重复消费

真实案例：

某电商系统库存扣减，用类似逻辑，结果await期间库存被其他线程修改，导致超卖。后来改用Redis Lua脚本保证原子性，问题才解决。

进阶技巧：

乐观锁：给state加版本号，更新时校验版本，失败则重试。
分布式锁：跨服务时，用Redis或ZooKeeper实现全局互斥。
幂等性：确保同一访客多次进入，结果一致，避免重复业务逻辑。

高频面试题延伸：如何设计一个安全的山庄？

面试官问：“如果山庄有多个房间，怎么设计？”

答案框架：

分层锁：门锁（全局互斥）+ 房间锁（局部互斥）。
死锁预防：规定锁获取顺序，如先拿门锁，再拿房间锁。
监控告警：状态长时间BUSY，触发告警，人工介入。

代码示意：

class MultiRoomGreatHouse {constructor(rooms) {this.rooms = rooms; // { roomA: new Room(), roomB: new Room() }this.globalLock = false;}async enter(roomName, visitor) {// 先拿全局锁，防止房间锁竞争await this._acquireGlobalLock();try {const room = this.rooms[roomName];if (!room) throw new Error('Room not found');await room.enter(visitor);} finally {this._releaseGlobalLock();}}async _acquireGlobalLock() {while (this.globalLock) {await this._wait();}this.globalLock = true;}_releaseGlobalLock() {this.globalLock = false;}
}

设计思想：