oo第二单元博客作业

[王竣翔-24373372]

第二单元电梯作业总结

1. 同步块与锁的设计

三次作业中，我对锁的设计是逐步细化的。

第一次作业中，主要共享资源是“待分配请求”和“单部电梯内部请求队列”，因此我主要使用了队列锁和调度器锁，保证请求的加入、取出、分配是原子的。第二次作业加入临时检修后，电梯的运行不再只是“接人-送人”，而是多了一套特殊状态流转，因此我开始把“状态切换”和“请求操作”分离，避免在一个大锁中混合处理。第三次作业加入双轿厢后，同一井道内出现了两个线程共享轨道资源的问题，因此我又引入了“井道锁”，专门负责主轿厢与备用轿厢之间的状态同步、楼层冲突控制和特殊操作协同。

我对锁和同步块的理解是：锁保护的应该是“共享状态”，而不是“整段业务逻辑”。因此我尽量只在修改共享数据、判断共享条件、执行 wait/notifyAll 时进入同步块，而不会把 sleep、输出、长时间运行逻辑放进锁里。这样做的好处是减少锁竞争，也能避免因为持锁时间过长而导致其他线程被无意义阻塞。

2. 调度器设计与线程交互

三次作业中，我都采用了“中心调度器 + 多电梯线程”的设计。输入线程负责读取请求并交给调度器，调度器负责为乘客选择合适的电梯，电梯线程则只负责执行开门、关门、上下行和乘客进出等动作。

第一次作业中，调度器的职责主要是分配普通乘客请求；第二次作业中，调度器除了分配新请求，还要接管检修开始时被中断的请求，并重新投放；第三次作业中，调度器还需要处理双轿厢拆分后的分段运输，把一个跨区请求拆成两段并重新分配给主/备轿厢。电梯线程和调度器之间的交互方式主要是：调度器分配请求后唤醒对应电梯；电梯在状态变化、乘客下车、中途换乘、特殊任务结束后再反向通知调度器继续分配。

3. 调度策略与性能考虑

我的调度策略本质上是一个带权代价选择。分配请求时，我会综合考虑电梯当前位置、已有任务数、车内人数、运行方向是否一致，以及是否需要在 F2 中转。距离近、负载低、方向一致的电梯会得到更低代价，从而优先被选中。

这个策略对多个性能指标都有兼顾。对时间指标来说，它能尽量减少等待时间和空驶距离；对电量指标来说，它避免了无意义开关门和长距离空跑；对特殊请求来说，我会优先保证检修、改造、回收的时间上限。第三次作业中，对跨区乘客采用“必要时中转”的策略，也是在时间和电量之间做平衡，而不是所有跨区请求都强行拆分。

4. bug 与调试方法

第二单元里我遇到过的 bug 主要集中在状态切换和线程协作上。比较典型的一类问题是：电梯状态已经切换了，但旧请求没有及时释放或重新分配，导致乘客丢失、重复 RECEIVE，或者电梯在没有合法请求时仍然移动。第三次作业里我还遇到过换乘层相关 bug，例如主轿厢在回收阶段把乘客放到 F2 后，又空载离开 F2，从而违反了 RECEIVE 约束。

我调试多线程程序的方法主要有三点。第一是“缩小规模”，尽量构造只包含一两个电梯请求的样例。第二是不盲目看全部输出，而是只盯住某一部电梯在某一段时间内的状态变化。第三是“检查不变量”，例如门开关是否合法、移动前是否有 RECEIVE、特殊状态下是否静默、系统结束时是否还有未完成请求。相比直接看代码，先从输出中找违反约束的时刻，再回溯到状态变化，效率会高很多。

5. 对线程安全与层次化设计的理解

线程安全不是“到处加 synchronized”，而是先想清楚“谁拥有数据、谁能修改数据、谁负责通知别人”。如果一个对象的职责不清晰，就很容易出现锁范围混乱、状态不一致、甚至死锁。

层次化设计同样很重要。我的实现里，输入处理、请求分配、井道控制、电梯执行是分层的。调度器负责“决定谁做”，电梯线程负责“把事情做完”，井道控制器负责“解决共享轨道冲突”。这样分层之后，功能扩展会容易很多。第二次加入检修时，我不需要推翻第一次的整体结构；第三次加入双轿厢时，也是在原有结构上增加井道层，而不是重写整个程序。这让我更直观地理解了“高层做决策，底层做执行”的设计价值。

6. 大模型使用心得

我主要使用的是 ChatGPT。我和大模型的分工比较明确：架构设计、核心代码实现、线程安全判断主要由我自己完成；大模型更多用于阅读规格、整理状态机、检查边界情况、生成测试样例以及帮助我复盘 bug。

在多线程电梯这种复杂任务里，大模型的优势是能快速整理很长的指导书，把分散的规则归纳成状态流转和约束清单，也能帮助我发现一些平时不容易想到的边界情况，比如检修/改造/回收与普通请求交织时的特殊场景。但它的困难也很明显：对多线程真实运行时序、锁粒度和竞态条件的把握并不总是可靠，有时会给出“看起来合理但实际上会违背题意”的建议，所以必须人工验证，不能直接照搬。

它在“整理信息”和“快速试错”上帮助很大，但在真正涉及线程安全、状态一致性和性能权衡时，最后仍然需要自己做判断。

7. 第二单元体验与建议

第二单元是我觉得训练价值很高、但也非常容易焦虑的一个单元。它不仅要求正确实现功能，还同时考察了线程安全、状态设计、实时交互和性能优化，尤其是后两次迭代加入检修和双轿厢后，复杂度上升非常明显。我最大的收获是对“状态机 + 并发协作 + 分层设计”有了更具体的理解，而不再只是停留在概念层面。

建议的话，我希望课程组以后能在指导书中对一些高频歧义点给出更明确的例子，尤其是 RECEIVE 约束、换乘层特例、以及特殊状态下哪些动作允许、哪些动作不允许。如果能再多给几组“合法但容易错”的官方样例，对同学们理解题意和减少无效 debug 会很有帮助。