面向对象第二次博客作业

[吴晓佳-ZC061010]

一、前言

第二单元以多线程电梯为主线，从指定电梯、到自主调度 + 维修、再到双轿厢改造与回收，三次作业层层递进。我完整经历了从单线程思维到并发思维的转变，在锁设计、调度策略、线程安全、层次化架构上完成了系统性迭代。本文将严格按照作业要求，围绕同步块与锁、调度器设计、Bug 复盘、多线程理解、大模型心得、单元体验六大维度展开总结。

---

二、三次作业同步块设置与锁选择

我在三次作业中始终以synchronized为核心，锁对象围绕请求队列、调度器、电梯状态、井道互斥四类共享资源展开，同步块严格遵循最小粒度、只包共享读写原则。

1. 锁与同步块的迭代演进

• 第五次作业（指定电梯）锁对象：RequestQueue 实例锁同步块：队列的 add、get、wait、notify 全部包裹，保证队列原子访问。特点：最简单的对象锁，满足单队列、指定分配的线程安全。

• 第六次作业（自主调度 + 维修）锁对象：Scheduler 全局锁、TaskBuffer 队列锁、电梯状态锁同步块：

  • 调度器分配请求时加锁，防止并发修改待分配队列；
  • 电梯获取任务、修改载重、切换状态时加锁；
  • 维修流程中对 specialCommand、fixPending 加锁。特点：从单锁升级为多细粒度锁，减少无效竞争，支持多电梯并发。

• 第七次作业（双轿厢）锁对象：新增Shaft 井道锁、F2 换乘层互斥锁同步块：

  • 双轿厢进入 F2 前抢占井道锁，防止碰撞；
  • 状态切换（UPDATE/RECYCLE）全程加锁，保证时序不乱；
  • 所有修改 pending 队列、轿厢任务的地方缩到最小同步块。特点：锁直接支撑井道互斥、状态机时序、跨轿厢安全三大约束。

2. 锁与同步块中语句的关系

1. 锁保护的是共享资源，同步块划定临界区同步块内只做读 — 改 — 写原子操作，绝不放 sleep、循环、复杂逻辑。
2. 同步块越小，并发越高我从一开始锁整个方法，逐步改成只锁几行共享访问，性能明显提升。
3. wait/notify 必须在锁内队列空、无任务、维修等待等场景，必须在同步块内 wait，避免轮询。
4. 多锁必须固定顺序，防止死锁我始终遵循：先队列锁 → 再调度锁 → 最后电梯 / 井道锁，全程未出现死锁。

---

三、三次作业调度器设计、线程交互与调度策略

1. 调度器架构与线程交互（生产者 — 消费者）

• 第五次：无真正调度器，输入直接分给对应电梯队列。
• 第六次：独立调度线程 Scheduler，作为中央大脑：
  • 生产者：InputHandler 提交请求到全局池；
  • 消费者：调度器取出请求，按策略分配给电梯；
  • 交互：wait/notifyAll 实现无轮询，状态变化立即唤醒。
• 第七次：调度器升级为支持双轿厢、换乘、维修 / 改造 / 回收：
  • 能识别井道模式（NORMAL/DOUBLE）；
  • 支持跨层任务拆分换乘；
  • 维修 / 改造期间自动避开对应电梯。

线程交互统一模式：输入线程 → 全局队列 ← 调度线程 → 电梯缓冲队列 ← 电梯线程全程靠 wait/notify 休眠唤醒，CPU 占用极低。

2. 调度策略与性能适配（时间、电量）

我的调度策略核心是：最小负载 + 同方向优先 + 维修 / 双轿厢感知。

• 第五次：固定分配，简单稳定。
• 第六次：最小负载调度（修复后 leastLoad < 12）
  • 优先分给当前任务更少的电梯；
  • 电梯内部 ALS 同向捎带，减少空跑、减少开关门，省电省时间；
  • 限流兼顾防 TLE 和物理满载，适配极端数据。
• 第七次：双轿厢分区调度
  • 主轿厢负责 F2+，备用轿厢负责 F2-；
  • 跨层请求自动拆分在 F2 换乘；
  • 改造 / 回收期间不分配，保证合规；
  • 尽可能减少 ARRIVE、OPEN、CLOSE 次数，电量指标更优。

这套策略在三次作业里都能很好平衡总运行时间、平均等待时间、耗电量。

---

四、Bug 复盘与多线程 Debug 方法（重点真实 Bug）

1. 第六次作业两大致命 Bug（强测 WA）

1）调度限流阈值与物理容量冲突

• 现象：极端 50kg 乘客大量涌入，多电梯维修时大量乘客滞留 WA。
• 根因：调度器 leastLoad < 6，低于电梯 8 人物理上限。
• 修复：改为 leastLoad < 12，既防 TLE 又释放运力。

