oo第二次博客总结
oo第二次博客总结
一、前言
从三部多线程电梯开始，oo终于进入了多线程的控制。多线程中的线程安全是非常重要的方面，需要更多的精力和更加小心的去设计代码和修改bug
二、多线程电梯
在三部多线程电梯中，我的设计并不完善，其中从输入到调度器再从调度器到托盘的过程若均使用生产者消费者模型会因为无输入而导致调度器线程挂起，而无法实时循环判断无法捎带的指令何时能被电梯捎带，最终也是无法解决。
指令从input线程到调度器线程，在分配到三个电梯线程，通过托盘传递，以保证线程安全。
虽然说明书要求了继承前次实验的类，但事实上，我之前的设计感觉并不适合多线程的使用，实际上我直接重写了scheduler类。实验时因为运行时间会产生误差，无法准确做到符合电梯运行时间，于是使用了额外的时钟，记录时刻，在电梯运行相应楼层数，停留时增加相应的时间。
三、IFTTT
本次实验是对文件的监控，需要监控文件的大小，最后修改时间，以及文件的路径包括文件名的修改，当发现变化后，依据监控任务程序作出相应的动作。
其中该次实验中，需要关注的多线程多个不同监控命令对应的线程以及是对文件夹的扫描线程。对于文件夹扫描，我只使用了一个线程，后来才明白这样如果面对目录深度大文件数目多的情况，会使得运行时间较长。
在设计程序时，还应该考虑及极端的情况，这样考虑到大目录，就回选择使用一个文件深度对应一个线程，而实现更高效的程序。
四、出租车初级
这次的出租车因为我在写多线程时使用了不同以往的不熟悉写法，导致出现了线程安全的问题，疯狂de了一波bug。本来我信奉不在线程书写方法的原则，而是令写一个普通类，实例化对象后引入线程，例如写一个出租车线程与一个出租车类，然后再出租车线程中出租车类作为成员变量使用，并提供出租车的方法。但是这次图方便将两个合并（事实上给自己带来了更多的不便）。或许这种写法并没有不适，但是由于我对于多线程的方法锁以及类锁的理解不够透彻而导致出了不少问题，还需努力。
