oo第二次博客作业
oo第二个单元也过去了，在这里做一个小的总结。
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。第一次作业
第一次作业主要就是我们对多线程的一次接触，所以对于电梯调度的逻辑性不存在任何难度，由于比较简单就不详谈了。
第二次作业
第二次作业相比第一次作业调度方面只增加了一个捎带，关于这里的设计我是按照指导书的提醒进行设计的，即每到一层楼都交流一次信息，判断是否需要捎带，捎带的条件是：1，当前进行的请求还未到目的楼层；2，被捎带的请求和当前请求方向一致；3，电梯当前到达楼层是被捎带请求的出发楼层。只要满足以上三条就会进行捎带，同时会将当前请求的目的楼层更新为正在执行的一系列请求的方向上最远的楼层（比如说是往上，那么这系列目的楼层就是正在执行的请求序列中目的楼层最高的楼层），同时设立一个队列来存储这一系列请求中所有请求的目的楼层，而达到每层楼也会进行判断当前楼层号是否能在目的楼层队列之中找到，如果找到，则说明有乘客需要停靠出电梯，这样发现一个请求的重要条件给忽视了，那就是乘客ID，所以还需要创建一个楼层—ID的表格来进行对应，以便在出电梯的时候找到乘客的ID。
第三次作业
第三次作业当中把一部电梯增加为了三部电梯，我采用的设计方式是把待处理的请求队列当作一个被保护的对象，每当三部电梯和输入端需要存取请求的时候都要先synchronized这个队列，同时每个电梯也有自己的待处理的请求队列（因为每个电梯都涉及到捎带），每个电梯自身的队列不会涉及到线程安全性的问题，因为首先已经确定是这部电梯进行调度了，而且它的请求队列里请求条数不只一条的原因也只有因为捎带添加进入，也就是说每部电梯自身的请求队列的调度方式是能够一眼看出的一串互相捎带的请求，但是还有一个问题没有解决，那就是一条请求涉及到多部电梯共同工作才能完成的情况，把每部电梯可停靠楼层观察一番后发现每部电梯都能够通往一楼，并且三部电梯除一楼外可停靠楼层的并集是所有楼层，所以说其实每条需要多部电梯共同工作完成的请求都是可拆分成先从出发楼层到1层，再从1层到目的楼层的两条请求，这样第一条请求就可以交给出发楼层满足其停靠楼层的电梯，关于这个的设计需要注意的是在拆分请求的同时需要将被拆分的请求先从请求队列移除并将第一条请求交给满足上述要求的电梯的指令队列，同时必须等该请求执行完（必须要执行完，这两条请求执行必须是第一条执行完后再执行第二条！）后再将第二条请求放入总的指令队列。
关于遇到的困难
遇到的困难主要来自于第三次作业，因为多线程debug很大程度上只能通过逻辑上来解决，所以对于多部电梯间存取指令时的线程安全设计不完善时很容易卡壳，需要反反复复来看很多次才能发现问题所在，还有就是有时候以为一个bug已经解决了但是其实只是运气好没有触发这个bug，有时候需要运行六七次才会触发一个bug，同时也出现了不少拆东墙补西墙的情况。
多线程总结
通过多线程的学习，加深了我对线程安全的理解，对逻辑的严谨性也有了很大的提升，希望以后能再接再厉。
