电梯控制java代码 java实现电梯调度算法

转载

kekenai 2024-01-10 18:58:15

文章标签 电梯控制java代码生产者-消费者多线程设计模式 文章分类 Java 后端开发

1 概述

本单元我基于Java完成了一套多线程电梯运行与调度模拟系统。本文中我将按本单元3次作业的迭代顺序，总结我的设计思路与关键实现细节。通过本文，你可以了解到：

简单的Java多线程设计模式
多线程程序的增量开发方法

2 作业回顾

2.1 第一次作业

本单元实现了北航新主楼A-E座共享输入单电梯系统。

2.1.1 代码架构

|- MainClass: 程序运行入口
|- Launcher: 启动器
|- Revceiver: 输入接收器
|- Distributor: 请求调度器
|- Elevaor: 电梯
|- buffer: 输入队列包
    |- DistributorBuffer: 调度器输入队列
    |- ElevatorBuffer: 电梯输入队列

我设计了如上类以完成本系统。

Receiver 与 Elevator 是两个必要的线程类。Receiver 需要不断阻塞等待请求输入，Elevator 需要模拟电梯运行中的行动时间，均无法与主线程同步。
与主线程同步的是Distributor类，相当于第3个线程。
程序启动后，MainClass 调用 Launcher 创建各类一定数目的对象，并启动上述两个线程类的对象，然后将控制权交给 Distributor。
Distributor 作为 Receiver 的消费者，Elevator 的生产者，不断将从 Receiver 接收到的请求分发给对应楼座的 Elevator。

2.1.2 同步块与锁

由代码架构可见，本次作业中我使用了两级生产者-消费者模式，线程之间使用共享对象进行数据交互。所以，两个线程共享类DistributorBuffer和ElevatorBuffer的各个方法即为程序中的所有同步块，我使用synchronized修饰符对它们加锁。

以 Receiver-DistributorBuffer-Distributor 组成的生产者-消费者模型为例进行分析。Disributor 不断使用 DistributorBuffer 的getAll()方法获取新的请求，但若队列为空，并且 DistributorBuffer 的receiving标志仍为true（若为false则结束运行）的情况，该方法则会使用wait()将 Distributor 线程阻塞，直到被 Receiver 线程唤醒。Receiver 获取输入请求后，若请求不为空，则调用 DistributorBuffer 的add()方法，将请求放入队列中；若请求为空，则说明输入结束，则调用 DistributorBuffer 的StopReceiving()方法，将 DistributorBuffer 的receiving标志设为false。以上两个方法均会使用notifyAll()唤醒被阻塞在 DistributorBuffer 的 Distributor 线程。
Distributor-ElevatorBuffer-Elevator 组成的生产者-消费者模型与之类似，但有以下两点不同：

存在多个楼座的ElevatorBuffer-Elevator，Distributor 根据请求的楼座对其进行分发，属于单生产者-多消费者模型；
ElevatorBuffer 可以根据一定条件从队列中获取元素。

2.1.3 调度器与策略

由上文可以看出调度器 Distributor 的任务非常简单：根据楼座将乘客请求放入到对应的电梯输入队列 ElevatorBuffer 中。
电梯则以一种类似有限状态机的方式运行，每次停靠在新的一层，电梯进行以下操作：

检查是否有乘客要出去。如果有，则开门让他们出去；
检查是否有乘客要进入。如果有，先检查门是否打开，若未打开则先打开门，最后让他们进来；
根据电梯与等待队列的状态上行或下行：

若电梯中有乘客，则以最先到达的乘客的方向为目标方向；
若电梯中没有乘客，则使用 LOOK 算法在ElevatorBuffer中搜索下一个目标乘客，以他所在方向为目标方向。

2.1.4 心得体会

本次作业我学习到了如何使用Java创建多个线程并行工作，并且学习到了如何使用锁与wait-notify让各个线程之间有序且高效地进行交互。刚开始着手设计本次作业的程序时，各种复杂的交互让我难以下手，但通过对生产者-消费者设计模式的学习，一切都变得清晰起来。

2.2 第二次作业

第二次作业加入了(1)在楼座间运行的横向电梯，(2)同楼座/楼层多电梯系统，（3）动态电梯创建请求。

3.2.1 代码架构

|-com
    |- distributor
        |- Distributor: 调度器基类
        |- MainDistributor: 主调度器
        |- SubDistributor: 子调度器
    |- elevator
        |- Elevator: 电梯基类
        |- HorElevator: 横向电梯
        |- VerElevator: 纵向电梯
    |- Launcher: 启动器
    |- Receiver: 接收器
    |- RequestQueue: 请求队列
|- MainClass: 程序入口

本次作业中我新增入了横向电梯类和子调度器类，并对代码结构做出了一定调整。

子调度器存在于电梯于主调度器之间，负责为同一楼层/楼座的电梯分发请求；
调度器的运行逻辑仅有请求分发逻辑不同，将这些部分作为抽象方法留给子类重写，其余部分均在集类实现；
电梯的运行逻辑仅有出入条件和方向决定逻辑不同，将这些部分作为抽象方法留给子类重写，其余部分均在集类实现；
合并所有共享对象为RequestQueue类，仅保留基本操作作为方法，复杂访问与修改逻辑由访问者提供；

2.2.2 同步块与锁

本次作业与第一次作业的同步块基本相同，依然采用多级生产者-消费者模式，以生产者与消费者的共享队列作为同步对象。并且将所有共享对象合并为RequestQueue类，仅保留基本操作作为方法，复杂访问与修改逻辑由访问者提供，以提高实现的可靠性。

