OO第二单元优化博客

OO第二单元优化博客

第五次作业没有性能分，但是，我在这一单元的宗旨就是写一个日常生活中 最常见的那种电梯，所以第五次我没有写傻瓜电梯，而是直接写了个\(look\)，和第六次基本相同。

总计一下look算法的几个特点：

1、没有主次请求的区分。

2、电梯会一直往当前方向运行直到需要转向，转向条件为：

​ (1)当前电梯中没有乘客的目的楼层在当前方向上。

​ (2)当前方向上的楼层目前没有请求。

3、捎带时只捎带请求与当前方向相同的乘客。

​ (由于第五次第六次作业没有容量限制，所以可以把当前楼层上的所有请求全部拿进来)

另外，还有一些奇怪的优化：

1、在\(close\)和\(arrive\)时候记一下时间\(t_1\)，下一次运行的时候可以根据当前时间\(t_2\)，少\(sleep(t_2-t_1)\)的时间。

2、若电梯长时间没有收到请求，可以利用休息的时间\(t\)，根据下一次需要到达的楼层来节约时间。

​ 在第五次作业中，每次可以节约\(min([t/500ms],|target-now|)*500ms\)的时间；

​ 在第六、七次作业中，由于需要输出\(arrive\)，最多每次能节约\(400ms\)

​ 这种反现实优化被我们称为“薛定谔电梯”，直观上来看，就是100%预测下一次的运行方向和楼层数，休息的时候直接往那里走，被称为薛定谔是因为：在你给出下一个请求之前，你永远不知道我的电梯到底在哪(第五次作业)。

关于架构上的感悟&多电梯：

第五次作业的\(CPU\) \(time\)限制支持暴力轮询；

第六次第七次大部分同学应该都用的\(wait\&notify\)，为了代码复用和简单架构，我在暴力轮询的循环里加了\(sleep(10)\)，就能够控制\(CPU\) \(time\)在\(1s\)左右。

没有请求队列，模拟现实生活中的楼房\(Building\)类和楼层\(Floor\)类，将请求无条件放在对应楼层，电梯再去取人，所有的同步锁都只放在\(Floor\)类中，避免死锁。

多电梯中，将\(A,B,C\)三部电梯对应到三个不同的\(Building\)对象，用一个分配器分配，分配策略为平均(摸了)。