OO2026第二单元总结博客

[程灿-24231210]

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

  在Shaft类中，我使用了Semaphore实现电梯对2楼的互斥访问。在Elevator类中使用synchronized保护电梯状态和请求队列的安全。例如我的setElevatorState()方法通过synchronized保证了电梯状态的正确修改，也确保了对电梯状态的读取的正确性。

二、调度器的设计与调度策略

  对于电梯的分配，我采取的就是简单的平均分配，对id进行mod6运算。这种分配模式在大量的数据上是平均的，可是面对具体的测试数据又是伪平均的。对于电梯的调度，首先考虑的就是电梯的重量限制，这是正确性的问题。接着为了缩短运行时间，电梯会通过自身状态选择优先处理同方向的请求，从而减少无效的折返。在Elevator类中，电梯仅在有请求或者状态变更时运行，从而减少空转耗电。

三、bug与debug

  在很多情况下我的程序在运行时间上会超时，究其原因是Elevator类中电梯的运行逻辑以及相关锁的设计有问题，导致出现了活锁的问题，cpu运行时间总是在10秒多。对于电梯的分配，如果乘客的id为特殊的序列（例如都是6的倍数），就会导致只有一个电梯被使用，运行时间大幅提高，因而对这一策略也应当进行优化。

  个人认为debug最好的办法就是看自己代码的实际输出，通过输出的问题反推自己程序存在的问题，最后定位问题源于那段代码。对于最后一步，有时候会有些很难一眼看出来的bug，这时可以借助大模型辅助debug。

四、线程安全和层次化设计

  本次作业的层次主要有输入层，指令层，电梯调度层和输出层。根据java语言的特性，程序是高内聚低耦合的，电梯相关的大量数据都封存在Elevator类中。调度器只负责分发请求，而电梯只负责接受和处理。

五、关于大模型

  大模型在大多数的情况下是相对可靠的，它能显著地提高编程的效率，同时介绍一些比较巧妙的设计方法。同时，大模型也会出现各种各样的错误。对此，我的经验是对待大模型生成的内容要时刻保持质疑，最好多方求证，也可以通过实践检验，让代码跑起来看看。对于大模型的使用，我认为给大模型提供的信息越局部，要求越具体，大模型就会实现得越好，特别是在修bug的过程中。

六、单元感受

  个人最大的感受就是复杂，要想解决多线程的问题需要各式各样的设计。讨论课上同学分享的各式各样的锁，对电梯运行时间，cpu运行时间的优化，突然感觉写的程序变得有些不可控了，越来越有那种没考虑到某个点就要全部推到重来的情况。