2.2.3 调度器与策略

本次作业中主调度器的逻辑与第一次作业调度器相同，只是增又加了子调度器以完成同楼座/楼层多部电梯之间任务的分配。子调度器会将新的请求分发给等待队列最短的电梯。
可见，每个电梯依然有一条独享的输入队列，其运行策略与第一次作业相同（横向电梯类似，但不使用LOOK算法，而使用ASL）。

2.2.4 心得体会

刚开始我以为本次作业十分复杂，但经过分析发现经过请求的分配后，各个电梯之间的运行可以是独立的，它就没有任何难度了。使用生产者-消费者模式再创建一个层级，即可轻松完成。经典设计模式十分实用。

2.3 第三次作业

第三次作业加入了(1)只有通过换乘才能满足的乘客请求，(2)创建个性化电梯的请求。

2.3.1 代码架构

|-com
    |- distributor
        |- Distributor: 调度器基类
        |- MainDistributor: 主调度器
        |- SubDistributor: 子调度器
    |- elevator
        |- Elevator: 电梯基类
        |- HorElevator: 横向电梯
        |- VerElevator: 纵向电梯
    |- DynamicPersonRequest: 动态乘客请求
    |- Launcher: 启动器
    |- Receiver: 接收器
    |- RequestQueue: 请求队列
|- MainClass: 程序入口

本次作业我通过增加DynamicPersonRequest类，对PersonRequest类进行扩增，在最小改动已有代码的情况下实现了新的需求。

DynamicPersonRequest请求重写PersonRequest的getToFloor()与getToBuilding()方法，动态获取单步目的地；
乘客离开电梯后，会被重新送回主调度器进行进一步处理，这形成了流水线设计模式。

2.3.2 同步块与锁

本次作业与第二次作业仅有一处不同：电梯也可以作为主调度器的生产者，出现了多生产者-单消费者模式。但依然在原架构适用范围内，无需进行改动。

2.3.3 调度器与策略

调度器工作模式与第二次作业相同。唯一值得注意的是，主调度器此时的运行结束条件发生了变化，需要等所有乘客请求完成后才能终止。我通过在主调度器中增加一个集合记录分发出的所有乘客请求，并在该请求被电梯返回且已经完成时删除它，只有该集合为空时主调度器可以结束运行。

本次作业新增了换乘策略，我将它封装在动态乘客请求中。动态乘客请求维护了一个静态变量，记录了所有横向电梯的停靠信息（可以在哪些楼座停靠），以此获得自己的换乘楼层。对于外部，动态乘客请求“伪装”成一个PersonRequest，在其当前楼座与目标楼座不同时，其getToFloor()方法返回其换乘楼层；当到达目标楼座后，其getToFloor()方法返回其最终目标楼层。

2.3.4 心得体会

本次作业加入了最让我担心的换乘需求，由于我程序架构中的各个电梯是独立运行的，所以我并没有想出一个简单的方法让它们之间进行换乘交互。直到理论课上我学到了open-close原则，我开始思考如何更充分地利用现有的代码，而不是在遇到问题时总是推倒重来。
第二次作业中，我的程序架构已经可以完美地满足同一楼座或同一楼层内的请求，要让它完成一个需要多次换乘的请求，势必要将这个请求多次投入到我的电梯系统中。这并不难实现，只需要将从电梯出来的乘客再次投入主调度器的输入队列即可。难点在于如何使我的电梯系统知道换乘乘客需要在何处离开电梯，这会让我原本架构的复杂度极大提高，与安全简单的设计原则相悖。于是我干脆转换思路，不对原来的功能进行修改，而是扩展PersonRequest类的功能，让它在换乘的每一个阶段“伪装”成一个无需换乘的请求，通过多次投喂给我的电梯系统，完成它的最终目的。
我继承PersonRequest类，扩展了DynamicPersonRequest类，重写了它的getToFloor()与getToBuilding方法，仅对原有代码进行了最小的修改，就实现了全新的需求。

3 BUG分析与修复

3.1 测试策略

本单元作业我主要使用黑箱测试进行自动化评测。

3.1.2 测试样例生成

我将请求分为5类：纵向电梯创建请求、横向电梯创建请求、纵向乘客请求、横向乘客请求、换乘乘客请求。在生成测试用例时，我在初始时刻会首先生成一定数量电梯创建请求，然后对各类请求，设置参数按照一定时间间隔和一定数目进行生成。

3.1.3 输出结果检查

我为存在的每一个电梯与乘客建立一个跟踪器对其状态进行监控。每当出现新的与该电梯/乘客相关的输出时，对应跟踪器进行以下两项检查：

该电梯/乘客当前的状态是否可以执行此动作；
该电梯/乘客执行此动作后是否转移至正确的新状态。

3.2 BUG修复

本单元中，我的程序共出现了两处BUG：

电梯运行日志输出不同步
电梯可进入人数判断错误
第一处BUG出现在各电梯使用官方提供的TimeableOutput包输出运行日志时，未进行同步处理，导致输出时间戳不递增。这说明我对多线程同步问题尚不够敏感，应该仔细使用 Berinstein 原则对各线程调用的每一个方法进行分析，直到可以熟练地找出所有同步块；
第二处BUG是由于循环中首先进行操作，再进行break判断导致的。不幸的是这一点在我使用随机数据的数百轮测试中都没有暴露出来，这说明随机测试虽然可以检测出大多数BUG，但是绝对不能仅仅依靠随机测试对程序进行测试。