[面向对象]电梯作业优化相关
我的整个电梯作业的架构非常普通，一个总控制线程来分配任务给不同的电梯（每个电梯具有自己的等待队列），每个电梯再完成自己的等待队列中的任务。
在这一系列过程中，可以产生优化的部分主要有两个地方：一是总控制线程分配任务给各电梯的过程，第二个是每个电梯内部的运行算法。在我们写好程序之后，可以通过自动化对拍器来更好更直观地分析和评价我们的电梯，并对其性能进行改善。
直达任务的分配
在我的调度过程中，可以直达的请求是由一部电梯来直接完成的：虽然这样的性能可能不是最优的，但是其复杂程度相对于拆分直达请求而言还是降低了很多。
在调度的开始，我们首先判断该直达请求能够被多少电梯执行(如请求FROM-1-TO-15三个电梯均能完成)，如果该任务只能被单一电梯完成，我们便交给相应的电梯，而如果多个电梯均能完成该任务，我们再考虑如何对它进行分配。
在多个电梯同时运行的过程中，要考虑的问题主要是负载均衡和最终时间较少。负载均衡是为了让每个电梯都能够分配到合适的任务量，避免一个电梯超负荷运行而其他电梯作壁上观的情形，而最终时间较少是我根据电梯目前的运行状态来决定将任务交给某个电梯，以期最终的运行时间尽可能短。
在这里我设计了一个为每个电梯打分的评价方法，指标主要有一下几个：电梯是否满载、 电梯是否正在执行任务、电梯目前所处的楼层和运行方向、请求发出的楼层和与进行方向。
在具体的实现上，
- 每个电梯的起始得分为0
- 如果这个电梯是处于空闲状态(停止)，那么我们给这个电梯加$G_{IDLE} $分
- 如果这个电梯不是满载状态，那么我们给这个电梯加$G_{NOTFULL} $分（也可以根据电梯内的人数n来加F(n)分）
- 计算当前电梯到该请求的距离（考虑当前电梯的运行方向和电梯速度），为电梯加$S(lenth, speed) $分
- 对于不同的电梯，我们给他不同的分数系数α
- 不能直达运行该任务的电梯,α = 0
- 如果能运行该请求，给A、B、C电梯不同的系数α（例如可以提高C电梯的系数，来保证同等条件的时候，能够更多地将任务交给C）
- 得出每个电梯的总分数：\(score = \alpha \times (G_{IDLE} + G_{NOTFULL} + S(lenth, speed))\)
最终我们便能够根据分数来决定将该任务分配给哪个电梯。
非直达任务拆分
对于不能直达运行的任务，我们要先将他们运送到中转站，然后再交由下一部电梯完成整个任务。在这里，总调度器要做的就是为他们选择合适的中转站，而从请求发出楼层到中转站和中转站到目的楼层的两部分过程都参考直达任务来分配。
在中转站的选择上，我们同样结合该请求发出的楼层和其方向、电梯的情况来决定。如果请求发出的位置是只有特定电梯能够停靠的，那我们就将它交给特定电梯，如果有多部电梯可以接到该请求，我们便用上文提到的打分机制来找出更合适的电梯。
在找到合适的电梯后，为该请求分配中转层，我们将分配电梯运行到该任务后运行方向上最近的换乘层作为中转站（在本题中为1或15层），能够使得该任务尽早被中转(但不一定最优)，对于B->C、C->B换乘的任务，我们可以交给任务运行方向上最近的奇数层。
电梯内部运行算法
对于单部电梯的运行算法，LOOK的表现还是不错的，即运行完成一个方向上的所有请求后再调转方向完成另一方向上的所有请求。
在捎带策略上，由于第二次作业中电梯没有容量限制，所以我采取的策略是：在每层根据能否捎带决定是否开门，一旦开门则将该楼层出发的请求全部装入以节约下一次反方向经过的开门时间。
但是在电梯容量有限制的时候，这样的捎带策略可能导致后续能够捎带的请求无法捎带上，而电梯需要为这些请求在后续多跑一趟。我的解决办法是在电梯内人数到一定阈值的时候\(\beta\times Capacity\)（指定系数*电梯总容量），调整捎带策略为：在开门后，对于反方向的请求，不允许其进入电梯。（听到有同学是在每层，先让电梯中的人全部下电梯，在选择合适的进来，tql...）
电梯运行情况的分析与评价
对于电梯运行情况的检测，我们可以计算其在一定时间内运行的任务数量，来查看每个电梯的负载程度，并通过调整打分机制中的相应参数（例如系数α）来调整任务的分配。
同时，我们也可以绘制出电梯运行的时空图来更加直观地检测电梯的运行状态：
我们以程序运行时间为横轴，纵轴为楼层数，画出了电梯的运行轨迹，每个点的大小为电梯在到达该楼层时的负载情况。
电梯运行时空图 图注：
蓝色：A电梯
绿色：B电梯
红色：C电梯
折线：电梯运行轨迹
每个方形的大小：当前电梯内人数
在这里，我画出了我的程序在某一数据下的运行情况，可以看出，单个电梯的LOOK算法执行较好。但是在任务分配上做的不好，B电梯的负载明显过高，而C电梯的任务量太少（运行时间短、运送任务少），电梯整体的的运行图能够更加直观地展示电梯在其生命周期内的运行负荷，也能够较好地找出限制电梯运行效率的痛点所在。
在第三次作业的互测阶段，我也为同组的一位同学画出了电梯的运行时空图，对于30S左右输入的40条左右请求，他的程序执行了160S以上。从画出的电梯运行图也能看出，他的单部电梯在执行任务的过程中使用的算法不是非常合理，B电梯出现了大量的“折返跑”现象；在任务的分配上同样存在着问题，A、C电梯都有长时间空等的情况。
