面向对象第二次博客作业

[王一斐-20375034]

总结分析三次作业中同步块的设置和锁的选择，并分析锁与同步块中处理语句之间的关系

锁的对象选择存在实例锁来管理对象自身的私有状态，还有分配器的的实例锁来确保了任务分配逻辑的原子性。
同步块设计遵循‘死锁预防’原则，内部仅执行本对象状态转换与局部计算，避免在持有锁时调用其他对象的同步方法，防止嵌套锁引发循环等待。跨对象协作通过状态机通知或线程安全队列解耦实现。
HW7引入了读写锁，读锁用于获取电梯当前位置、载重、任务数等，写锁用于修改任务归属、更新电梯坐标、改变运行模式。
同步块范围严格遵循‘最小临界区’原则。策略计算、路径规划等无副作用的逻辑均置于锁外执行；仅在读取共享状态快照、校验竞争条件、提交最终状态变更时短暂持有写锁，避免长时间阻塞导致并发性能下降。若同步块内需使用 wait()，当前线程必须已持有该对象的监视器锁。条件检查须置于 while 循环中，以防止伪唤醒导致的状态不一致。wait() 执行期间会自动释放锁并挂起线程，被唤醒后将重新竞争锁并再次校验条件，确保状态转换的安全性。

总结分析三次作业中的调度器设计，并分析调度器如何与程序中的线程进行交互；总结分析三次作业中的调度策略，并分析自己的调度策略是如何适应时间、电量等多个性能指标的

调度器如何与程序中的线程进行交互整体属于生产者-消费者模式。
HW5就是纯LOOK调度，而且我没有使用单独的类实现调度器的功能，都是电梯类自己来进行相关策略与输入队列进行交互。
HW6引入维修后，调度器增加了“可用性检查”。整体采用距离优先，来优先分配给最近的电梯，减少了电梯的空跑时间，从而降低了电量消耗。同时采用负载约束防止任务过度集中在某一部电梯上。电梯自身的运行基本还是LOOK策略。电量方面采用静止等待与减少开关门来省电。
HW7电梯自身的运行基本还是LOOK策略。由于双轿厢的运行范围限制，调度器不再寻找能一站式到达的电梯，而是寻找能向目的地“推进”的电梯，并在换乘层实现任务的无缝接力。整体是贪心距离算法+分段运输。

分析自己程序出现过的bug以及自己面对多线程程序的debug方法

HW5中强测和互测阶段并没有Bug。
HW6强测和互测阶段存在乘客维护时到达判定错误的问题，以及大量乘客在5个检修1个空闲时被分配涌入同一个电梯导致的TLE的问题。
HW7强测和互测阶段发现我的双轿厢改造与回收中，转乘逻辑与维修结束后的调度信号设计有问题导致可能会出现隐蔽的死锁产生TLE，以及两部电梯同时出现在换乘层F2导致的WA。
多线程程序的debug方法，首先是需要有一个强大的测试辅助工具，在电梯方面的具体体现就是TestMain与datainput工具，如果没有这两个工具，那么就很难完成相应的debug。第二点是合理利用大模型的分析能力，让他们直接从输入输出去分析可能出错的地点及解决方案，这样能够极大地提升debug的效率。此外就是需要留意Powershell与cmd可能在多线程程序的debug阶段有不同的结果，需要使用可以得到正确的数据的终端。

结合三次作业谈谈从线程安全和层次化设计的理解

在三次作业中，线程安全十分重要，我也因此出了一些错误。起初，我只是简单地对候乘队列加锁，到HW7后我使用了 ReadWriteLock 来平衡并发性能与安全性。双轿厢冲突本质上是资源竞争，我最终通过引入静态的预约数组和主动唤醒机制，实现了线程间的主动避让。我认为线程安全十分重要，因为这一点决定了会不会出现死锁产生TLE等问题，需要认真设计。
层次化设计是随着三次作业的迭代中复杂度的增加而不得不去考虑的。例如类出现了职责的分层与隔离，包括输入层、调度层、执行层、行为委托层等。此外通过状态与行为的解耦可以使得状态的线程安全保护集中处理，且逻辑的扩展则变得非常灵活。我们可以在作业早期就产生一个大致的层次化设计的思路，免得之后遇到作业的新需求造成相关的重构。

大模型的使用心得：模型名称，如何与大模型进行的分工，在面临多线程电梯这样的复杂任务时大模型具有什么优势，会遇到什么困难，自己使用大模型的感受...

在大模型方面，我采用了了Gemini、Glm、GPT、MiniMax等模型。大模型的使用我认为分为chat与agent两个方面，对于作业指导书等题目要求内容，可以让大模型进行相关解读的任务，并且提醒我们其中可能存在的重点与难点，以及一些输入输出格式的相关分析，我认为大模型在这方面能力比较强。此外就是agent让大模型可帮助进行代码补全等操作以提升写代码时的效率、还可以让大模型生成更多的测试用例，提高测试方面的效率。多线程电梯调度涉及死锁预防等复杂任务。大模型可以在调度算法等整体设计方面给出较为合理的选择，同时在测试方面可以帮助我们分析电梯系统的极端场景与边界条件。我遇到的最大的困难是大模型在测试时一般都会默认使用Powershell的脚本，但是在这个单元之中，Powershell可能产生一些问题，需要使用cmd进行测试，这使得我在使用大模型辅助时需要付出更多的精力。回顾整个使用过程，我觉得大模型确实提高了相关工作的效率，但是大模型也可能存在很多隐含的问题与错误需要在使用时小心谨慎，水平不足的情况之下最好用多个模型进行交叉验证。

二单元的真实体验和感受

这个单元的整体体验比较不错，我觉得最主要的原因可能是通过中测并进入强测的难度曲线设置的比较合理。虽然这样也导致了在强测之中，暴露出了很多TLE、甚至WA的错误，同时如果不进行相关优化，存在很大的可能性会进入B房以及C房，但是对于我个人而言有着比第一单元更好的体验。在课上授课方面，我认为第二单元也有着更加有用的知识点以及相关的案例解析，使得我在完成作业时感到有很大的帮助。此外还要感谢互测阶段同房间内产出大量测试数据的同学，有很多测试数据对于我个人而言是完全没有想到的角度。通过在互测阶段的检验，成功发现了我的程序之中存在的很多问题，让我得以在之后进行修复。如果没有互测阶段同学的相关帮助，我可能会浪费更多时间与精力在生成测试数据方面。最后要感谢助教对于修复的审核方面，并且没有出现长时间卡审核的状况，让我在每个作业的收尾倦怠期都有着更加良好的体验。
总的来说，我认为这个单元的体验已经比较优秀了，我认为这离不开课程组长期对于电梯这一主题的精心打磨，这让我也更加期待之后两个单元的内容，希望大家都能够收获良好的课程体验。