1、基于度量的做业分析
h1能够说是一个很是傻瓜的多线程电梯，原理很是简单直接粗暴算法
实际运用可能会被客户投诉（是必定）安全
在第二次做业中，我采用了一种很是复杂的写法多线程
能够看到复杂度最高的地方集中在电梯的运行函数和调度函数中，但其实这种复杂性对于电梯的运行并无任何的帮助，只是因为对于多线程知识的只知其一;不知其二和架构设计不清晰而造成的这种结构架构
相较于第二次做业来讲，电梯的设计有了必定的改进，将一些没必要要单列的线程和功能进行了抽象化和集中函数
可是电梯的复杂度仍是比较高的，尽管指导书要求咱们写的应该是一个有着实际运用价值的电梯，可是个人电梯的目的只是为了过中测性能和调度算法仍是比较差的性能
2、设计策略
在前两次的电梯做业中，我对于多线程的了解都只是错误或者不全面的学习
重点叙述一下第三次电梯做业的设计策略测试
首先，电梯问题是一个很经典的“生产者——消费者模型”spa
生产者——需求线程
在这里需求分为两类
1.能直达
2.不能直达（从起点到换乘楼层，从换乘楼层到达目的楼层），至关于两个需求，可是这两个需求是有时间的前后顺序的
消费者——电梯
因为三部电梯拥有不一样的到达楼层，乘客可能有换乘的状况发生，因此在需求产生的时候，我就将这个乘客是否须要换乘，在那层楼换乘进行了一个判断
对于每一个电梯，都有一个运行序列，主需求序列经过调度器将各个乘客分配到三部电梯的运行序列中
调度器的运行是在电梯上下楼之间的时间完成的，也就是说，没上升或者降低一层楼，都会对电梯进行一次调度，同时根据电梯的运行状态（上行或者下行，是否满载），来进行乘客的进出
3、发现的bug以及处理
-
电梯不能读入请求
这里的问题主要是线程安全致使的，对于让电梯和调度器wait和唤醒时的设置有问题
2.超载
最开始没有设计电梯容量，在电梯的运行函数中修改
3.电梯疯狂向一个方向跑
对于判断电梯运行状态的方法设计有问题，修改
4.需求不能执行完，执行几条以后就不执行了
这里是线程安全的问题，出现了部分死锁的状况
4、分析本身程序的bug和分析本身发现别人程序bug所采用的策略
bug仍是挺多的，设计自己有问题。
主要出如今调度算法的漏洞，电梯仅依靠判断本电梯运行序列中乘客的状况判断是否上下人，而后有时候调度器错误的调度就致使电梯不能正确执行指令
关于debug的方法：
先设计好数据，而后黑盒测试，对于有问题的数据进行代码的调试和bug的定位
（这里感谢ffdl的定时投放数据脚本）
5、心得体会
首先，多线程是真的挺难的。
对于如何让本身的代码兼具高效和正确性对我来讲仍是一个比较大的挑战。
在学习多线程的过程当中，我认为仍是多和同窗进行交流，这样就能够及时的将一些错误的理解避免，免除没必要要的代码工做
更重要的一点是，必定要在认真阅读过指导书后在进行设计，而后再进行代码
否则就有可能整个程序架构崩盘（你问我怎么知道的？呵呵）