oo第二单元作业总结

oo第二单元博客总结

在第一单元求导结束后，迎来了第二单元的多线程电梯的问题，在本单元前两次作业中个人主要应用两个线程，采用“生产者-消费者”模式和共享数据变量的方式解决问题。在第三次作业中加入多个电梯线程以后，沿用之前的模式，但是在控制线程的地方进行了部分相应的修改保证任务的完成。

第一次作业—傻瓜电梯

第一次作业是没有任何调度算法的傻瓜电梯，生产者生产请求，将请求加入存储的仓库队列。消费者消费请求，循环从仓库中取出请求，取出一个请求即运送他，直至运送完毕后，再进行循环。

下面是第一次作业的类图，个人感觉还是比较清晰的。

此次作业中由于几乎没有调度要求所以没有查找到bug。

第二次作业—als调度电梯

第二次作业中加入了一些新的调度要求，要求在运送请求的过程中进行捎带，以减少电梯的运行时间。自己的设计主要是在第一次作业的基础上，在电梯运送主请求的过程中，在每一楼层与仓库队列进行交互，查询是否有可以进行捎带的请求，是否可以有从电梯中出去的请求。（本人比较菜，没有进行过多的算法优化，所以此次的作业在保证了简单的正确性的情况下，收获的性能分却很低。

此次自己设计的调度比较简单，所以没有被查找到bug。因为没有自己的测评机，所以在测评中主要用了暴力输入的方式，导致效率非常低下，并且也没有找到别人的bug。

第三次作业—多线程智能电梯

第三次作业加入了更多更加复杂的要求，电梯能够到达的楼层不同，电梯所能够承载的人数不同，这两点是在本人设计电梯的过程中最主要的两点要求，也是在本次作业中本人踩坑的地方。自己的设计主要采用了暴力分配的方法，仓库队列中每进入一个请求，对于请求先进行拆分，如果可以直达，则不进行多余处理；如果不能直达，则一定可以通过一次换乘到达终点，将请求处理完毕后加入仓库队列。电梯线程的设计沿用第二次als调度电梯的设计，在能够到达的楼层与仓库队列进行交互。

第三次作业中个人遇到很大的困难是如何判断电梯线程的停止。由于出现了换乘，所以前两次作业中通过判断输入停止和仓库队列为空的方法不再适用，最终的解决方法是在仓库队列中加入一个人员队列存储所有的请求，只有请求到达最终的终点后才能够从队列中清除掉，将这个人员kill掉，最终的电梯线程停止的判断条件变为输入停止和人员队列为空。

此次电梯的设计出现一个非常愚蠢的bug，就是在电梯判断捎带的过程中，没有判断在该楼层能否停靠，导致了严重的bug。

这是画出的这三次作业的简单的处理图，在第三次中加入了下方的处理类，先将请求进行处理后再进行其他的处理。

心得和体会

这三次多线程作业主要考察的难点就是在线程安全的设计和调度运行的优化等方面，线程安全我主要是采用synchronized同步机制,来锁住输入线程和电梯线程的对于共享变量的操作方法；如果仓库队列为空，则使用wait()和notifyAll()来释放锁和唤醒线程。调度运行的优化方面其实我没有做很多工作，没有成功地加入观察者模式，也没有加入完整的scanner算法，只是进行了简单的捎带简化，因为本身之前对于多线程了解不清晰，在作业中更多的设计主要是想确保线程的安全性。

其实在此次第三次作业中踩了很大的坑，现在回过头来反思，其实很大的原因是课下自己测试的不足，代码测试的重要性是绝对不容许被忽视的。