面向对象第二次博客作业

[李佳宜-ZC061002]

一、同步块与锁的设计分析

1. 同步块的设置与锁的选择

三次作业围绕多线程电梯调度展开，同步块和锁的设计核心是解决线程间的资源竞争与数据一致性问题，不同阶段的选择适配了不同的业务复杂度：

第一次作业（基础单电梯调度）

• 锁的选择：核心使用 ReentrantLock 而非 synchronized。原因是第一次作业虽逻辑简单，但需要手动控制锁的释放时机（如电梯到达楼层后唤醒等待线程），ReentrantLock 的可中断、可超时特性更灵活。
• 同步块设置：同步块集中在 “请求队列修改” 和 “电梯状态更新” 两处。例如，当主线程接收请求并加入队列时，同步块包裹队列的 add 操作；电梯线程读取队列时，同步块包裹 poll 操作。
• 锁与同步块语句的关系：锁的粒度严格匹配同步块内的处理逻辑，仅包裹 “读写共享队列 / 状态” 的核心语句，未包含电梯运行、楼层计算等无共享资源的逻辑，避免了锁粒度过大导致的性能损耗。

第二次作业（多电梯基础调度）

• 锁的选择：为每个电梯分配独立的 ReentrantLock，同时新增 “全局请求分发锁”（ReentrantLock + Condition）。多电梯场景下，独立锁避免了单锁导致的所有电梯阻塞，全局锁保证请求分发时的原子性。
• 同步块设置：同步块拆分为 “全局请求队列同步”“单电梯请求队列同步”“电梯状态同步” 三层。例如，分发线程修改全局队列时加全局锁，单个电梯处理自身请求时加电梯私有锁。
• 锁与同步块语句的关系：锁的归属与同步块处理逻辑强绑定，全局锁仅包裹 “请求分发” 相关语句，电梯私有锁仅包裹 “本电梯请求读写 / 状态更新” 语句，实现了 “谁使用、谁加锁” 的原则，避免跨锁操作导致的死锁。

第三次作业（多电梯带优先级 / 性能优化）

• 锁的选择：引入 ReadWriteLock（读写锁）优化读多写少的场景（如电梯状态查询），核心请求处理仍用 ReentrantLock + Condition 实现精准唤醒。
• 同步块设置：同步块进一步精细化，将 “请求添加”“请求删除”“状态查询” 拆分为独立同步块，读操作使用读锁、写操作使用写锁。例如，监控线程读取所有电梯状态时加读锁，分发线程修改请求队列时加写锁。
• 锁与同步块语句的关系：锁的类型（读 / 写 / 排他）完全匹配同步块内语句的操作类型，读操作共享锁提升并发性，写操作排他锁保证一致性；同时同步块仅包裹 “共享资源操作”，非共享逻辑（如电梯算法计算）完全剥离，最大化线程并行度。

2. 核心总结

锁的选择需匹配 “操作类型 + 并发场景”：简单排他用 ReentrantLock，读多写少用 ReadWriteLock，精准唤醒结合 Condition；同步块的边界必须严格对齐 “共享资源操作”，避免锁粒度过大 / 过小，是线程安全的基础。

二、调度器设计与调度策略分析

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

三次作业的调度器从 “单线程单电梯” 逐步演进为 “多线程分层调度”，核心交互逻辑如下：

第一次作业（单电梯）

• 调度器结构：单线程调度器，包含 “请求接收线程” 和 “电梯运行线程”。
• 线程交互：请求线程将请求加入共享队列后，唤醒电梯线程；电梯线程处理完请求后，若队列为空则进入等待状态，等待新请求唤醒。交互方式为 “生产者 - 消费者” 模型，通过锁 + 条件变量实现唤醒 / 等待。

第二次作业（多电梯）

• 调度器结构：分层调度器，包含 “请求接收线程”“请求分发线程”“多个电梯线程”。
• 线程交互：
  • 接收线程→分发线程：接收线程将请求加入全局队列，唤醒分发线程；
  • 分发线程→电梯线程：分发线程根据 “电梯当前位置 + 负载” 将请求分配到对应电梯的私有队列，唤醒该电梯线程；
  • 电梯线程：处理完私有队列请求后，若队列为空则等待，直到分发线程 / 接收线程唤醒。交互核心是 “全局分发 + 局部执行”，通过多锁隔离不同电梯的执行逻辑，避免相互阻塞。

第三次作业（多电梯性能优化）

