OO第二单元の小结

第二单元（线程与电梯问题）总结博客

三次作业的设计策略

第一次：本次作业只有一部电梯，而且不用捎带。因此，我一共设计了两个线程：一个负责管理输入，一个负责电梯运行。同时，我将调度队列设置为单例模式，里面存储着一个队列。由于是存一次取一次，所以我在该单例模式中的方法使用了生产者消费者模式：input一个，get一个。

第二次：本次作业依旧是一部电梯，但是需要捎带。由于本质上还是一部电梯，所以我依旧没把调度器写成线程。依旧是一个线程负责输入，一个线程负责电梯运行。但是这次由于要稍带，调度器的方法就不能是互斥的生产者消费者模式了，因为每运行到一层都需要判断捎带。

第三次：本次作业变成了三部电梯，也需要捎带。三部电梯，自然要三个线程。处理输入也需要一个线程。在调度器我们需要将总队列内的任务分配到三个电梯的请求队列中，因此，调度器也是一个线程。

程序结构度量分析

　　第一次：由于本次作业较为简单，每个类的功能单一，因此，自己感觉设计得没有什么缺点，或许值得改进的地方是要将调度器也改成一个线程，这样更方便之后任务的拓展。

　　第二次：本次作业附带了捎带，而每层判断的捎带算法由于嵌套了大量if，复杂度飙升。或许应该再另写一类协助处理这个方法。还有个比较大的问题：elevator类中的方法过多，违反了SOLID原则中的单一功能原则，我应该将elevator中的方法分类、写到新的类中，由elevator调用，这样方便类的扩展。

　　第三次：这次的作业由于非主线程多于两个，因此，我要说一说线程之间的关系。但是，其实很简单：主线程将剩余的几个线程建立，由电梯线程结束所有运行线程。而线程之间的沟通利用的是几个容器类，也就是说，线程间不会直接交互，这样也保证了线程安全。

　　设计的缺点，最大的一点是我三个电梯分别写了三个类。我应该写一个基类再分别取继承这个电梯基类，这是设计中的重大失误，增加了代码复用，违背了设计原则。另一点和第二次的电梯作业一样：我应该把一些方法放在一个方法类中，被电梯线程调用，也许一部电梯时问题不大，但到了多部电梯，我就发现代码复用的问题了：不方便调试以及扩展。

BUG分析

　　第一次和第三次作业，公测样例全部通过，互测也没有bug，故不谈。（主要是第三次作业采取了很怂的调度方法，只追求正确性而没有考虑运行性能，虽然公测的点全部AC，但是性能分都是85）。故主要谈第二次作业的问题，第二次作业算上互测一共被hack了12次。而我修改三行就修复了其中11个bug。究其原因，是我的调度逻辑出现了问题。我在电梯的出发层不是当前楼层时，将请求加入了电梯队列，但是在前往出发层时，我进行了捎带，甚至捎带了与主请求运行方向相反的请求，导致根本没有接到人就去送人了，又由于主请求还在电梯队列内，导致出现了无中生有放人出去的窘况。于是我加了三行代码，电梯在前往接人的时候不会捎带，这样就修复了几乎全部的bug（摊手）。还省的一个bug有些怪异，电梯队列内遗留了最后一个请求然后停止了。于是我加了一个判断语句，解决了问题。

BUG策略

　　第一次作业由于电梯实在太傻瓜了，hack不到别人。第二次作业主要考察捎带的判断，有没有漏人或者关人，主要判断反向请求是否会接受。第三次作业主要判断…我个人感觉是判断三部电梯接人是否会重复。三次作业我都没能够hack成功一次，真是非常惭愧。

　　这个单元和上个单元相比，由于正确性以及性能全部交给强测判断了，我们能判断的，也只有调度算法是否有逻辑错误以及线程安全的问题了，而第一单元的作业追求的是绝对的运算正确。但本次作业，比如说第三次作业，错误是很难复现的，尤其是cpu运行时间的错误，线程的错误往往是不能复现的，这为debug制造了困难。

心得体会

　　由于本人对线程比较感兴趣，所以这次的作业相比上次写起来还是愉悦不少的。本人对于线程的理解是：安全第一、优化第二。为了时间的优化而忽视了线程本身的安全性，我觉得是舍本逐末的行为。因此，虽然第三次作业的性能分比较低，但我宁愿让乘坐我电梯的乘客稍事等候，也不希望他们陷入不安全的情况下，抑或是为了速度疯狂换乘。就当是我的小小执念罢。