第二单元总结

1、做业分析

1.多线程设计与控制

我设计的原则是能少创建线程则尽可能不要多创建没有意义的线程，这样多线程相关的设计与控制将更加简洁。关于线程冲突，我主要采用synchronized来进行同步控制，和共享数据相关的方法须要保证其操做原子性的均加上synchronized关键字，为防止电梯等待请求的轮询。使用wait方法。

2.具体架构

个人电梯总体上采用的是look调度原理，既电梯在楼层间扫描，若能够调头，则调头，如有人要上则上人。第二次做业和第一次做业差异不大，我为每一个电梯开了一个storage，请求从主线程读入后几乎不访问电梯的状况将请求放入仓库。第三次做业较前两次变更比较大的是须要换乘，我考虑在一、15楼换乘，若电梯没法知足请求则在此抛出请求给其余仓库，此时要增长电梯和其余电梯、仓库的交互，须要比较谨慎，在此我采用hashtable容器来存储电梯与仓库做为共享变量。关于结束程序是个比较难以考虑的点，前两次我都是采用最后放入storage一个特殊的请求，做为输入结束的标志，而第三次因为换乘请求可能在输入结束标志到来后到达，我设计了一个标志来表示电梯是否可以退出，该标志可让电梯跳过装人环节，当该标志置位时访问其余电梯的状况，若该标志均置位则能够结束线程。

（1）类的度量

下面为三次做业类的度量：

能够看到第一次做业中判断是否要下人和是否须要调头的方法的复杂度较高，而这些方法几乎是必须的，看见此次的复杂度控制的比较好，第二次同第一次做业同第一次相似，修改也较少，变化不大，第三次做业方法增长了许多，可是复杂度几乎没有大的变化，可见三次做业复杂度控制的比较好。

（2）类图

三次做业的类图以下：



三次设计思路相似，类图也看起来差异不大。很明显，三次做业在低耦合这一点上作得还不够好，好比电梯类其实能够简单的只负责上下开门一类的，利用一个单独的控制类来对电梯的行为进行控制，这样也不至于致使电梯类的行数太多，电梯只接受控制器的控制，另外还能够单独构造一个类来储存各个电梯的信息，这样在交互的时候逻辑也比较简单，而且不容易出错。

（3）协做图

因为低耦合作得很差，因此类比较少，只有main、elevatro、storage三个类，类、线程之间的交互也比较简单，三次做业的内核都采用上图所示的方式，电梯每到一个楼层向storage索取请求，若是没有且知足其余一些条件则wait，storage每次get到请求便notifyall，交互逻辑简单，这算是优势，第三次的结束部分增长了知足结束条件则上下游走，等钱其余电梯以确认换乘不会增长请求，此处没有增长wait，固然其实这样的处理很差，只是为了写起来简答，可是对电梯而言就比较累了。

3.设计评估

（1）性能设计

关于性能，我三次都是再以前的基础上知足额外功能要求，基本调度采用look算法，好比第二次当请求到来时我会先获取各电梯线程的状态，若为WAITING则放入对应的仓库，若没有正在WAITNG的电梯则随机放入一个仓库，实现起来比较容易，不涉及电梯信息的交互，分数上还算过得去，算是性价比比较高的写法。第三次的换乘则不得不添加一些电梯间的交互，大致上请求调度也采起随机的方式，分数也还过得去。

（2）设计原则（SOLID

SRP单一责任原则

不得不说个人类之间的耦合度一次比一次高，类之间的分工还算明确，但整个做业不过三个类而已，这一点作得很很差。却是其中的方法分的比较细，从方法的角度来看还算知足单一责任原则，面向过程的意味比较浓。

OCP开放封闭原则

这一点作得通常，每次写做业仍是主要考虑当次做业的需求，习惯性的修改原有的代码，可是个人方法划分比较细，单个方法的独立性较好，方法与方法之间的耦合度较低，所以修改时每每只涉及到部分方法。

LSP里氏替换原则

做业中未涉及继承，固然这是很差的。

ISP接口分离原则

写代码仍是不习惯设计接口，可能做业的工程量还不算大。

DIP依赖倒置原则

对于一套仓库和电梯而言，是知足这个原则的，仅仅是在交互时可能发生跨层次交互，总的来说这一点仍是符合的。

（3）可拓展性

写代码时没有意识来实现更好的可扩展性，每每扩展时须要对代码比较熟悉进行修改，毕竟做业的工程量较小，层次划分不够，做业的时间跨度也比较短。固然通过两次迭代的过程，多少有一些扩展性比较好的地方，特别是第三次，由于第三次电梯的种类比较多，类型差别还算比较大，我采用一个构造方法来实现不一样的电梯，所以就算新增种类的电梯也可以简单的增长构造方法的逻辑分支便可。关于线程的交互，好比电梯之间的交互，因为个人设计原则是尽可能少交互，因此没有实现一个统一的交互平台，这是不足的，影响扩展性。

2、BUG分析

1.个人BUG

第三次做业中电梯会在一些极端的状况出现进入wait以前，条件判断以后触发notify，致使wait没法退出的状况，在调整了判断条件，增长了notify的状况下得以解决。

2.他的BUG

第一次的时候虽然没有hack成功，可是我发现有个同窗开门用0.4s，关门用0.4s。。。这告诉咱们要认真读题！！！第二次的时候在互测的最后关头发现有个同窗的超载处理有问题，会出现电梯的超载的状况，但是时间不够没能成功提交合法的互测样例。。。第三次的时候发现有同窗的电梯会卡住，程序没法退出，应该是退出逻辑没有写好。第三次做业经常有不知道为何非法的构造样例，真的已经仔细看过互测用例要求了仍是提交不上去，但愿从此可以反馈非法缘由。

3.测试相关

我通常会简单读一下代码，若是以为有问题则想办法构造样例，另外我也写了测评机，随机生成测试用例，若是有问题则分析问题所在。

3、心得体会

要先作设计再开始动手写代码，低耦合高内聚应该深刻人心，设计不该该只是针对做业知足做业要求，还应该考虑设计的“美观”（尽可能划分层次，从类入手设计，功能考虑完善），这样犯错的几率也更低，效率也更高。此次我了解了多线程，是个很神奇的东西。此次还让我认识到，关于性能分，个人水平仍是追求高性价比比较好，特别是对于一些说不清楚的东西，带有随机性的东西。就像咱们的人生，没必要贪心。