OO第二次博客作业

OO第二次博客作业

一、从多线程的协同和同步控制方面，分析总结三次作业的设计策略

第一次作业

多线程的协同：

本次作业采用生产者-消费者模式进行设计，搭建了主线程、电梯线程以及请求队列。

本次作业没有搭建调度器。一部电梯调度个锤子。

主线程读取请求后，直接将请求放入请求队列，电梯线程从请求队列中读取请求并执行，主线程读取请求结束后，电梯线程处理完所有请求自动结束。

多线程的同步控制：

请求队列作为主线程和电梯线程的共享对象，设计为线程安全的，使用 synchronized 关键字进行方法级的同步控制。

第二次作业

多线程的协同：

本次作业在第一次作业的基础上新增调度器，且并未将其设计为线程。调度器负责请求向若干个电梯的分配。

多线程的同步控制：

与第一次作业相同。

第三次作业

多线程的协同：

本次作业涉及电梯种类不同，因此将多部同种电梯和相应的调度器（沿袭第二次作业）封装为一个电梯子系统，同时新增一个主调度器负责请求向若干个电梯子系统的分配。

多线程的同步控制：

电梯子系统的同步控制细节与第二次作业相同。

考虑到新增的主调度器处理的请求来自两方面——主线程读取、子系统上传（人员换乘），因此需要设计为线程安全的，使用 synchronized 关键字进行方法级的同步控制。

二、从功能设计与性能设计的平衡方面，分析和总结自己第三次作业架构设计的可扩展性

功能设计：

第三次作业为多部多线程可稍带调度电梯。

性能设计：

单部电梯，采用 LOOK 算法进行调度。

多部电梯，调度器分析每部电梯由当前所在位置运行至乘客所在位置耗时，并依此作为请求分配依据。由于电梯运动方向何时更改未知，当电梯内无乘客，且电梯运行方向上的更高楼层无乘客等候时，电梯则会更改运动方向，因此仅计算最坏情况（电梯运行至顶层或底层才掉头）下的接客耗时。当多部电梯的接客耗时差别不大时，调度器采取随机分配策略，以保证电梯负载均衡。

人员换乘方面，固定换乘楼层（1/5/15），固定换乘次数（1）。

总体而言，可扩展性一般，针对电梯种类而言，可扩展性较好，针对电梯可达楼层而言，可扩展性一般。

三、度量分析

第一次作业：

方法复杂度：

代码行数：

类图：

第二次作业：

方法复杂度：

代码行数：

类图：

第三次作业：

方法复杂度：

代码行数：

类图：

四、分析自己程序的bug

三次作业在强测和互测中均未发现bug。

五、分析自己发现别人程序bug所采用的策略

由于本人没有评测机，且懒，因此在互测中基本处于隐形状态。人不犯我我不犯人。

六、心得体会

三次作业中的第一次作业给我造成了最大的阻碍，真·万事开头难。而后发现，只要理清线程间的协作关系以及共享对象，多线程还是很有意思的。