buaa oo 第二单元总结

[张钧祺-22371432]

第二单元总结

第一部分

第一次作业基本上算是没有什么难度吗，从给的实验代码到各种教程都十分详细，但是第一次其实是有很大的问题的，就是没有采用wait-notifyall的方式来唤醒，而是单纯地采用sleep试图卡过评测机（事实上我写完了才发现最后那一行小字），这个问题会在第二部分详细的说。第二部分就是加锁的问题，第一次对于synchornized关键字的理解不够深入，没用采用一些规范的加锁的方法来防止冲突的发生，导致周六下午发现了一个很难复现的bug，在本地开很多个线程跑了上千次的数据才终于复现出来，因为requesttable中主要放了要被分配的人，所以讲这一部分的arraylist进行上锁，但是实际操作中发现这种方法并没有正确地保护好我的数据，在我将我的requesttable锁上后一切又变得合理了起来，我的初步推测是锁这个关键字并不能正确地锁上不同类中相同的数据，即使他们的存储地址相同，如果他们是跨类重复定义的话有可能无法正常工作。

BUG修复

第一次互测bug为0，强测未出现问题。第一单元自己写了评测机，但因为没有更好的数据投喂器而在速度上和自动化测试上有一定的问题，但是checker确实能够帮助我在茫茫多的输出中找到自己错误的点，同时评测机也让我学习了python的面向对象的写法，同时也学习了python中的多线程的研究，尤其是线程池的相关知识也有了相关的了解。同时发现如果在自己电脑上如果开过多的线程有可能并发会变为看上去串行的结果，如果有知道具体原因的大佬可以在评论区讨论一下。

第二次作业

第二次作业正值清明假期，本着一切从简的原则开始了这一次的迭代，分配方式用什么？随机！如何重置电梯？将他算作一个新的策略！虽然这样过了简单的样例但是直接导致了我所有的中测点都ctle了，因此我在主f102度过了煎熬的一晚，如何让电梯正确地醒来，我在凌晨三点的时候想出了很多奇怪的想法，比如说将我的一个类里面写一个方法去唤醒其他的类，在某个类的方法中强行改变其他的类的某种属性来让他们绑定做到可以同时唤醒，还有最重要的在wait中增加最大时间（因为最后实在没有办法在结束时唤醒了，这其实也是操作系统中十分重要的思想，最大等待）。

bug修复

第二次作业由于有一个自制的数据点刀到太多人被围攻了，结果发现并不好修改，最后只能修改一个电梯中的等待队列中的最大人数，将一部分先放在盘子里面先不要动，来防止某一电梯过多地在同一时间内接收到相同的请求。清明节假期，所以自动化测试方面最后被无限期搁置了，只是更新了自己的checker来方便自己debug。

第三次作业

第三次作业新增了双轿电梯这个新的类，为了减少对分配器的修改，我只能将电梯写为一个接口，然后将他分为普通电梯和双轿电梯，然后仿照普通电梯中的reset方法写了一个新的reset方法，但是怎么适时地开启双轿电梯是一个十分复杂的问题，最后只能采用最原始的方法，将双轿电梯中增加一个普通电梯的属性，实时地获取同号电梯是否重置结束。同时双轿电梯如何不相撞也是十分重要地问题，一开始我选择将两个电梯看是否对面会来电梯来判断，但是如果两者同时出现这种情况很容易产生两个过度礼让导致两个电梯死锁，最终我想了一个下下策，在move方法中如果当前楼层已经有电梯了那么就先不要走了，这种方法虽然修改了固定的move函数，让原本应该进行的动作被隔离开来，但是何种方法的正确性很高。

bug修复

因为不好的设计太多，所以反而bug变少了，这次中测直接一遍过，强测没bug，评测机因为上次没有迭代所以鸽了。