OO第二单元总结

历次作业分析和总结

第一次作业：在第一次作业当中我们并没有过多的设计多线程的内容，只是简单的把乘客的请求放到电梯运行的队列中，因此简单的开了电梯调度的线程，为之后的两次作业做更好的铺垫。

在第一次作业中，我简单的写了一个对于输入请求的调度器，对输入请求进行调度，并在电梯运行时设置调度器相应的接口，并写好了简单的傻瓜电梯运行，这样就是对于本次作业来说需求就已经可以得到满足了。

 

 

第二次作业：在第二次作业中再第一次作业的基础上增添了可捎带人员的要求，因此需要对调度器以及电梯运行做一些调整了。在这里我在电梯调度的类中增设了一个存储电梯中人员的队列，并根据电梯运行到每一层的时候增设调度器的接口，从中接进在当前楼层且满足调度需求的人员进入电梯，从而实现电梯的可捎带功能。

 

第三次作业：在第三次作业中涉及到多线程多电梯的调度，并在其中加入了许多关于电梯运行的要求，以及会由于电梯运行层数的关系出现的乘客需要换乘的情况，同时这里也会涉及到线程安全的问题，因此需要在调度器以及电梯调用上面进行一些大改。

首先，在调度器中，我们设置了4个队列，分别对应需要A,B,C3个电梯以及需要换乘的等待队列。在调度器中，我们将可以直达的乘客先存入ABC对应的三个队列中，并提前为需要换乘的选手先分开所需要分乘的两部电梯，先将前一部需要运行的电梯先存入ABC三个电梯，然后再将后面的需求存入等待队列中，在前半部分的运行结束之后既可以将等待队列中的该乘客重新存入ABC对应的队列当中。而在电梯的运行类当中，我们首先在第二次作业的基础上ABC三个电梯对应运行的特征量（电梯运行时间，乘客上限等），然后在之后将应用类似于作业二的可捎带的电梯调度的方法处理电梯运行。之后再电梯调度的run方法里设置相应的调度锁，即完成本次作业的需要。

 

 

自我评价

首先，我的认为的这三次作业所采取的整体设计结构还是基本一致的，都是使用了调度器这一中间量来对输入乘客的请求进行调度，将乘客存入相对应的等待队列当中，并从作业二开始增设了电梯自己运行时的乘客队列，实现可捎带功能，在处理线程冲突这方面，我主要则是在类中存在多个线程可能同时使用的地方加锁，以确保自己程序的线程是安全的。但是在我的程序中，是存在设计上面的缺陷的，对于电梯的判断是否运行，我采取的是sleep轮询的方法，而不是使用noitfy和wait的方法进行处理，这样则可能会导致线程运行的时间间隔小于轮询所用的时间则可能会出现问题

 

分析bug

在这几次作业中，前两次的作业主要是电梯运行的正确性的bug，这里就主要是需要查看电梯调度的问题。而在第三次作业中，由于存在多个进程，则需要判断进程结束的条件，否则则会出现需求存在而某个电梯线程提前结束的情况出现。

在bug的测试环节，由于多线程的bug难复现性，我们不能够想第一单元中的测试一样简单的输入输出，而是要考虑到时间对于结果的影响，我主要是进程覆盖性测试，最简单的在某一时刻同时输入多个请求，然后查看程序的正确性，之后我通过datacheck构造在不同时间段输入的请求判断结果是否正确，以此来进行正确性的判断。

 

心得体会

从线程设计安全的角度上来看，我们主要还是要明确在什么地方是可能存在着线程隐患的，即进一步的讲，什么地方要加锁，什么地方不需要加锁，通过对存在线程安全隐患的地方加锁来达到实现线程设计安全的目的。同时，也要防止死锁的情况出现。

从设计原则的角度上看，我上次作业主要是采取了消费者和生产者的策略，通过调度器，即相当于托盘，存储生产者的资料，将资料以队列的形式传递给消费者（即电梯），在电梯中将生产者的资料（即乘客）送达楼层，以完成调度。