「BUAA OO Unit 2 HW8」第二单元总结

既然在LOOK算法下的电梯一般会一直保持一个方向行进，那么在分配请求时，我们就可以迎合这个特性，为其分配迎合其方向的请求，对于停层的电梯，就将它视为朝两个方向运行的电梯，与前一种电梯共同判断谁离这个请求出发楼层最近，然后把这个请求丢给它的分请求池。这样就可以保证在这种情况下，这个请求是被最优处理的。

当然，也会出现六部电梯都朝同一个方向运行，而请求在反方向的情况，在这种情况下由于并无法计算让哪一步电梯去处理该请求最优，所以我采用了将其分配给当前电梯里请求最少的电梯。这样可以让它尽早被处理。

1.2.3 性能指标适应度

首先在电梯内部的调度中，采用LOOK算法，保证了单电梯时间与电量做到我所能做到的最优。

其次在电梯之间的调度中，采用自己创造的配合Look算法而产生的算法+最少请求分配，相比于自由竞争可以避免多部电梯同时为一个请求工作的耗电情况。做到极致节能，并尽可能的保证时间的最优。当然，在这种情况下，时间上肯定会稍微弱于自由竞争，这个是调度无法避免的事情。

但相比而言，在耗电与时间的取舍中，采用调度器会比自由竞争拿到大幅降低的耗电量，略微增加时间的结果，这显然是优于自由竞争的。

1.2.4 UML类图及分析

变化： 第五次作业作为电梯单元的第一次作业，还没有可以参照的对象，所以没有变化。

未来扩展能力：

结合UML类图和1.1.1的架构图可以看出，该架构还是具有比较大的可扩展性的，如果要新增新的指令，只需要修改MultiElevatorControl和RequestPool即可。

并且总请求池和分请求池复用同一请求池类，改起来工程量也比较少。

如果要换策略，只需要更换LookDecision和修改MultiElevatorControl即可。

1.2.5 UML协作图

1.3 Bug分析

1.3.1 出现过的Bug

本次中测，强测和互测均未产生Bug。

课下自己做测试的时候有过线程无法结束的情况，这个需要好好规划一下，让Input的关闭信号传给MultiElevatorControl并唤醒，关闭MultiElevatorControl线程（即总请求池——分请求池调度器），然后传递给六部电梯并同时唤醒它们。

这里着重要强调唤醒，因为如果不对进程进行唤醒，进程一直休眠是无法处理这个关闭信号的。

1.3.2 DeBug方法

在这一单元，如我在第一单元所承诺的那样，我继续构建了评测机进行测试，用来产生Bug。

找到Bug之后，采用了打印流的方法来定位问题函数进行DeBug。

Part 2 第六次作业

2.1 线程安全

2.1.1 同步块设置

与第五次作业相同，同步块依旧存在于总请求池和分请求池里面，只不过是增加了更多的方法，因此增加了更多的同步块。

2.1.2 锁的选择

与第五次作业相同，依旧使用Java的Reentrantlock。

2.1.3 锁与同步块中处理语句之间的关系

在第二次作业中，基于我的设计，我的代码产生了一个新的问题：

两条相邻语句之间需要保证一定意义上的原子关系，否则会出现维护请求从一个请求中被删除，但维护信号还未加入另一个容器。这时候在两条语句之间被打断了，有可能导致调度器认为当前没有维修电梯的错判。所以在两条语句上要加一个调度器进行上述判断时所用方法里面加的那把锁，这样保证了两条语句没有全部执行完之前，调度器无法进行判断，会被锁阻塞。

所以，锁与同步块中处理语句之间的关系四：考虑同步块中处理语句之间是否需要保持一定意义的原子操作，如果是，就需要加对应的锁。

2.2 调度器

2.2.1 调度器设计与交互

本次作业新增电梯的动态变化操作，分为维护和增加。我主要修改了总请求池——分请求池调度器（总调度器），在总请求池中新增两个容器分别存放这两种指令，并修改调度器对其进行处理。

具体的说：ADD和MAINTAIN指令均在总调度器处理并完成，对于ADD，总调度器帮忙生成电梯并加入电梯列表。对于MAINTAIN，总调度器向被维护电梯发出信号并将其移出电梯列表。

