OO第二单元总结
17231041 金陆洋
这一单元开启了多线程的旅途，从最开始的FAFS，到ASL，再到最后的SS，每一次的难度都有一个很大的提升，尤其是最后一次作业的时候，经常会让我领略到凌晨四点的北航（当然，也有OS的功劳），当然，在这个痛苦的过程中，我的能力也得到了一次又一次的提升（应该吧~~~），当然和大佬相比还是有很大的差距。
接下来进入正题，先来讲一讲这三次作业中对多线程的一些个人拙见，可能有些片面，各位看官笑笑即可，如若能在评论区指点几句就更加感激不尽了。
与暴力轮询say goodbye——从让它睡觉到让它等着
面对共享对象（在这次作业中，即RequestList）的访问，一个永远逃不开的问题就是如何避免暴力轮询，一种方式是sleep(time)让线程休眠一段时间，另一种方法是wait/notify使线程暂时阻塞直到被唤醒。
由于第一次作业中我不太敢用wait/notify，对这两个方法的功能也不甚了解，因此采用了简单粗暴的sleep()方法，让电梯分配器为空的时候每访问一次RequestList便休眠一段时间才能进行下一次的访问，其实这样做似乎没什么问题，更准确地说，正确性并没有受到影响，如此简易高效的做法我本可能沿用到之后的两次作业中的，直到某位大佬对我说了这样一句话：
感觉你这样做不够美观。
使用sleep固然不会错，可这样做好吗，答案显然应该是否定的。
或许一个电梯的时候sleep还可以，但多电梯呢？多调度策略呢？很显然，sleep不能很好地支持代码的健壮性和可复用性，为了面对将来纷繁复杂的情况，我们显然应该使用wait/notify来解决轮询。
这就好比人家给了我点钞机，我却要一张一张自己点，一张两张效率可能更高，但一万张呢？
因此，从第二次作业开始，我换用了wait/notify，其实真的蛮好用的，尤其是第三次作业的时候，而且似乎wait/notify的性能比单纯sleep还要好一点？
其实sleep有个值得注意的问题，如果我哪天脑抽把sleep写在了synchronized方法中，那可能真的gg了。
在使用wait/notify的时候，我也越加深刻地体会到了代码构架的重要性，只有将构架完整地搭建好了，使用wait/notify才会真正万无一失。
因此，真正好的构架应该是一以贯之行云流水的的，而绝不是缝缝补补拆东墙补西墙的，这在我的第二次电梯作业中体现得最为明显，在这次作业中，我第一次使用了wait/notify，自然少不了四处碰壁，也发现了构架的不少小问题，我选择了直接重构，其实也并未花费多长时间，反而可能比一遍又一遍地找bug更快，而且从根本上解决了众多bug（虽然性能分不高）。但其实如果我能在写代码之前再认真思考一下架构问题，而不那么急于动手，应该也就不需要这一次的重构了，也算是一个教训了。
于是，第三次电梯作业我用了一个晚上从头到尾地做好了构架，真正写代码的时候反而很轻松。
可以说，时至今日，我才真正体会到了一个好的构架的重要性。
不要重复造轮子，指导书中如是说，我原来不明白这句话的真正含义，现在才发觉，原来我之前都在重复造轮子。
多线程冲突——synchronized大法真的好吗
作为Java尤其是多线程的初学者，只要涉及到共享对象的访问就加一个synchronized，这样似乎万事大吉了？
如果没有一个良好的构架作为基础，那么势必会导致synchronized关键字出现频率异常多，而互斥锁用得越多，也就更有可能出现难以预料的线程问题，这是在所难免的。
因此，synchronized应该是用得越少越好（当然，在保证线程安全的前提下），这也就需要一个好的架构来实现解耦，这样，似乎又回到了上一个问题。
解决线程冲突问题，也可以使用不可变对象，这也是行之有效的方法，但由于电梯作业的增删改查过于频繁，使用不可变对象的代价太大，因此最终放弃了这个想法（应该是我太菜了没有想到使用的方法）。
线程的结束——一起停还是分别停
这个问题，其实就不是那么重要了，两种策略在我看来无孰优孰劣，根据自己的构架选择更加适合的即可。
我使用的是分别停止的方法，在每个电梯完成了所有的工作后（并且不会再有新的请求）即可使线程结束，所有线程结束，程序正常退出。
FAFS电梯总结
这一次的作业较为简单，Schedule作为共享对象，InputHandler进行存储，Elevator进行拿取（由于比较简单，我没有使用Dispatcher，可拓展性并不够好）。
| method | ev(G) | iv(G) | v(G) |
| oo.Elevator.changeClose() | 1.0 | 1.0 | 1.0 |
| oo.Elevator.pickUp() | 1.0 | 6.0 | 6.0 |
| oo.Elevator.run() | 5.0 | 7.0 | 8.0 |
| oo.Elevator.send() | 1.0 | 6.0 | 6.0 |
| oo.InputHandle.run() | 3.0 | 4.0 | 4.0 |
| oo.Main.main(String[]) | 1.0 | 1.0 | 1.0 |
| oo.Schedule.getOut() | 1.0 | 1.0 | 1.0 |
| oo.Schedule.getState() | 1.0 | 1.0 | 1.0 |
| oo.Schedule.goInto(int,int,int) | 1.0 | 1.0 | 1.0 |
| Total | 15.0 | 28.0 | 29.0 |
| Average | 1.67 | 3.11 | 3.22 |
| class | OCavg | WMC |
| oo.Elevator | 3.5 | 14.0 |
| oo.InputHandle | 3.0 | 3.0 |
| oo.Main | 1.0 | 1.0 |
| oo.Schedule | 1.0 | 3.0 |
| Total | 21.0 | |
| Average | 2.33 | 5.25 |
只有Elevator的run方法复杂度较高，这是因为我将分配器（Dispatcher）以及电梯（Elevator）合二为一，没有实现真正的解耦。
bug：
本次作业较为简单，并未发现自己和他人的bug。
ASL电梯总结
由于水平较为有限，也比较怕互测被极端数据卡时间，因此采用了官方推荐ASL算法。
这次电梯作业，我采取了Dispatcher和Elevator分离的构架。
RequestList作为共享对象（即容器），InpurHandler发送新的请求信息，Dispatcher负责获取所需信息并调度电梯（Elevator）。
注：分配器是线程而电梯不是线程，避免两个线程间的安全问题。
| method | ev(G) | iv(G) | v(G) |
| oo.Dispatcher.carryGo() | 4.0 | 7.0 | 9.0 |
| oo.Dispatcher.Dispatcher(RequestList) | 1.0 | 1.0 | 1.0 |
| oo.Dispatcher.emptyGo() | 1.0 | 5.0 | 7.0 |
| oo.Dispatcher.goOut(int) | 1.0 | 3.0 | 3.0 |
| oo.Dispatcher.goOutEm(int) | 1.0 | 4.0 | 4.0 |
| oo.Dispatcher.into(ArrayList<arraylist>) | 1.0 | 2.0 | 2.0 |
| oo.Dispatcher.inWait() | 1.0 | 2.0 | 2.0 |
| oo.Dispatcher.run() | 4.0 | 5.0 | 5.0 |
| oo.Elevator.close(int) | 1.0 | 2.0 | 2.0 |
| oo.Elevator.getFlag() | 1.0 | 1.0 | 1.0 |
| oo.Elevator.move(int) | 1.0 | 2.0 | 2.0 |
| oo.Elevator.open(int) | 1.0 | 3.0 | 3.0 |
| oo.InputHandler.InputHandler(RequestList) | 1.0 | 1.0 | 1.0 |
| oo.InputHandler.run() | 3.0 | 4.0 | 4.0 |
| oo.Main.main(String[]) | 1.0 | 1.0 | 1.0 |
| oo.RequestList.getNum() | 1.0 | 1.0 | 1.0 |
| oo.RequestList.getOut() | 1.0 | 3.0 | 3.0 |
| oo.RequestList.goInto(int,int,int) | 1.0 | 1.0 | 1.0 |
| oo.RequestList.lookUp(int,int,int) | 1.0 | 13.0 | 13.0 |
| Total | 27.0 | 61.0 | 65.0 |
| Average | 1.42 | 3.21 | 3.42 |
| class | OCavg | WMC |
| oo.Dispatcher | 4.0 | 32.0 |
| oo.Elevator | 1.5 | 6.0 |
| oo.InputHandler | 2.0 | 4.0 |
| oo.Main | 1.0 | 1.0 |
| oo.RequestList | 2.75 | 11.0 |
| Total | 54.0 | |
| Average | 2.84 | 10.8 |
可以看出，对于共享对象的遍历查询（即捎带过程）的复杂度较高（表格中的lookUp方法），其实这在我的意料之中，因为判断每一请求能否捎带的确需要多重判断条件，现在想一想，把这些判断条件单独封装起来应该会更好，这是一个不足的地方。
另附上代码：
public synchronized ArrayList<ArrayList<Integer>> lookUp( int now, int waiting, int to) { ArrayList<ArrayList<Integer>> result = new ArrayList<>(); for (int i = 0; i < requestList.size(); i++) { ArrayList<Integer> tem = requestList.get(i); if (tem.get(1) == now) { if (now < to && now < tem.get(2)) { result.add(requestList.remove(i)); i--; } else if (now > to && now > tem.get(2)) { result.add(requestList.remove(i)); i--; } else if (waiting != 0 && now > tem.get(2) && tem.get(2) > waiting) { result.add(requestList.remove(i)); i--; } else if (waiting != 0 && now < tem.get(2) && tem.get(2) < waiting) { result.add(requestList.remove(i)); i--; } } } return result; }
bug：
由于我并未做实质上的优化，故强测成绩并不高，大家可能都没有测评机，因此并未发现bug。
SS电梯总结
这次作业我复用了上次作业的ASL调度算法作为每一个电梯的调度策略并扩展成了三部电梯（使用了三个分配器）。
看起来有点复杂，其实与上次作业的区别仅在于使用了三个分配器，另外我新建了SyOutput类为输出方法加上了锁以避免不安全的问题（但似乎没必要？）。
| method | ev(G) | iv(G) | v(G) |
| oo.DispatcherFirst.carryGo() | 7.0 | 10.0 | 12.0 |
| oo.DispatcherFirst.DispatcherFirst(RequestList) | 1.0 | 1.0 | 1.0 |
| oo.DispatcherFirst.emptyGo() | 1.0 | 5.0 | 7.0 |
| oo.DispatcherFirst.goOut(int) | 1.0 | 4.0 | 4.0 |
| oo.DispatcherFirst.goOutEm(int) | 1.0 | 5.0 | 5.0 |
| oo.DispatcherFirst.into(ArrayList<arraylist>) | 1.0 | 2.0 | 2.0 |
| oo.DispatcherFirst.inWait() | 1.0 | 2.0 | 2.0 |
| oo.DispatcherFirst.run() | 4.0 | 5.0 | 5.0 |
| oo.DispatcherSecond.carryGo() | 7.0 | 10.0 | 12.0 |
| oo.DispatcherSecond.DispatcherSecond(RequestList) | 1.0 | 1.0 | 1.0 |
| oo.DispatcherSecond.emptyGo() | 1.0 | 5.0 | 7.0 |
| oo.DispatcherSecond.goOut(int) | 1.0 | 4.0 | 4.0 |
| oo.DispatcherSecond.goOutEm(int) | 1.0 | 5.0 | 5.0 |
| oo.DispatcherSecond.into(ArrayList<arraylist>) | 1.0 | 2.0 | 2.0 |
| oo.DispatcherSecond.inWait() | 1.0 | 2.0 | 2.0 |
| oo.DispatcherSecond.run() | 4.0 | 5.0 | 5.0 |
| oo.DispatcherThird.carryGo() | 7.0 | 10.0 | 12.0 |
| oo.DispatcherThird.DispatcherThird(RequestList) | 1.0 | 1.0 | 1.0 |
| oo.DispatcherThird.emptyGo() | 1.0 | 5.0 | 7.0 |
| oo.DispatcherThird.goOut(int) | 1.0 | 4.0 | 4.0 |
| oo.DispatcherThird.goOutEm(int) | 1.0 | 5.0 | 5.0 |
| oo.DispatcherThird.into(ArrayList<arraylist>) | 1.0 | 2.0 | 2.0 |
| oo.DispatcherThird.inWait() | 1.0 | 2.0 | 2.0 |
| oo.DispatcherThird.run() | 4.0 | 5.0 | 5.0 |
| oo.Elevator.close(int) | 1.0 | 2.0 | 2.0 |
| oo.Elevator.Elevator(int,char) | 1.0 | 1.0 | 1.0 |
| oo.Elevator.getFlag() | 1.0 | 1.0 | 1.0 |
| oo.Elevator.move(int) | 1.0 | 2.0 | 2.0 |
| oo.Elevator.open(int) | 1.0 | 3.0 | 3.0 |
| oo.InputHandler.InputHandler(RequestList) | 1.0 | 1.0 | 1.0 |
| oo.InputHandler.run() | 3.0 | 5.0 | 5.0 |
| oo.Main.main(String[]) | 1.0 | 1.0 | 1.0 |
| oo.RequestList.check(int,int,int) | 2.0 | 5.0 | 5.0 |
| oo.RequestList.clear(ArrayList<arraylist>) | 1.0 | 3.0 | 3.0 |
| oo.RequestList.firstAvailable(int,int) | 1.0 | 1.0 | 4.0 |
| oo.RequestList.getOutFirst() | 4.0 | 5.0 | 7.0 |
| oo.RequestList.getOutSecond() | 4.0 | 5.0 | 7.0 |
| oo.RequestList.getOutThird() | 4.0 | 5.0 | 7.0 |
| oo.RequestList.lookUpFirst(int,int,int,int) | 9.0 | 15.0 | 18.0 |
| oo.RequestList.lookUpSecond(int,int,int,int) | 9.0 | 15.0 | 18.0 |
| oo.RequestList.lookUpThird(int,int,int,int) | 9.0 | 15.0 | 18.0 |
| oo.RequestList.max(int,int) | 2.0 | 1.0 | 2.0 |
| oo.RequestList.min(int,int) | 2.0 | 1.0 | 2.0 |
| oo.RequestList.ready(ArrayList<arraylist>) | 4.0 | 3.0 | 5.0 |
| oo.RequestList.reset(int,int) | 1.0 | 10.0 | 10.0 |
| oo.RequestList.returnAl(int,int,int,int,int) | 1.0 | 1.0 | 1.0 |
| oo.RequestList.secondAvailable(int,int) | 1.0 | 1.0 | 8.0 |
| oo.RequestList.separate(int,int,int) | 3.0 | 17.0 | 18.0 |
| oo.RequestList.set(int) | 1.0 | 7.0 | 7.0 |
| oo.RequestList.specialHandle(int,int,int) | 1.0 | 5.0 | 9.0 |
| oo.RequestList.thirdAvailable(int,int) | 1.0 | 1.0 | 6.0 |
| oo.SyOutput.initStartTimestamp() | 1.0 | 1.0 | 1.0 |
| oo.SyOutput.println(String) | 1.0 | 1.0 | 1.0 |
| Total | 123.0 | 236.0 | 287.0 |
| class | OCavg | WMC |
| oo.DispatcherFirst | 4.625 | 37.0 |
| oo.DispatcherSecond | 4.625 | 37.0 |
| oo.DispatcherThird | 4.625 | 37.0 |
| oo.Elevator | 1.4 | 7.0 |
| oo.InputHandler | 2.5 | 5.0 |
| oo.Main | 1.0 | 1.0 |
| oo.RequestList | 4.79 | 91.0 |
可以看出来，绝大多数的方法复杂度均较低，问题还是出现在共享对象的遍历上，这一点是我下一单元改进的重中之重。
bug：
这一次，我和其他同学共同搭建了测评机，用来自测和互测（也想当一回【假】狼人）。
但我这个废物测评机竟然在我手里没有发现任何bug（其他使用这架测评机的同学都或多或少地找到了自己和他人的bug，我好气啊~~）。
上周五与一位真·大佬聊天，他告诉我测评机的数据过于随机，可能找不到潜藏较深的bug，看来以后，我也需要读一读同组同学的代码，取长补短的同时，也可以顺便找找bug（究竟哪个是顺便😊）。
注：特别鸣谢何岱岚同学，让菜鸡拥有了搭建测评机的可能。
电梯载人策略图示
SOLID自评
SPR（单一责任原则）：几乎实现了一个类只负责一项工作，但其实也可以将这些类进一步细化，划分成更多的小类，每个类负责更细化的工作。
OCP（开放封闭原则）：感觉还可以，但可拓展性尚需进一步加强。
LSP（里氏替换原则）：没有用到继承（线程类除外）。
ISP（接口分离原则）：没有用到接口。
DIP（依赖倒置原则）：感觉做的不太好，构架的抽象程度不充分，仍然有面向过程的影子。
写在最后
心得与体会
多线程其实蛮有趣的（如果它们不是那么不听话的话），这也是我们将来走上工作岗位的重中之重，经过了两个单元，我也渐渐的适应了OO和OS的双重夹击（即天天熬夜）； //为将来996做好了身体上的准备
虽然很累，但是真的学到了不少有用的知识和技能，提升了自己的核心竞争力； //离996岗位更进了一步
第三次作业有幸分到了A组，见到了许多大佬的代码，让我更加领会到了面向对象的含义和优秀的架构，今后我会继续学习大佬们的代码风格，争取可以活(xian)学(xue)活(xian)用(mai)。
虽然不知道下次作业是啥，但肯定和多线程脱不开干系，继续努(ao)力(ye)吧。
愿指引明路的苍蓝星为我们闪烁