• 调度器结构：智能调度器，新增 “监控线程”“性能统计线程”，形成 “接收 - 分发 - 执行 - 监控 - 优化” 闭环。
• 线程交互：
  • 监控线程：定时读取所有电梯状态（位置、负载、剩余电量），将性能数据传递给分发线程；
  • 分发线程：结合监控数据动态调整分发策略（如电量低的电梯优先分配短途请求）；
  • 电梯线程：执行请求时，实时上报状态到监控线程，异常时（如电量不足）主动唤醒分发线程重新分配请求。交互方式为 “双向通信”，调度器不仅分发请求，还能根据运行状态动态调整，线程间通过共享状态 + 条件变量实现实时联动。

2. 调度策略与性能指标适配

表格

作业阶段	核心调度策略	时间 / 电量等性能指标适配方式
第一次	先来先服务（FCFS）	仅适配时间指标：按请求到达顺序处理，减少请求等待时间；无电量考虑（假设电梯无限电量）
第二次	贪心算法（就近分配）	适配时间指标：将请求分配给 “距离最近 + 当前负载最少” 的电梯，降低整体运行时间；仍无电量考虑
第三次	多目标优化策略	1. 时间：结合 “就近分配 + 请求合并”（同方向请求批量处理）减少启停次数；2. 电量：为低电量电梯分配短途请求，高电量电梯分配长途请求；3. 负载：避免单部电梯负载过高，动态均衡各电梯请求数

3. 核心总结

调度器设计的核心是 “分层解耦”：接收、分发、执行、监控拆分为独立线程，通过共享资源 + 条件变量实现交互；调度策略需从 “单一目标（时间）” 向 “多目标（时间 + 电量 + 负载）” 演进，通过实时监控线程的状态反馈，动态调整策略以适配多性能指标。

三、Bug 分析与多线程 Debug 方法

1. 典型 Bug 总结

表格

Bug 类型	出现阶段	具体表现
死锁	第二次	分发线程持有全局锁时尝试获取电梯私有锁，电梯线程持有私有锁时尝试获取全局锁，导致相互阻塞
竞态条件	第一次	电梯线程读取队列后，队列被请求线程修改，导致重复处理 / 漏处理请求
虚假唤醒	第二次	电梯线程被唤醒后未检查队列是否真的有请求，导致空跑
锁粒度不当	第三次	读操作使用排他锁，导致监控线程读取状态时阻塞所有电梯线程，性能大幅下降
请求分发不均衡	第三次	部分电梯负载过高，部分闲置，未结合电量 / 位置动态调整

2. 多线程 Debug 方法

针对多线程 Bug 的特殊性，总结了以下核心 Debug 思路：

（1）日志埋点法

在关键操作（加锁 / 解锁、请求添加 / 删除、线程唤醒 / 等待）处添加详细日志，包含 “线程 ID + 操作时间 + 共享资源状态”。例如，死锁问题通过日志排查出 “线程 A 持有锁 X 等待锁 Y，线程 B 持有锁 Y 等待锁 X”，定位死锁链路。

（2）缩小复现范围

将并发场景简化：先单线程运行验证逻辑正确性，再逐步增加线程数；先模拟少量请求，再放大请求量。例如，竞态条件问题先单线程测试无问题，再双线程复现，定位到 “未加锁的共享队列读写”。

（3）工具辅助

使用 JDK 自带的 jstack 工具排查死锁（jstack <pid> 可直接显示死锁线程和持有的锁）；使用 IDEA 的线程调试功能，暂停所有线程后查看每个线程的调用栈和锁状态，定位虚假唤醒、锁等待问题。

（4）逻辑校验法

在同步块前后增加断言，校验共享资源的状态是否符合预期。例如，请求处理前断言 “队列非空”，避免虚假唤醒导致的空跑；锁释放后断言 “锁状态为未持有”，避免锁未释放的问题。

3. 核心总结

多线程 Debug 的关键是 “可复现 + 可追踪”：通过日志和工具明确线程执行顺序和锁状态，通过缩小场景定位问题根源；同时，编写代码时遵循 “最小锁粒度 + 先单线程验证 + 后多线程扩展” 的原则，可大幅降低 Bug 概率。

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

1. 线程安全的理解

三次作业让我深刻认识到：线程安全的核心是 “共享资源的原子性、可见性、有序性”。

• 原子性：通过锁 / 同步块保证共享资源操作不可分割（如请求队列的 add/poll 必须包裹在同步块内）；
• 可见性：通过 volatile / 锁保证一个线程修改的状态能被其他线程及时看到（如电梯状态标记为 volatile）；
• 有序性：避免指令重排导致的逻辑混乱（如锁的释放 / 获取顺序严格对齐业务逻辑）。

