OOUnit2

面向对象第二单元多线程总结

(1)设计策略

• 第一次作业策略

  第一次作业单个ALS电梯，构建了三个线程类，调度器，电梯，输入管理。主线程中创建这些子线程，输入线程和调度器控制停止信号，电梯类和调度器通过生产者-消费者模型，通过synchronized块实现数据的共享。调度器和电梯通过创建的一个RequestQueue类进行人请求的管理，通过一个FloorQueue类细分每一层的进出请求。调度算法通过电梯和请求的方向来判断是否捎带。

• 第二次作业策略

  第二次作业加入了多个电梯，根据输入控制电梯总数，每个电梯的自调度算法和第一次作业相同，另外加入总调度器的算法，把请求随机分配给每个电梯。

• 第三次作业策略

  第三次作业新增了动态的电梯加入以及换乘，复杂度过高没能想到合适的解决策略。

(2)可扩展性

• 第一次作业

  第一次作业满足每个类执行自己的职责，电梯和调度器分开，调度和输入管理分开。

• 第二次作业

  第二次作业没有用到类的继承，重构了调度器满足分配给多个电梯。

• 第三次作业

  没有实现

(3)基于度量分析

第三次作业没有实现，第二次作业出现暴力轮询ctle，给出第一次作业的度量分析：

• 第一次作业

  • UML图

    

    调度器、电梯、输入管理之间的关系

  • 方法复杂度

    

  • 类复杂度
    

    调度器臃肿复杂度高，电梯只处理自身上行下行存储请求列表，和调度器之间不够平衡。

(4)分析自己程序的bug

• 线程不安全，死锁的产生

  一开始我调度器和电梯还有输入管理之间职能划分不够细，耦合度较高，调度器在输入结束的时候会等待输入和电梯状态的变化，电梯在调度的时候会询问调度器有没有新请求的加入，最终会导致调度器和电梯互相等待进入死锁。解决方法为新增Tray类利用生产者-消费者模式，满足调度器和电梯之间的请求共享，由tray自行判断避免饥饿。同时输入管理类加入结束信号，调度器和电梯共享结束信号，当调度器收到结束信号并且传入所有请求给电梯时结束调度线程，当电梯收到结束信号并且电梯内没有未处理请求时结束电梯进程。

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

• 构建边缘数据测试样例

(6)心得体会

• 多线程的调试极其麻烦，不能设置断点，通过打印方式来寻找bug，通过研讨课上学习到的log打印进行调试。