BUAAOO 第二单元总结

第二单元总结

（1）总结分析三次作业中同步块的设置和锁的选择，并分析锁与同步块中处理语句之间的关系

三次作业中的锁设置基本一致——对请求队列（requestQueue）加锁。电梯线程调度时需要拿到锁，有乘客到来的时候读入线程也需要拿到锁。
第一次作业中，由于刚刚接触到电梯，同步块设置过多，导致电梯运行代码被编写到了requestQueue同步代码块当中，导致每次只能上下一名乘客。电梯运行的时候不能读取乘客。在性能和正确性上有很大不足。
第二次作业中，更正了第一次作业的错误，将电梯的调度拿了出来。再次开辟一个新的线程用于生产电梯。
第三次作业中，给每个电梯自己的调度策略。
三次作业锁的设置均为requestQueue。当电梯线程需要上下人的时候，和Input线程增加等待乘客的时候需要同步requestQueue。

(2)总结分析三次作业中的调度器设计，并分析调度器如何与程序中的线程进行交互

三次作业中均没有一个总调度器，或者说，三次作业的每个电梯都有自己的调度策略，与其他电梯无关。
第一次作业电梯的调度策略很简单。判断电梯中是否有乘客，没有乘客就选择最近的楼层作为目标楼层。如果电梯中有乘客，就将电梯中第一个乘客的目标楼层作为电梯目标楼层。每次到达一层，都判断本层是否有人要下电梯，是否有人要上电梯。如果有人下或者上电梯，那么就停下开门，如果没有就再次向目标楼层移动一楼。
第二次作业中，每个电梯的调度策略不需要改变，只需要增加更多的电梯即可。也就是有一个请求到达，所有电梯都将行动起来。
第三次作业中，有三种不同类型电梯，就要写三种不同的调度策略。就是不同的电梯判断乘客下电梯和上电梯的逻辑不同。每种电梯都按照自己的运行规律运行，每个乘客都将逐渐逼近自己的目标楼层。
此类调度方法没有一个总调度器，而是各自为战，每个电梯都按照自己的行为方式运行着。

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

由于架构基本未变，三次类图与时序图基本一致
类图：

电梯调度器时序图

电梯调度器当中实现了许多判断是否上下电梯，是否有人等，电梯开关门，上下移动之类的逻辑。
从类图看，主要分为三个线程，电梯线程，电梯工厂线程，输入线程。电梯线程根据电梯种类不同编辑相应的运行策略，电梯工厂用来启动电梯，输入线程用于增加电梯请求和乘客请求。
作业的可扩展性：在电梯种类上的扩展。只需要编写新的电梯类型的调度策略即可。在电梯功能上的扩展：仅仅支持上楼速度等这些量的参数化。如果的电梯有新的功能，比如搭载意大利炮的专用电梯等，需要重新构建电梯，重新编写请求表重新设计架构。在电梯数量上的扩展：增开新电梯即可。
因此：本调度策略的优点在于，各自为政，可以减少相互关联的调度复杂度。
本调度策略的缺点在于，各自为政，因此在视觉观感上电梯运行混乱，运行效率较低但是可以接受。

(4)分析自己程序的bug

第一单元中出现了调度器编写错位的bug调整位置即可。
由于采用两个表requestQueue，waitTable，在一些地方的编写上出现了死锁。通过阅读代码，静态调试也进行了良好解决。

(5)分析自己发现别人程序bug所采用的策略

人工编写测试数据。
但是多线程没有炸到人。没有发现别人的bug。

(6) 心得体会

我认为自己拥有了一定面向对象的思想
我思考了：什么是电梯？电梯应当有什么类型的封装？对外应当提供什么类型的接口？什么是调度？调度器应当有什么特点？（尽管最后将调度器与电梯合在了一起）
另外，多线程debug，看着自己的电梯从无到有，能正常跑起来。就感觉自己十几个小时的辛苦没有白费。也是一种奇妙的感觉。
总的来说，OO真是一个奇妙的旅程。