此外，线程安全不是 “越安全越好”，而是 “在保证正确性的前提下最小化锁开销”。例如第三次作业使用读写锁，既保证了读操作的并发性，又保证了写操作的安全性，平衡了 “安全” 与 “性能”。

2. 层次化设计的理解

层次化设计是多线程复杂系统的 “解耦关键”：

• 功能分层：将调度器拆分为 “接收层、分发层、执行层、监控层”，每层仅负责单一职责，层间通过清晰的接口（共享队列 / 状态）交互，避免 “一锅炖” 式的代码；
• 资源分层：将共享资源按 “全局 / 局部” 拆分（全局请求队列 / 电梯私有队列），对应不同的锁粒度，降低层间耦合；
• 异常分层：每层处理自身的异常（如接收层校验请求合法性，执行层处理电梯运行异常），避免异常扩散导致整个系统崩溃。

层次化设计的优势在第三次作业中尤为明显：新增 “电量优化” 功能时，仅需修改监控层和分发层的逻辑，执行层（电梯线程）无需改动，符合 “开闭原则”。

五、大模型使用心得

1. 使用的模型名称

主要使用Claude Code、豆包，辅助使用Gemini进行代码补全。

2. 与大模型的分工

阶段	我的工作	大模型的工作
需求分析	明确作业核心要求、性能指标、边界条件	梳理多线程电梯的核心设计模式（生产者 - 消费者、分层调度），提供设计思路参考
代码编写	设计整体架构、核心算法（调度策略）	编写基础代码模板（如锁的封装、线程通信逻辑），补全重复代码（如日志工具、状态校验）
Bug 排查	定位 Bug 现象、复现场景	分析多线程 Bug 的可能原因（如死锁、竞态条件），提供 Debug 思路和修复方案
优化迭代	确定优化方向（时间 / 电量）	提供性能优化的具体方法（如读写锁使用、条件变量精准唤醒），对比不同调度算法的优劣
文档 / 总结	提炼核心逻辑、总结实践心得	辅助梳理技术要点（如线程安全三特性），优化语言表达

3. 大模型的优势

• 比我懂得多

4. 大模型的困难

• 记忆没那么长

5. 使用感受

大模型是 “高效的辅助工具”，但绝非 “替代者”：

• 适合 “基础知识点答疑、模板代码编写、常见问题排查”，能大幅提升开发效率；
• 但在 “复杂系统架构设计、核心算法实现、工程化优化” 上，必须以自己的思考为主，大模型的输出仅作为参考，需严格验证逻辑正确性；
• 此外，使用时需 “精准提问”—— 明确告知大模型作业的约束条件（如 “多电梯、需考虑电量、使用 Java 实现”），才能获得更贴合需求的结果。

六、二单元学习体验与建议

1. 真实体验与感受

• 对多线程理解慢慢加深

2. 建议

（1）教学层面

• 补充多线程 Debug 工具教学：除了理论，可讲解 jstack、jconsole 等工具的使用，以及日志埋点的技巧，让学生掌握高效的 Debug 方法；
• 提供阶段性参考设计：第一次作业后给出基础架构参考，第二次作业后给出多电梯交互的参考思路，避免学生走过多弯路，聚焦核心难点（调度策略、线程安全）；

（2）作业设计层面

• 梯度更平缓：第二次作业从 “单电梯” 直接到 “多电梯” 跨度略大，可增加一次 “单电梯带简单优化（如请求合并）” 的作业，逐步提升难度；
• 性能指标分步引入：第三次作业同时引入时间、电量、负载等指标，可拆分指标（先优化时间，再优化电量），降低复杂度；
• 开放更多设计自由度：允许学生选择不同的锁类型、调度算法，鼓励创新，同时提供性能对比的基准，让学生理解不同设计的优劣。

（3）反馈层面

• 提供 Bug 案例库：收集学生作业中的典型 Bug（死锁、竞态条件、虚假唤醒），整理成案例库供学生参考，帮助学生规避常见问题；
• 代码评审重点明确：针对多线程作业，评审时重点关注 “锁粒度、线程交互、层次化设计”，而非仅关注 “功能是否实现”，引导学生重视代码质量。

七、总结

二单元的多线程电梯作业，让我从只会写单线程代码到能设计多线程分层系统，不仅掌握了锁、线程通信等技术点，更理解了 线程安全的核心思想。大模型作为辅助工具，大幅提升了开发效率，但核心的架构设计和逻辑验证仍需自己完成。