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)对象，用一个分配器分配，分配策略为平均(摸了)。