OO第二次做业电梯总结

这三次做业，发现本身不管采起怎样的架构，最后本身写的类都只有两个（除了给出的TestMain demo类）。

在类图中，都是只有三小块....架构复杂性彻底没有变？

第一次做业：

类图：

设计模式：

第一次做业的架构是三次里面最清晰的——生产者消费者模式。

本身开始对于多线程彻底没有思路的时候，《图解Java多线程设计模式》救了本身一命。

PS：这本书北航图书馆有电子馆藏，你们能够搜一下下载。（涉及版权问题就不直接放连接了）

具体以下：

模式角色	对应Class	做用
生产者	TestMain	提供请求
消费者	Copying	不断地查询是否有新的请求须要执行
放有产品的桌子	Elevator	为生产者和消费者提供各类各样的接口
产品	PersonRequest	(做业提供/自带）

 

 

第二次做业：

类图：

设计模式：

第二次做业的架构能够说和第一次彻底同样。可是这里本身遇到的一个新的考虑是是否须要换成观察者模式。

再也不是每层都本身执行一遍有无请求的查找函数而是当有新的请求加入的时候，通知电梯这个请求的到来。这样没必要每一层都执行查找函数。

关于观察者模式和消费者模式的区别：

目前看来，最大的区别在于一个是本身去看生产者有没有请求，一个是由生产者主动通知本身有没有请求。

这三次做业本身没有改变本身的架构，这样的带来的问题是CPU运行的时间会长一些。

目前尚未看到观察者模式在此次做业上有特别须要的地方。（由于电梯每一层都必须输出一个arrive信息。这样，电梯仍是没法作到请求到请求的代码运行？）

 

 

第三次做业：

类图：

设计模式：

【请求拆分】

 为了沿用本身以前的架构，第三次做业发现请求拆分比较方便。

即一开始就把一个电梯没法到达的请求拆成两个。

而后，优先寻找中转楼层为两个电梯之间的楼层。若是没有，选择中转楼层为1或者15 的最近楼层。

 接下来的运行过程就和单电梯的调度策略是同样的了

 踩到的坑：

一、LOCK对象与wait notify对象不一致就没有用了。

好比

若是是

synchronized (lock)

就必须在里面使用

lock.wait();

而非简单地

wait();

由于wait，表示是当前的this对象等待。

同理，notifyall也须要一致的对象。

 

二、电梯线程像尸鬼同样死不了，或者死的过早的问题。

若是主线程结束了，电梯线程怎么知道主线程结束了呢？

须要使用一个dead信号量，电梯线程不断地探测，若是为true，就自杀。

可是，出现了三个电梯，就比较难办了。由于一旦没有任务，电梯就wait了吗，不会主动探测到dead信号量。因为是事先分配全部请求，若是主线程输入没有了，其余电梯队列里面也不会有扔给本身的了，就能够线程结束。可是要当心电梯wait而检测不到dead信号量的问题。

 

复杂度比较与线程UML协做图：

第一次做业：

 其实能够发现，第一次做业除了copy 的run函数复杂度比较高之外，实际上出现问题的就只有

elevator的stop方法，的确，因为几乎调用了这个类其余全部的函数，这个函数的独立路径的条数较多，模块的复杂性相比之下最大。

 

 

两个线程的协做，其中，输入线程（主线程）TestMain一直没有wait，不断地将请求加入请求队列当中并唤醒copying线程，copying线程就一直不断地执行请求，直到请求队列为空将本身sleep。

第二次做业：

 

 renewdirect函数很是地冗长，主要的复杂度最大的函数。不过，这个函数的基本复杂度并不高（非结构化成分并很少），可是这个函数的模块断定结构复杂度很高，若是须要预防错误所需测试的最少路径条数较多，程序比较难以维护。

第二次做业线程之间的协做关系和第一次做业的协做关系基本如出一辙。只不过增长了捎带的算法

第三次做业：

 因为此次做业，代码须要处理的逻辑增长了很多可是本身依然只用了两个类，增长的函数也并很少，就致使每一个函数都比较地冗长，复杂度较前两次做业大大地上升。

第三次做业，增长了线程池这个结构，管理三个电梯，因为只有一把锁，三个电梯在访问请求队列时会造成竞争关系。

主线程依然在不断地运行直到输入结束。

三个电梯各自的运行逻辑跟前两次做业类似，只不过最后结束的时候，并不仅仅要判断dead信号量，还要检查其余两个电梯的队列里面是否有本身须要处理的请求。

整体Analysis：

不出意料地第三次复杂度最高。第三次本身的几乎所有代码量都集中到Controller类里面了。分布很是地不均衡.....

conclusion：

感受多线程在电梯做业中最核心的一点就是把握住lock的申请与释放问题。只要sleep就再也不占有lock了。目前看来仍是能够生命能够承受之重的代码。

但愿下次不要再那么臃肿了.....