OO第二单元总结

OO第二单元总结

概述

OO第二单元的主题是多线程电梯，分为傻瓜式电梯，带捎带的电梯，以及多部捎带电梯的协同运作。这是我第一次从单线程到多线程的过渡，不管是多线程的调试还是测试都给我带来了不少的麻烦，但不管怎么说，我在这一过程中还是收货颇多的。

第五次作业

思路： 第一次电梯作业我的架构十分简单，调度器就是队列，开了一个输入线程一个电梯线程，以单例模式建立调度器队列，实现两个线程之间的交互，第一次作业我并没有使用notify和wait方法，而是使用yield类似于暴力轮询的处理方法，毫无疑问这么做导致了较高的cpu时间。这次几乎没有什么调度策略，有人来就先让电梯运输他。

第一次作业比较简单明了，用调度器队列在输入线程与电梯线程之间交互即可，类的作用分离比较清晰，复杂度也不是很高

第六次作业

思路：第六次作业我完全沿用了第五次作业的架构，调度器依然只有一个队列，唯一的不同是调度方法出现了变化，相较于傻瓜式电梯，这次实现了可捎带的功能，增加了电梯运行的效率，采用了指导书提供的方法，先创建一个主请求，剩余请求如果满足条件就进行捎带，在加入的过程中为了进一步提高效率主请求是会不断改变的。这里我觉得电梯的结束条件是比较难判断的，如果像第一次一样使用yield就会导致很高的cpu时间，这里我用wait和notify的时候没有严格保证调度器队列的线程安全从而导致可能出现错误。在运行时的条件判断也考虑不周导致电梯可能出现死循环的情况。

第二次作业几乎沿用第一次作业的设计，唯一的不同就是电梯运行模式的改变，输入线程的接受输入我完全用一个方法来完成，电梯线程的运行我也只开了一个方法，分离度并不理想，move函数的复杂度较高，其实可以将请求再单独开一个类，并进一步细分move操作来进行优化。

第七次作业

思路：第七次作业因为有三部电梯的协同运作，所以我认为单纯的调度器队列已经无法满足要求，因此我对我的程序进行了一次重构，可捎带电梯仅仅根据自己的捎带原则去运行，而调度器线程负责给这三个独立的电梯线程传输任务，调度器的调度原则是先给A，再给B，再给C，因为A速度最快，B其次，C最慢，非常朴素的想法，但是这种调度的话会导致C的运行效率要比A和B低很多，经常处于无事可做的等待状态，在使用JProfile分析时也发现了这个问题，但是因为自己的惰性我并没有去修改这个问题。这里我使用了四个队列，输入线程和调度器之间的队列，调度器和三个电梯线程又各自有一个队列，均使用单例模式创建且保证线程安全。这里我感觉比较麻烦的是各个线程之间的交互，尤其是拆分指令的存在，指定了拆分的前一条指令必须要在后一条指令之前执行，而多线程的执行顺序往往是很难控制的，所以我牺牲了一部分效率，在前一条拆分指令执行完之前不对后一条拆分指令进行分配。

第三次作业创建了三个电梯线程，而且是独立创建，其实这三个电梯的操作有大量相似之处，如果用继承来创建的话应该会简化结构。这次不仅有三部电梯之间的协作，而且由于拆分指令的存在以及各个线程之间的交互，我加了很多控制语句，导致方法的复杂度都比较高，电梯自身的运行流程也比较复杂，在电梯类依然需要自己决策判断指令的执行顺序，可以看出耦合度还时较高，真正理想的设计应该是电梯只管运行，执行顺序全部由调度器来管理，然后自身水平有限，并没有实现这样的架构。

标签：OO,总结,队列,作业,调度,捎带,电梯,线程,单元
来源： https://www.cnblogs.com/KSMLighter/p/10761014.html