- 设计思路
- homework1
- homework2
- homework3
- 度量分析
- homework1
- homework2
- homework3
- bug分析
- 发现别人的bug
- 心得体会
设计思路
这三次作业的总体架构都很类似，都是采用生产者-消费者模式，两者共用一个公共队列容器。数据输入（生产者）和电梯（消费者）分别用独立的线程实现，请求队列作为公共容器，实现锁的控制。
在作业一中，单独开了一个Input类来作为生产者，后来的两次作业直接把读入请求并入MainClass中；在调度器的设计方面，三次作业都是把调度器整合在请求队列的类之中，电梯分别向请求队列提出请求，然后由队列中的调度器进行调度；在如何终止进程方面，我将所有电梯类setDaemon了一下，也就是当除了电梯线程之外的其它线程全部终止之后，所有电梯线程也会终止，这样只要在输入结束并且保证队列中所有请求全都满足之后，结束main线程即可。
同步控制方面的话，只要保证Queue里面的操作都上锁，就可以保证线程安全。
homework1
第一次作业的调度策略是完全按照指导书上的ALS(可捎带电梯)规则来实现的。
homework2
第二次作业的调度策略是：根据分配的电梯个数，等时间间距地投放电梯，电梯做来回往复运动。在考虑了别的一些调度方法之后，我采取了一种非常简洁的调度方式，宏观上看所有电梯等间距地运行，当电梯在所在楼层遇到请求并且电梯容量足够并且请求方向一致时则搭载请求。
基于这样的设计策略，实现过程就非常简洁了，电梯自己控制自己的行为（因为行为都是固定的），到达每一层的时候，都向Queue发送一个搭载请求，并且检查有没有下去的乘客。而Queue只需要根据电梯发送过来的请求以及相关限制，返回数个请求给电梯。再加上请求读入，整体的实现就基本上完成了。
这种调度策略对于大量的随机数据来说性能是很好的，因为它保证了每一个楼层在一个固定的短时间内都会经过一部电梯。所以在第二次作业强测中取得了很好的成绩（>99）。
homework3
由于第二次作业调度策略取得了不错的效果，所以我在第三次作业就没有怎么修改，还是采用一样的策略。但是因为第三次作业中电梯的一层运行时间可变，所以无法保证等间距这个条件，所以虽然正确性没有问题，但是性能方面就打了很大的折扣。
接下来根据5个经典设计原则仔细分析一下第三次作业：
- SRP（单一职责原则）：我认为这个原则体现的挺好，但是Queue类包含了调度功能可能是一个缺陷；
- OCP（开闭原则）：其实这个原则我一直不是很理解，第三次作业中比如需要修改电梯的一些参数，我只能删去原来的改为新的；再比如投放电梯的方式、请求的处理等等，都是通过修改原来的方法实现的，因为我觉得之前的方法在功能更加多的时候已经没有存在的意义了，所以我的处理不大符合这个原则；
- LSP（里氏替换原则）：本次作业用到继承的只有对Thread类的继承，满足这个原则；
- ISP（接口隔离原则）：本次作业没有使用到接口，个人认为也没必要使用接口；
- DIP（依赖倒置原则）：类的关系比较简单，没有体现；
另外要提到的是，尽管作业二和作业三的调度策略很好地满足的需求，但是在现实生活中毕竟很不实际，这是一个很大的不足。
度量分析
homework1
代码行数：186
UML图：
复杂度：
homework2
代码行数：196
UML图：
复杂度：
homework3
代码行数：244
UML图：
复杂度：
bug分析
第一次作业中出现了到达0层的情况，因为当时写评测机的时候检验函数没有考虑这个方面，所以没有检查出来；
第二次作业和第三次作业没有bug。
发现别人的bug
都是使用自己的评测机，先把别人所有的代码做成若干个jar文件，然后多个线程同时hack。
不过可惜，除了第一次作业（因为自己有bug，所以房间中存在好多bug）hack了几次之外，后面的作业都没能成功找出别人的bug。
心得体会
我觉得这一单元最大的不足就是，我设计电梯的时候没有考虑实用性，虽然对于完成作业来说这么做没有问题，但是总感觉不是很好。
另外没有仔细地去想去分析各种调度策略的性能，只是太过于追求简洁，这么做的后果就是：性能分看运气
不过通过了这一单元的学习，我对于多线程的有了初步的理解和掌握，我认为学习OO真的是必须要下功夫，因为别人不可能把所有东西都教给你，自己还需要花时间去思考，以及自己去找资料，这样才能让自己掌握更多东西。