OO第二次博客

Posted 2020-11-02

 

电梯多线程

设计策略：

由于此次的电梯要求完全模拟现实中的情况，所以主要对电梯的运动方式做了变动，以前是接到请求以后立即转变状态并判断捎带请求，而且由于只有一部电梯，电梯的等待列表是确定的。这次由于有三部电梯，电梯的等待列表也是即时输入的，所以电梯的等待列表需要即时更新，等待列表中哪条请求可以被捎带也是需要即时判定的。

设计的结构是这样的：输入请求的线程每次将输入的请求“检验”后插入三部电梯各自的等待列表中，此时，同质请求应被忽略，之后捎带请求也在这个阶段进行判断，并考虑加到哪个电梯的等待列表中（这个步骤只针对楼层请求）。主体的电梯运行机制相比于第二次电梯并没有太多改变，电梯在接收请求时，区分接收主请求和捎带请求，对于捎带请求应该考虑后进先出的问题。每运动一个楼层，电梯需sleep3000ms，每开关门一次，sleep6000ms。电梯的运动完全由目标楼层和当前楼层决定，每次主请求运动一个楼层，都会从等待列表中遍历搜寻可捎带请求，之后才开始运动，重复此操作直至抵达目标楼层。

对于本次特有的时间系统，设计为请求时间就是请求产生时的系统时间，并把第一个请求产生的时间设定为t0，此后抵达各楼层时，输出的时间为当前系统时间t-t0。

同步互斥问题主要出现在总列表和各自的等待列表中。对三部电梯的等待列表的插入和取出操作不应同时进行。

代码分析：

度量：

问题所在：（其实红色那部分主要内容是第四次作业没删掉的部分，，，，虽然这次的复杂度以及嵌套深度还是存在一定问题）

 

类图：

 

 

IFTTT（文件监控系统）

设计策略：

本次作业无论是思路还是实际设计上，难度都要比电梯和出租车要简单一些。由于指导书对测试者做出的种种限制，我们在设计程序的时候，省却了许多考虑复杂情形的时间（惭愧惭愧，应该考虑到这些要求以外的问题才对，奈何实在是熬夜熬不动了）。

这次的设计上，主体类是监视器线程，每当触发了触发器，便创建一个监视器线程，对指定文件的指定变化进行监视并予以相应操作。

监视：每隔一段时间，进行一次snapshot，判断是否是第一次，如果是，将其存为newshot。如果不是，将当前newshot存为oldshot，之后删除newshot，将当前文件状况存为new

shot，之后应当进行前后对比。

同步互斥问题体现在snapshot和对文件的修改和记录信息上，前者和后者不能同时进行。此外，对文件的修改也不能同时进行，应分批处理。

代码分析：

度量：

问题所在：SpyWorker和Spyer的复杂度问题，SafeFile和SpyWorker的参数过多，SpyWorker的嵌套过深。主要问题出在SpyWorker上，而其确实存在臃肿问题，需要优化以及功能拆分。

 

类图：

 

出租车调度1

设计策略：

看似这次需要建立100个出租车线程，实际上100辆车可以看做一个拥有100个元素的总体，只需建立一个这个整体的线程即可。

首先读入Map，这将是各个类的共享final属性，不会被改变。之后，初始化出租车系统（包含100辆车），随机安排每辆出租车的位置。在出租车系统中，包含singleTaxi类，内含出租车的运动方法。再之后，读入乘客请求，每个请求建立一个monitor线程，在乘客地点的指定范围内反复遍历，在3秒内寻到最佳接客的车，并通过改变其运动路径使其执行请求（将请求传给改编号出租车，并通过BFS计算出路径）。singleTaxi在没有确定路径时会随机运动，而一旦确定，便会沿着指定路径运动。singleTaxi的运动模式通过有限状态机实现。

同步互斥问题主要是GUI中BFS的标记问题，不同monitor对taxi整体的操作不能同时进行（同时同刻应随机判断主次）。

代码分析：

度量：

问题所在：复杂度偏高

 

类图：

 

 

总结

BUG分析：

电梯多线程：①输入END以后依然无法结束程序②时间不是3.0整倍数

IFTTT:①wide测试②输出时没有忽略掉recover执行记录

出租车调度1：①没有满足允许300条以上请求的要求②有时会少输出一条信息

寻BUG方法：

①老办法：看对方有没有出现自己遇到的问题

②新现象：对方会主动自爆

③新手段：由于这3次均为实时程序，而且出租车甚至采取了随机位置，所以同一个测试数据，可以多次输入，花样输入，根据输出的请求时间和结果比对，寻找到存在矛盾的地方，进而发现BUG所在

心得体会：

这三次作业相比于前三次作业而言，最大的不同在于使用了多线程，面临的主要问题也从临界问题转化成了临界区&临界资源的问题。

由于对同步机制的运作了解不够完善，导致我这三次作业之中并没有构建足够效率的结构。正如电梯多线程的PPT中所言，synchronized块越多，越贴近单线程。

但是，经历了这三次作业的磨练，我初步学会了使用多线程解决问题的手段。看着自己的程序随着输入，经过一定“延迟”之后，慢吞吞地吐出处理后的结果，实在是有种成就感。