BUAA_OO 第二单元
(1)同步块和锁
1.在三次作业中都使用了synchronized修饰方法的方式进行同步和加锁, 对共享对象的所有方法都进行了加锁设置.
2.为了确保输出的线程安全,对输出函数进行封装加锁.
3.为了满足能够对新输入请求及时相应,在电梯运行线程中对共享对象的某些操作进行了加锁处理,从而达到与输入线程交互的目的.当某电梯的请求队列为空时,运行下列代码,从而避免轮询以及对新请求立即相应.
synchronized (outQueue) {
try {
outQueue.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
notifyAll();
}
4.如果某一时刻所有请求已经获得完毕,且某电梯不在运行中其请求队列同时为空,在前两次作业中即可判断本电梯可以结束运行, 但是在第三次作业中无法确定这一电梯在未来时刻不会再有人进入,所以需要判断什么时候所有请求才全部处理完成. 为此新增了一个请求队列requests存储所有请求,以下代码用于判断何时结束,加锁的目的是对请求的状态改变及时相应.
for (Request item : requests) {
while (true) {
if (item.getNewState() == -1) {
break;
}
synchronized (item) {
try {
item.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
(2)调度器
在三次作业中均没有实现调度器类,调度器功能是由输入线程和电梯队列类中的方法共同实现的. 当有请求输入时,由输入线程将请求传送给相应的电梯队列, 在电梯队列中决定将请求传给哪个电梯.而电梯中的请求队列获得新请求后, 由于电梯运行线程直接面向该电梯的请求队列,所以电梯运行时可以当即对该请求做出反馈.
(3)类图和时序图
第一次作业类图:
第一次作业采用生产者消费者模式,输入进程是生产者, 存在多个托盘即为每个电梯对应的等待队列,每个电梯都是一个消费者,只能消费本电梯对应托盘里的产品. 电梯运行采用ALS策略,判断在何时应该开关门以及是否捎带.
第二次作业类图:
第二次作业相较于第一次作业添加了横向电梯,即给托盘和消费者分类,根据请求种类决定电梯运行方向.在某楼座有多个电梯同时运行时,将新请求分配给电梯内人数最少的电梯.
第三次作业类图:
第三次作业同一个乘客可以进入多个电梯,所以采用流水线架构,让乘客依次进入不同电梯.一位乘客从出发地到目的地的过程可以总结为3个过程,即纵向-横向-纵向,那么通过BitSet存储乘客是否需要经过某个电梯,1代表需要,0代表不需要.如果某乘客只需通过一个纵向电梯就能够到达目的位置,那么该乘客只需要经过第三个过程.如果某乘客需要经过横向电梯,在该请求刚刚通过InputThread进程获得后,立刻为该请求决定未来要进入的横向电梯,之后将该请求分配给纵向电梯到达该横向电梯所在的楼层,此时即可将该请求第一个过程对应的BitSet位设为0.然后依次进入下一个电梯.
时序图:
(4)分析自己程序的bug
前两次作业没有发现bug,第三次作业中存在两个bug.
1.若输入的请求只需要在一个楼座进行转移,此时应当将当前的temFromFloor设为该请求的fromFloor,而我在代码中错误的设置成了0.修复办法是将0改为fromFloor.
2.当横向电梯位于不能开电梯门的某座时,如果此时主请求为null且请求队列不为空,因为获取主请求的代码位于if(可以开门)的代码块中,所以既不会让电梯停止,也无法移动,导致电梯一直在这一位置轮询.修复办法时在if代码块外刷新主请求.
(5) 心得体会
线程安全:通过synchronized对方法和类进行加锁,同时使用notifyALL()唤醒其他进程. 另外,值得注意的是,我们常用的ArrayList类并不是线程安全的,可以使用线程安全的CopyOnWriteArrayList类.
层次化设计:在本单元中没有用到继承和接口实现,层次化主要体现在数据的组织结构上, 新增电梯和新增请求都是基于这种数据结构完成的. 从一个请求到一个请求队列,每个电梯又包含一个请求队列,而同层或同座电梯又构成队列,
