OO第二单元总结
一同步块的设置和锁的选择
1同步块的设置
我对所有需要访问线程都使用了同步块，这样以避免多线程并发导致读入脏数据，如图中在ProcessingQueue中使用sychronized的waitRequest
我使用的全部都是synchronized锁，这样的好处应该是不容易出错，在作业中也不会造成过大的性能损耗。
二调度器设计
我仿照“厨师”实验完成的电梯调度器设计：
1输入线程
将所有输入格式化为请求后送入请求队列
2总请求队列
输入将所有请求打包后送入总请求队列，队列可以由分配线程访问，此外为了实现“踢人”逻辑，所以电梯线程也能读取与修改请求队列
3分配线程
分配线程取出请求队列中的请求后根据处理器分配任务刚给电梯
4处理器线程
享有相对应电梯的所有信息，用来唤醒或者运行电梯。
调度策略
我采用计算“得分”的方式来评判最优电梯，此外为了适应第三次迭代我还将电梯是否是双轿厢作为评判标准之一。由于缺少具体的量化标准，所以我的得分计算并不是十分严谨，大部分都是靠“俺寻思”来给分的，所以在时间上面相较于其它更加优秀复杂的机制来说性能有限。具体展开说，我的电梯会计算预计到达目标楼层时间，得出评分1，再根据乘客数量、是否超重得出评分2，最后考虑是否为双轿厢电梯得出总评分，最后将评分最优秀的电梯作为目标电梯发送RECIEVE。
三出现的BUG
第二次出现的经典的BUG，即当5台电梯维修时分发大量请求，此时由于我的分配器会在接收到请求时将所有请求都分配出去，导致将大量的请求分给一台电梯导致超时。为了修正，我更新了策略：当电梯此时由超过8个请求时就不再接受请求。
第三次的BUG为当客梯在将要前往F2时（此时已经关门，正在执行move客梯内由客人），此时F2由主梯控制，输入回收指令，在这种情况下导致卡死。修正方法为将优化逻辑，使主梯在客梯执行回收指令时也能自主移动。
四线程安全和层次化设计
通过对线程加锁的方式可以保证同一资源在同一时间只能有一个进行访问，这保证了数据不会出现“刚修改就读取”的风险，保证了不会读入“脏数据”。
通过“从上至下”的层次化设计，可以使代码架构简单明了，并且能简化逻辑，不容易犯错。
五大模型的使用
使用模型“GEMINI3.1pro"
真的很好用，我会先自己按照实验代码模仿来做我的作业。但写完肯定是有BUG的，然后我就用AI来DEBUG，慢慢改，并且我会先完成最简单的版本，改到能确保正确性后再慢慢添加复杂的逻辑。任务确实比较复杂，但我可以慢慢改，用评测坤找出错误点，然后交给AI分析，然后再改，然后再用评测只因来找BUG，然后再让AI分析……
六真实体验
实验上给的提示很强势，我完全是按照实验的来做我的电梯调度的，架构做出来感觉简洁清晰，此外还有AI真的太好用了（QAQ）。
