第五次做业是多线程电梯,而且要求知足捎带和运动量均衡的原则。在设计的时候,个人想法就是主要写一个电梯类来封装电梯的属性,好比所在楼层、运动方向、目标楼层、运动量等等,以后在经过一个调度类来调度指令给三部电梯,从而完成电梯的共同运做。算法
上图中的Request类用来处理需求,主要是检查格式问题、输入值的范围问题等等,以后把处理过的指令传到Queue类中,Queue类储存指令而后分类,再分别存入Global类中,这里的Global是用来储存全局变量的地方,由于考虑到像指令这样的东西不免要被三部电梯去抢用,因此我想把他们存在这里方便锁起来。MultiScheduler是调度器,主要用来检测三个电梯的运动量什么的。由于当时尚未想到把电梯类的三个对象做为参数传入其中,因此致使代码冗长并且出现了BUG。StrDispose类主要的做用是进行字符串的处理,来分解指令,里面存了一些方法去处理字符串,避免写重复的代码。多线程
此次做业个人run函数过于长,由于对于多线程的使用还不熟悉,其实有不少run里面的内容能够提炼到外面的方法中,但又由于惧怕出错而放弃了。并且个人时间用了系统的真正的时间没去用假时间,因此在时间上运行以后会I有偏差,本身也没作复杂的精度处理,因此在时间的问题上也出了BUG。函数
此次做业是文件监管系统,去监管文件的状态是否发生了变化。由于对于这方面很陌生并且把它想的过于复杂,因此好久以后才动笔去写,写的过程当中发现其实这个程序和我想的很不同,主要是监管目录的那一块,目录的变化要经过里面的文件的变化才能体现,但我发现时已经为时过晚,遂放弃之,致使目录的监管几乎没怎么实现,这一会儿致使我被找到了无数多的BUG......测试
此次做业也是写的不怎么美丽,再处理完请求以后就直接用一个BuildThread的类去生成了一个对应的线程,能够说毫无章法可言,在锁的方面只把输出的部分加了锁。总之写的很差。ui
第七次做业是写一个出租车的调度系统,感受这个调度系统的功能也比较完善,能够支持最短路径,而且用上了信用度的概念。我此次做业把主要的东西都放到了Taxi类中,这也致使个人Taxi类过于庞大,测试者也就这个问题报了个人设计缺陷,引觉得戒。线程
上图中的ReadMap用来读地图而且去检测地图的格式是否有问题,Request类用来读入请求并检查请求的格式,Scheduler类用来接收请求并对每个请求生成一个对应的线程,其生命周期为3s。在程序开始时,我先生成了100个出租车线程让他们随意的去跑,以后Scheduler类生成的线程回去检索这100个出租车构成的队列,寻找是否有出租车而且找到最优的那一个,而且调度线程能够改变出租车的运动状态,并将一些参数,好比时间、出发地和目的地等传入其中,此次在时间上我用了假时间,这样在测试中能够保证时间是以200ms稳定递增的。设计
在搜索最短路径的问题上我借鉴了给的GUI里面的bfs算法,由于这个算法跑遍地图上6400个点的时间太长,因此我只在须要的时候去跑一个特定的点。每收到一个指令,其实只须要去跑出发点和目的地两个地方,因此我把它们分别放到出租车和调度器的等待时间中去跑,以免出现很大的时间偏差。3d
输出方面我也是分别放到调度器和出租车中去输出,分别输出乘客的信息和出租车的信息并存入到一个文件中去,给输出的代码块上了锁,防止某个输出输出到一半被打断。输出到一个文件的时候因为可能同时存在多个出租车,因此并非按照一辆车一段输出而输出的,会很杂。对象
从开始对多线程的一头雾水到如今可以勉强使用它并跑出比较正确的结果,我以为已经算是不小的长进。上次OO上机的时候用到的新东西给了我很大的启发,也让我明白到本身如今掌握的多线程的知识还只是九牛一毛,距离真正的在大型工程中去应用还差了很远。因此我在想下次写做业能不能试着用一些除了sleep,start,sychronized以外的东西来充实本身的多线程。blog