标签：其他 为什么 mon image 重写 多线程 线程 adl 踩坑
三次作业多线程设计
第五次作业多线程电梯的设计为：输入、总调度器、三部电梯，共5个线程。输入和总调度器从共享对象——请求队列——中获取请求，由总调度器向三部电梯系统派发请求，一个电梯系统本身就是继承的第三次作业的具有捎带功能的（拥有一部电梯的）调度器，可以自行处理派发到电梯系统的一系列请求。
第六次作业IFTTT的线程设计为：每个监控作业一个线程，相互之间没有交互。
第七次作业设计为：主线程、100辆出租车、每个请求一个线程。主线程调用输入处理方法每增加一个请求就开启一个请求处理线程，所有请求处理线程共享100辆出租车，可随时获取其状态。（感觉每个改成一个请求处理线程专门处理所有请求似乎更好一些，下次作业实现……）
第五次作业——多线程电梯
（这红红的三行……为什么我记得写的时候只有一行是红的……）
满减红的主要原因如下：
1.在输入处理的方法中因为要判断合法输入的问题，所以用到了不少if。主调度器中判断可捎带、FR请求分配有很多限制，导致大量的if条件判断
2.电梯系统和主调度器中有太多的属性，传入的参数过多。尤其是电梯系统，为了实现功能，不管不顾的加一些属性而不是方法内部的局部变量，来达到各方法内用到变量的统一性
优点：充分利用了上一次作业（具有捎带功能的调度器）
缺点：在线程类代码中直接进行访问控制，调度器拥有对所有对象的引用，把电梯对象当成一般对象进行访问（真的是每次总结都是典型反面教材……）
自己的bug：
1.本次作业是重构的（可以说是重写orz），着重点放在了之前捎带和电梯运动的设计上所以忽略的输入处理，readme和一部分也没有更新，导致不支持超过int范围的数字，输入楼层数超过int范围，程序直接crash（啊多么痛的领悟……）
2.readme写的比较仓促说了没有说电梯号不支持#和前导0，被抓住了小辫子
测试代码的bug：
1.电梯的时间受输入end的时间的影响
2.电梯在开关门状态时输入会多开一次门
3.捎带问题（时间久远真的记不清了……）
依旧是黑盒测试，菜鸡看代码看不懂啊orz
第六次作业——IFTTT
Detail类是从来记录detail任务的类，里面存入一段时间内触发detail任务对应作业的详细信息，由于没有整理成一条信息传入，而是分别四项前后的变换，所以……这个传入的参数非常多，红色就又出现了。
MoniterFile是监控文件的方法，由于里面触发触发器后的处理是三个任务一起写的，所以嵌套了好几层if，满减红就又出来了
这次作业有一点做的比较好就是每个类每个方法都各尽其职，但也没有包揽所有的任务。很多方法都抽象成很小的方法（比如各种对比快照的方法），代码看着比较清爽（几个触发器类里的MonitorFile方法除外）
踩坑小能手再次上线，本次踩中的坑有：
1.每个监控任务一个线程（这都不是老师说的一个目录一个监控线程的问题了，情况更为严重orz）
2.四个触发器四个类，其实里面的代码大同小异（可以用继承或者写成一个类，内部抽象）
自己的bug：无
测试代码的bug：
1.rename无法监控子目录下的文件
2.rename作业 被recover后，同目录其他作业保存的不会被触发、但也不会更新，导致detail被再次触发时，记录的变化是recover之前的信息到新信息
第七次作业——出租车
这个表是包括GUI的（所以有些锅我不背。。。）
每次复杂度红似乎都是因为InputHadler，下次作业要好好想想怎么办
ReqSche请求处理线程，传入的参数过多，因为有太多属性了，不知道要怎么改……
自己的bug：无
测试程序的bug：
1.没有指导书输出条目第三项的文件输出
2.出租车送乘客到目的地后信用度不加3
3.无法识别有空格的地图
这一次因为没有输出文件，迫不得已通读了对方代码，难能可贵的是居然看的差不多懂了？？？然后后两条是看代码的时候发现的bug。OO互测一来第一次通过代码分析别人的bug，不得不佩服自己的勇气。其他的问题恕我这个菜鸡实在是不能通过代码看出来了，毕竟没有文件输出，代码也不能随便改……
多线程之路的心得
多线程玄学，通过加锁似乎慢慢得有了好转，然而依旧是懵逼的，需要在作业中继续摸索
多线程不易，熬夜伤身，给大家递上护肝片
标签：其他 为什么 mon image 重写 多线程 线程 adl 踩坑
原文地址：https://www.cnblogs.com/jyqin1117/p/8975368.html