对于交互的迭代，其实整体上仍然与第五次作业交互相同，只不过增加了一些新的交互，例如调度器向电梯发送新的MAINTAIN信号。

其余设计与第一次作业相同。

2.2.2 调度策略

本次作业不涉及调度策略的改变，与第五次作业相同。

其实我是想优化我的调度策略的，但写了一个很复杂的调度后发现其表现极其不稳定，有时候远远优于旧的算法，有时候表现很差，所以最终还是没有改变调度策略。

2.2.3 性能指标适应度

与第五次作业分析相同。

2.2.4 UML类图及其分析

未来扩展能力：由于和第五次作业的整体架构相同，所以分析同第五次，但我在实现处理添加电梯的请求的时候，使用了构造函数来添加电梯，如果后面添加电梯有新的参数也十分方便扩展。（一语成谶）

变化：相较于第五次作业，其实架构变化比较大的地方在于如何结束程序。原先结束总调度器线程的方法是只要输入线程结束，便可以关闭线程，之后只要电梯没有工作需要做就可以关闭线程。

但在第六次作业中，这样做是行不通的，因为即使输入线程关闭了，也可能存在未完成的MAINTAIN指令，导致被维护的电梯向总请求池递交请求，如果按照原来的架构，此时总调度线程已经关闭，这些请求不会被分配，所以丢失了。

即使电梯没有工作，在MAINTAIN后也可能会有请求给已经关闭的电梯，这些请求不会被处理，也会丢失。

所以，关闭的架构需要做出比较大的修改，但经过我的思考，有一种巧妙的改法：

将维护的电梯也视为输入线程。

这样就不需要大幅改变关闭的架构，只需要在条件判断时多加几个判断就好。

2.2.5 UML协作图

2.3 Bug分析

2.3.1 出现过的Bug

本次中测，强测和互测均未出现错误。

课下进行测试时出现了一个BUG：对于同一个人，维修时人还没从电梯出来，即还未输出OUT，另一部电梯就已经输出IN了，这是因为代码语序设置错误，应该先输出OUT后将请求返回，而不是先返回请求再输出OUT，这样就容易被别的线程中断导致输出错误。

2.3.2 DeBug方法

同第五次作业。

Part 3 第七次作业

3.1 线程安全

3.1.1 同步块设置

与第五次作业相同，同步块依旧存在于总请求池和分请求池里面，只不过是增加了更多的方法，因此增加了更多的同步块。

3.1.2 锁的选择

与第五次作业相同，依旧使用Java的Reentrantlock。

3.1.3 锁与同步块中处理语句之间的关系

本次未产生新的关系。

3.2 调度器

3.2.1 调度器设计与交互

本次作业对电梯提出了新的要求——可达性，电梯仍然在1-11层之间运行，但只能到达某一些楼层，用11位二进制的01表示该层是否可达。（即掩码）

所以在总调度器的位置，调度器要做出比较大的变化，能够计算出一条可供乘客使用的路径。并记录这条路径且按时安排。

具体的设计：

考虑到电梯的基准策略为找最少换乘路线。而且我认为确实是寻找最少换乘能让电梯的效率在普遍情况下得到最高（不断换乘也是需要消耗时间的）

所以我采用了BFS（广度优先搜索），以电梯作为状态。找到第一个解就立刻返回，可以保证这是一条换乘最少的路线。

这样做在时间上会比BFS快很多，而且我也做了一定的优化，比如每一部电梯只被搜索一次。所以我最多搜索电梯数目个状态。

因为在当时那种情况下，电梯的状态是一定的，可达性也是一定的。第一次经由它搜索到不了，第二次肯定也到不了。

交互：

在本次作业中，电梯与总调度器的交互性大大加强，一个路径被规划好后，需要将每一个步骤所形成的——PersonRequest按顺序投入对应的电梯，且保证时序，即对于同一个人，要先完成前置运输请求，才能进行下一运输请求。（人是不能分身的，且不能Teleporting)

这就需要完成任务的电梯给总调度器返回完成信号，让调度器继续分配下一步骤PersonRequest给某部对应电梯。

3.2.2 调度策略

由于电梯可达性的加入，电梯策略需要做出一定的改变，所谓大道至简，所以我的策略就是：