2）ALS 方向判断错误导致空载掉头

• 现象：电梯到同层同向请求却反向开走。
• 根因：isPathClear 用 > 而不是 >=，漏掉同层请求。
• 修复：改为 >=/<= 宽容匹配，彻底解决诡异掉头。

2. 第七次作业时序与状态机 Bug（强测违规）

1）RECEIVE 结束时机过早

• 问题：维修 / 改造一开始就把乘客重分配，导致重复 RECEIVE。
• 修复：统一把重入队放到 MAINT1-BEGIN / UPDATE-BEGIN / RECYCLE-BEGIN 之后。

2）状态切换早于 END 输出

• 问题：先切模式再输出 END，调度器提前分配违规。
• 修复：严格顺序：输出 END → 改状态 → 清空指令唤醒。

所有修复不改调度、不改运行逻辑，只修时序边界，一次性过强测。

3. 我的多线程 Debug 方法

1. 只信日志，不用行断点（断点会破坏调度）；
2. 关键位置打印：锁、wait/notify、分配、维修、状态切换；
3. 复现策略：先小数据稳定复现，再上极端压力；
4. 查竞态：看哪行没加锁却读写共享；
5. 查死锁：看锁顺序是否一致；
6. 查违规：严格对照题目的 BEGIN/END 时序与 RECEIVE 周期。

---

五、线程安全与层次化设计的理解

1. 线程安全

线程安全不是 “到处加锁”，而是一整套规范：

• 共享资源必须加锁保护；
• 临界区最小化；
• 用 wait/notify 杜绝轮询；
• 多锁固定顺序；
• 状态变更原子化；
• 所有线程退出条件安全可验证。

2. 层次化设计（我的四层架构）

1. 输入层 InputHandler：只负责读请求
2. 调度层 Scheduler：分配、策略、状态机
3. 电梯控制层 ElevatorCar：运行、开关门、上下人、特殊流程
4. 支撑层 Shaft/TaskBuffer/SystemController：队列、互斥、全局管理

层次化带来的好处：

• 职责单一，改维修不影响调度；
• 线程安全问题集中在队列与状态，极易定位；
• 第七次几乎没动架构，只修时序就兼容双轿厢。

---

六、大模型使用心得（真实、重点）

1. 使用模型

Gemini，Genspark

2. 人机分工

• 我负责：整体架构、锁设计、调度策略、状态机时序、Bug 根因定位、验收约束；
• 大模型负责：生成线程安全队列模板、代码结构整理、日志格式化、语法检查、解释多线程概念、提供 Debug 思路。

3. 优势

1. 快速写出线程安全队列、wait/notify 模板；
2. 解释死锁、虚假唤醒、临界区等抽象概念；
3. 帮我梳理复杂状态机流程；
4. 快速格式化代码、补充注释。

4. 困难

1. 不懂题目约束，会给出违规逻辑；
2. 复杂时序（维修 / 改造）容易写错顺序；
3. 无法理解整体架构，调度策略较浅；
4. 多线程随机 Bug 无法直接定位。

5. 使用感受

大模型是效率神器，但绝对不能替代思考。多线程的核心：锁设计、时序、状态机、约束合规，必须自己把控。人机协同才是最强模式。

---

七、第二单元真实体验与建议（重点）

1. 真实体验

这单元是我进步最大的部分。从一开始不懂锁、到处 WA、线程乱跑，到最后能稳定写出无轮询、无死锁、合规、高性能的多线程电梯，我真正建立了并发思维。研讨课交流让我意识到：锁粒度、时序、调度策略是大家共同的难点。互相看代码、分享 Bug 让我少走很多弯路。

2. 课程建议

1. 增加多线程基础小实验：先练生产者 — 消费者，再上电梯；
2. 开设专门的多线程 Debug 公开课：讲日志、锁检查、时序分析；
3. 提供状态机时序样例：维修 / 改造 / 回收的执行顺序最容易错；
4. 大模型使用指导：教大家如何正确提问、规避错误答案。

---

八、总结

第二单元的多线程电梯之旅，让我真正吃透了同步块与锁的正确使用、调度器设计与线程交互的核心逻辑，也打磨出兼顾高稳定性与性能指标的电梯调度策略，练就了一套面对复杂多线程 Bug 的定位与修复能力，更在实践中深刻理解了层次化架构与线程安全的设计思想，同时掌握了大模型辅助开发的正确使用方式。这段学习过程虽然充满挑战、时常为了一个隐蔽 Bug 反复调试到深夜，但也正是这样扎实的训练，让我完成了从单线程思维到多线程并发思维的彻底转变，是一段辛苦却无比充实、收获满满的成长历程。