本文共 1402 字，大约阅读时间需要 4 分钟。

恢复内容开始

摘要与前言

通过对OO课程的学习已进行了8周的深入研究，我对OO有了更深刻的理解，并经历了编写电梯调度模拟程序的宝贵经历。这段经历让我深刻体会到与其他大牛们相比还有很大差距，这种差距不仅体现在代码能力上，更体现在对OO课程的态度与学习积极性上。仅仅通过中测的态度远远不够。

第二单元作业回顾

在第二单元的三次作业中，我分别编写了单部多线程FAFS电梯模拟、单部多线程ALS电梯模拟以及多部多线程SS电梯模拟，通过这三次作业，我对多线程编程有了初步的体验，同时也踩了不少坑，收获了宝贵的知识。

作业代码分析

第一次作业代码分析

设计思路：本次作业采用FAFS调度方式，设计思路是创建一个电梯线程和一个调度器线程。调度器线程负责从输入读取请求并将其放入队列中，而电梯线程则负责处理队列中的请求。通过生产者-消费者模型实现，确保每个类只承担自身职责。

UML类图如下：

类图描述：- Elevator类负责处理请求- Scheduler类负责调度请求- Input类作为生产者

代码复杂度分析：整体结构合理，各类方法复杂度较低，成功降低了模块耦合度。

第二次作业代码分析

本次作业在FAFS基础上实现了ALS调度。主要思路是在空载时选择最先到达的请求作为主请求，在每层楼层建立一个队列，电梯到达某一层时遍历该队列处理可稍带的请求。

UML类图如下：

类图描述：- Elevator类负责处理请求- Scheduler类负责调度请求- Input类作为生产者

代码复杂度分析：与上次相比，调度器的算法复杂度提升，特别是bringUp和bringDown方法复杂度较高，导致耦合度增加。

第三次作业代码分析

本次作业实现了SS调度，难度显著提升。每个电梯有到达楼层、速度和载客量限制，优化空间较大。主要思路是将每个电梯分配一个主请求，若能直达则终点即为该层，否则设定换乘楼层。

UML类图如下：

类图描述：- Elevator类负责处理请求- Scheduler类负责调度请求- Input类作为生产者

代码复杂度分析：由于调度算法复杂度更高，耦合性增加，方法复杂度显著提升。同时，因未正确使用wait与notifyall方法，导致多线程调度出现RE问题。

程序bug分析

• 第一次作业：逻辑简单，主要通过强测和互测发现bug。需要保证队列线程安全，避免同时读写导致NullPointerException。
• 第二次作业：逻辑难度适中，主要bug来源于输入数据量大时导致RE。通过使用wait与notifyall方法减少线程占用CPU。
• 第三次作业：逻辑复杂，RE问题依然存在。经过分析，发现电梯类run方法中存在轮询问题，尽管使用了同步机制，但未能完全避免多线程切换带来的潜在问题。

Hack策略

针对多线程程序的偶发性和不确定性，使用Python脚本模拟测试点来检测线程安全问题。虽然无法实现定时投放，但可以有效检测逻辑问题。同时，注意减少锁嵌套，避免死锁。

总结

通过第二单元的三次作业，我对Java多线程编写有了初步认识，也深刻体会到架构设计与线程安全的重要性。线程安全是核心，设计原则要降低耦合，减少共享变量，避免死锁。未来，我将以更高质量的代码为目标，在后续作业中吸取经验教训，持续提升。

转载自: https://www.cnblogs.com/wttth/p/10760998.html