如果只有一部电梯可以直接完成请求，就用一部电梯

如果有很多电梯都可以直接完成请求，此时问题就变为了前两次作业的调度问题，直接复用前两次作业的调度策略。

如果没有电梯可以直接完成请求，再进行BFS寻找最少换乘路线。

3.2.3 性能指标适应度

由上面的调度策略进行分析：

在电量上这种策略一般是比较优秀的，因为过多的换乘只会增加电量（开门，电梯的移动），如果不得不换乘也是采用了最少的换乘，使用了最少的电梯，开了最少的门。显然是很省电的。

在时间上这种策略只能保证在一般情况下比较优秀，因为有些时候，可能换乘会比直达都快，但在我算法中只会优先直达。

但换个角度，如果调度花费了太多时间计算，是不是也会导致时间的增加？这同样是需要思考的一个问题。

3.2.4 UML类图及分析

未来扩展能力：到这次作业，总调度器的扩展方案基本成型：

    public void run() {
        //int i = 0;
        while (operateSign) {
            //i++;
            //System.out.println("第" + i + "次轮询");
            HashSet<ElevatorRequest> nowElevatorRequest =
                    globalRequestPool.forEachElevatorRequest();
            for (ElevatorRequest request: nowElevatorRequest) {
                assignElevatorRequest(request);
            }
            HashSet<MaintainRequest> nowMaintainRequest =
                    globalRequestPool.forEachMaintainRequest();
            for (MaintainRequest request: nowMaintainRequest) {
                assignMaintainRequest(request);
            }
            HashSet<PersonRequest> nowPersonRequest =
                    globalRequestPool.forEachPersonRequest();
            for (PersonRequest request: nowPersonRequest) {
                assignPersonRequest(request);
            }
            HashSet<PersonRequest> nowRequestHadDone =
                    globalRequestPool.forEachRequestHadDone();
            for (PersonRequest request: nowRequestHadDone) {
                updatePerson(request);
            }
            HashSet<PersonRequest> personNeedFlush =
                    globalRequestPool.forEachPersonNeedFlush();
            for (PersonRequest request: personNeedFlush) {
                flushPerson(request);
            }
            checkCloseSign();
        }
    }

可以看出如果有新类型的请求，可以按照同样的模板进行添加，扩展性较好

电梯的变化方案基本成型：

    public Elevator(int elevatorID,RequestPool requestPool,double arriveTime,int capacity,
                    int nowFloor,RequestPool globalRequestPool,int arriveAbleMask,
                    MultiElevatorControl control) {
        this.buildingName = "NewMainBuilding";
        this.elevatorID = elevatorID;
        this.elevatorDecision = new LookDecision(requestPool,this);
        this.doorState = false;
        this.nowFloor = nowFloor;
        this.direction = 0;
        this.capacity = capacity;
        this.personInElevator = new HashSet<>();
        this.lock = new ReentrantLock();
        this.condition = lock.newCondition();
        this.workSign = true;
        this.requestPool = requestPool;
        this.readyToClose = false;
        this.arriveTime = arriveTime;
        this.readyToMaintain = false;
        this.globalRequestPool = globalRequestPool;
        this.arriveTime1000 = (long)(arriveTime * 1000);
        this.arriveAbleMask = arriveAbleMask;
        this.control = control;
        this.thisFloorJustUpLoad = false;
        this.thisFloorIsAdded = false;
    }

构造函数简单直观，如果需要新的电梯参数直接加入即可，电梯扩展性较好。

甚至由图可知，代码有着不同楼的扩展性接口（可惜三次作业都没用上）

变化：

主要是新增了几个辅助类，同时将PersonRequest类转变为了Person类，将处理思路由处理请求变为了处理人。

在分请求池里面增加新容器，用来判断该请求是一个直达请求还是不直达请求中的一部分。

在总请求池里面添加新容器，用来接受电梯完成请求的回显，帮助总调度器非直达请求判断下一请求的分发。

在总请求池里面添加新容器，用来接受电梯维护时需要被刷新的人，如果对这个人的运输请求是属于不能一次完成的请求，此时由于路径已经变得不可达，所以就需要重新规划。

总调度器添加与这些容器对应的处理逻辑。