标签：tail 自己的 在线 加锁 schedule 文件 调整 存在 扫描
多线程电梯
设计策略
用户发出请求加入请求队列，调度器根据电梯的状态为电梯分配请求，每个电梯有自己的执行队列，根据执行队列的请求来改变自身的状态。用户请求处理器和调度器共享请求队列，调度器和电梯本身存在对电梯状态进行同时读写，因此需要对这两个做数据保护。
一开始以为电梯是要模拟真实运行状态，对时间不做调整，后来发现上下一层时间和开关门时间是非常精确的3.0s和6.0s，于是增加了一个时间系统来管理时间。另外，本次作业个人认为有一个最大的矛盾点，就是一方面尽管是同一行输入的请求，即同一时刻发生的请求，还是会考虑实际调度情况存在实际执行的先后顺序，另外一方面又要使同时输入并且执行时间相同的请求同时完成。（实在难以理解）
这个矛盾点主要在于这样的测试样例：
(ER,1,5);(ER,2,5);(ER,3,5);(FR,6,DOWN)
END
如果存在调度顺序，那么FR请求应该分配给实际上先执行完的一号电梯，而不是随机分配。
实际上这个矛盾还是能够实现的，只不过懒得改了，只要用一个真的很假很假的时间系统就可以实现状态同步了。
OO度量
在判断电梯状态选择电梯分配时由于判断条件多存在if嵌套过多，嵌套块深度过大；另外，调度器schedule方法承担了筛选同质请求，分配请求的功能，致使圈复杂度过大。
类图
优点：请求类使用了继承，减少了属性数量
缺点：调度器类承担功能过多
时序图
设计原则
违背了单一职责原则，电梯状态的改变应该由电梯本身完成，而不是由调度器的command方法来改变。基本符合其他设计原则的要求。
IFTTT
设计策略
这次作业的设计主要在线程上纠结，纠结一个监控任务一个线程还是一个触发器一个线程，最后还是选择了后者。所以在监控扫描文件时，由于一个触发器有多个触发任务，监控上由于存储顺序存在时间误差，只能要求测试者每隔一段时间做一次晚间操作。另外，由于记录触发信息用的是同一个输出流，所以要对Summary和Detail加锁，防止出现同时输出。
OO度量
类图
优点：构造了触发器类，一个触发器一个线程，减少了线程数量
缺点：文件类没有真正实现文件安全，触发器类由于线程运行顺序的原因在同一个周期获取到的文件快照可能不一样
时序图
设计原则
对于触发器类没有使用继承，没有将几个触发器的共性抽象成父类，违背了重用原则
出租车
设计策略
这次作业沿用了很多多线程电梯的设计策略，输入处理器和调度器共享一个请求队列，调度器和出租车可能出现同时读写出租车信息，所以对这两处地方要做一个保护。由于时间也要精确，于是构建了一个时间系统，来统一管理时间。另外，为了统一管理100辆出租车的信息，构建了一个TaxiControl类来统一更新出租车信息。
由于更新一百辆出租车的信息和为订单选择出租车都要在200ms内完成，所以很多地图信息需要直接获取，如果在线程运行时计算则会耗费很多时间，所以在初始化的时候就把地图信息计算好，包括节点间距离等等。
OO度量
嵌套块深度过高，圈复杂度过高。
类图
优点：按功能分类，职责清晰
时序图
设计原则
此次设计经过较长时间的思考，基本符合各类设计原则。
bug分析
多线程电梯
①同时输入且执行时间相同的请求由于多线程调度的不确定性没有办法同时完成
②程序输入END有时不能停止
IFTTT
监控目录时，有的重命名和路径改变无法扫描到
出租车
无
寻找bug的策略
①看readme,看一些指导书没有规定的内容，代码实现和readme是否符合
②阅读代码，寻找逻辑错误，看是否实现了线程安全，并构造测试样例来实现错误
③边界测试，看能不能顶得住压力
心得体会
①对线程安全有了更深的理解，对共享对象能做更好的数据保护
②设计构思更加用心，在构思的时候能有意识的遵循设计原则
③OO作业真的惨，真的惨，惨惨惨
标签：tail 自己的 在线 加锁 schedule 文件 调整 存在 扫描
原文地址：https://www.cnblogs.com/HAOHUANG/p/8975740.html
