OO第三次电梯作业优化

第三次电梯作业个人优化

目录

• 第三次电梯作业个人优化
  • 前言
  • 优化思路
    • 一、调度器
    • 二、电梯

前言

由于个人能力有限，第二次电梯作业只能完成正确性设计，没能进行优化，也因此损失了强测分数，于是第三次电梯作业时便决定进行优化，结果强测错了一个点，同样损失了强测分数……但是总的来说，第三次作业的优化还是有一定效果的，性能分比起完全没有优化的第二次高了许多，有的点甚至达到了96、97分，也一定程度上弥补了我第三次作业的强测分数。

在写博客之前也拜读了很多大佬的优化博客，比起他们的一些很巧妙的优化方法，还有一些我看不懂的优化方法，我的优化实在是拿不出手，过于简单。但我最后还是决定写一下这次的优化博客，一方面是为了能够得点分数，另一方面是希望能给像我一样能力有限的同学提供一个思路，即使不会什么高深的算法和工具，用最简单基础的方法也是可以进行优化的，优化一定程度上是大佬们的游戏，但对于我们而言，只要尝试了也一定还有收获。

那么下面就讲一下我的优化思路。

优化思路

一、调度器

最简单并且保证正确的调度算法就是按照A，B，C（或者C，B，A等等）的顺序来进行轮询，找到第一个能够完成请求的电梯就把请求塞给它。但是，这样就有很有可能导致调度器把绝大多数请求都分给某一部电梯，其他电梯长时间空闲的情况。

所以，对于多部电梯均可以完成的请求，我们要把它分配给最合适的那一部。对于如何选择最合适的电梯，有大佬给出了极为复杂巧妙的算法，而我的做法则很白痴，就是将按照当前已经分配给个电梯的请求数量把三部电梯进行排序，然后从请求数量最少到最多依次进行询问，分给第一部可以完成的电梯。

Elevator e1 = elevator1;
Elevator e2 = elevator2;
Elevator e3 = elevator3;
if (e1.getNuma() > e2.getNuma()) {//getNuma方法返回已分配给该电梯的请求数量
    Elevator temp;
    temp = e1;
    e1 = e2;
    e2 = temp;
}
if (e2.getNuma() > e3.getNuma()) {
    Elevator temp;
    temp = e2;
    e2 = e3;
    e3 = temp;
}
if (e1.getNuma() > e2.getNuma()) {
    Elevator temp;
    temp = e1;
    e1 = e2;
    e2 = temp;
}
……
if (e1.able(t)) {
            e1.getLista().add(t);//进行分配

} else if (e2.able(t)) {
            e2.getLista().add(t);

} else if (e3.able(t)) {
            e3.getLista().add(t);

}

当然，对于需要合作才能完成的请求，我也是先检查排序一位和排序二位的电梯合作是否可以完成，再依次检查。

我觉得这体现的其实是一种平均分配的思想，不仅适用于电梯，也适用于任何多线程完成任务的程序设计，当然也正因为于此，它可能在电梯这个特定的问题上表现的不如那些专门针对电梯特性设计的调度算法好，但是平均下来仍然有较好的优化效果，特别是在强测数据完全随机的情况下。

二、电梯

电梯的优化我主要分以下两个方面进行：

1.设定空闲目标楼层

简单来说，就是让每部电梯在没有任务，又恰好占用CPU资源的时候往一个最合适的楼层自主移动，这个最合适的楼层可以是换乘比较方便的楼层，可以是人流量比较大的楼层，也可以最简单的就设为所以可以到达楼层的中间楼层，在我的程序中我选择的是第三种。代码如下：

ft = fmid;//将目标楼层设为中间楼层
while (lista.isempty() && inc) {
    try {
        move();//在没有请求的时候向目标楼层即中间楼层移动
        Thread.sleep(1);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

不难发现，这种实现在某些情况下会产生负优化，比如过一段时间就从一楼来一个请求，这时候我的电梯往往会进行折返跑，浪费大量时间，但是同样，在平均效果上，这样的做法实现了优化，对于大量随机请求而言，电梯处于中间位置往往是最佳选择。

2.主请求的选择

在选择主请求的时候，我们的等待队列里往往已经有了许多等待的请求，这时候选择哪一个作为主请求呢，我认为应该选择那个出发楼层离电梯目前楼层最远的那个作为主请求，这样可以在去接主请求的路上捎带上尽可能多的请求，比如当前请求队列中有如下几个请求：5-9，4-3，1-2.；而我的电梯目前处于10层（假设各层均可停留），如果我们直接将第一个也就是5-9的请求作为主请求，电梯会先完成这个请求，然后再跑下来完成4-3，最后完成1-2，而如果按照之前所说选择1-2作为主请求，我们就会在去1层的路上完成4-3的请求，然后顺势而上完成5-9，完全没有无谓的折返。

我感觉这种优化体现的是和上面两处优化不同的思路，上面两处实现的是一种平均优化，即尽管某些情况会产生负优化，但平均起来效果更好。而第三处优化则是：某些情况下性能更好，其他情况下性能至少不会变差，这也是一种优化的思路。