OO第二单元总结

一、概述

　　本单元的主题是通过多线程来模拟电梯调度。总体来讲我觉得这一单元的难度略低于第一单元，主要体现在书写代码的难度低于第一单元，但是调试的难度却略高于第一单元（不过我还是觉得第一单元第三次作业调试debug很难）。

 

二、设计策略

　　我在这三次作业采用的是生产者——消费者的模式，输入作为生产者，电梯是消费者，他们之间共享一个调度器。调度器主要保存一些队列和一些调度函数。在我的代码里，队列主要是：在我的代码里分为每一层的请求队列，以及每个电梯的内部请求队列。一些调度函数包括：目标选层函数、电梯上下客函数以及一些其他辅助函数。调度器的部分方法用synchronized修饰用于解决等待队列的同步和互斥问题。

　　第一次作业：单个电梯

　　第一次作业我在设计的时候运用了两个线程：一个输入线程，一个电梯线程。这两者之间有一个共享的调度器。调度器的数据有十六个list，其中一个list是电梯内部请求队列，另外15个list分别是每一层的外部请求队列。每次输入线程获得请求，调度器根据请求的fromfloor加入该层的请求队列。调度器的选层函数通过当前队列（即16个list）的情况决定电梯的下一个停靠层。当电梯停靠时，通过调度器的上下客函数，更新这16个list，并输出INOUT信息。

      我的调度方法是：方向不变的情况下就近原则。比如当前电梯在向上走，就从当前楼层+1开始向上搜索，如果电梯内有请求或者电梯外有请求则停靠。如果当前楼层以上没有任何请求则改变电梯的运行方向。电梯线程里通过一个数据upOrDown来标记当前电梯方向：1是向上，-1是向下，0是当前无请求。

　　第二次作业：多个电梯

　　第二次作业增加了电梯的数量和电梯中允许搭载的人数限制。本人为了偷懒就在第一次作业的基础上稍作改动，其中调度策略没有任何的变化。只是增加了多个电梯线程而已，并在调度器的方法里增加电梯下标参数来获得对应电梯的调度层略。当然造成的结果就是所有电梯疯狂强人，因此性能分就不是很好。

　　第三次作业：多种电梯

　　第三次作业给出了更多可变因素。本人为了偷懒就在第二次作业的基础上稍作改动，其中调度策略基本上没有很大的变化。值得一提的是，这次有些乘客不能直接到达，需要换乘。我们可以轻松证明，至多经过一次换乘，乘客就可以到达目的楼层。因此对于不能直接到达的乘客，我添加了一个寻找中间楼层的方法，使得乘客换乘的“总路径”最短。比较遗憾的是，由于一些情况下可能的死锁问题，我的强测一个点RTLE了。且后来跟同学交流，发现在电梯人满的时候，可以不必理会外部的请求队列，也就是有些情况下电梯不需要停靠。感叹一下我竟然没有想到（毕竟停靠一次挺费时间的）。

 

三、第三次作业架构设计的扩展性

　　我的第三次作业整个电梯设计的思路一直都是生产者——消费者模式，对电梯种类的扩展可以通过在电梯类中增加属性来实现。对多种多数目电梯的综合调度，大部分也只需要改变调度器中的调度方法就可以完成扩展和改进。总体来讲扩展性还是可以。但是不足之处在于调度器显得太过臃肿，里面包含了太多方法，且调度器管的事情也有点多以及相互渗透。因此如果进一步增强第三作业架构的可扩展性，可以在改造调度器上下功夫，比如形成一个二级调度器，一个负责宏观实现，另一个负责围观具体实现，这样可以使得整个程序更清晰，以及真正让每个对象只管好自己应该管的事情，通过对象间的消息传递来形成一个设计优良的oo程序。

 

四、度量分析

      以下第三次作业为例。

 

五、自己程序中的BUG和别人程序的BUG

      第一次作业：在互测中发现了自己的CPUTLE的bug。发现了自己在第一次作业中并没有才有线程同步的方法，而是暴力轮询。没有发现别人程序的bug。

　　第二次作业：没有bug。也没有发现别人的bug。

　　第三次作业：强测中一个点RTLE了，应该是在一些特定情况下产生的死锁。应该是在输入线程结束后，仅有一个电梯进程没有结束的情况下，没有其他进程通知这个电梯进程，从而陷入死锁。修改办法是在wait方法中加入参数，可以在一定时间后没有唤醒的情况下自动醒来，从而避免死锁造成的RTLE。互测的时候没有发现别人的bug反而发现了自己的bug。

 

六、体会

      在多线程程序设计中，线程同步和安全十分重要。在不进行暴力轮询的情况下，如何运用wait（），join（），notify（），notifyAll（）等方法进行配合至关重要。能够写出一个安全无bug程序的关键是自己对于程序架构的充分理解以及全面考虑。像我这第三次作业的BUG就在于没有考虑到input线程结束后只有一个电梯线程存活的情况。其他关于debug等事宜，我因为摸鱼没有搞自动化评测，因此没有什么发言权。希望我以后能在互测上花更多功夫与努力吧。