OO面向对象多线程编程做业总结

第五次做业：多线程电梯调度

设计策略

​ 在本次电梯做业当中，我构造了一个电梯请求队列线程，一个调度器线程，三个电梯线程，一个文件输出线程，还有主线程。

​ 调度器扫描用户的请求队列，将每一个队列分配给符合要求的电梯，每一个电梯有本身的请求队列，电梯根据本身的请求队列来改变自身状态。

​ 同步控制主要包含两个点：用户请求队列会被调度器和请求队列输入线程操做，须要进行同步控制，电梯内部的运行队列也会被电梯自己和调度器操做，也须要进行同步控制。

​ 同步控制上，我用了synchronized关键词和wait()与notify()的方法来实现对共享资源的线程安全操做。

度量分析及类图

• 类图：

• 度量分析：

在类的度量分析里面，调度器类和电梯类的复杂度较高，接着分析方法的复杂度。

在调度器中，判断是否能捎带的方法复杂度较高，实际上这一部分彻底能够经过模拟电梯按钮来执行，在bug分析中提到。调度电梯的方法复杂度也较高，主要是要判断电梯外的请求，分析每部电梯的累计运动量等，这里能够更加模块化一些。

电梯类的复杂度主要是方法过多，每次停在某个楼层以后都要从新计算最短的捎带请求。改变思路可让代码简洁不少。

还有个人请求队列中的run()方法当中，我把输入的各类判断所有写在run当中了，这是很很差的习惯，应该让线程的run方法尽可能简洁，把输入的操做模块化。

bug分析

此次做业我在提交以前几个小时才发现一个很重要的bug，这是我在设计思路上的一个缺陷致使的，并且指导书也没有认真阅读。在请求加入请求队列的时候，若是是电梯内的请求应该直接分配给对应的电梯，不须要等待电梯都处于能捎带或者等待服务的状态，而我却让电梯内请求等待了。最后修改的时候直接将请求强行加入到电梯队列当中，这样又致使了捎带问题。

实际上较好的设计思路应该是模拟真实的电梯，给电梯的每一层设置按钮，当有请求发送的时候，改变按钮的状态，在每一层运行的时候都判断按钮是否被按下，若是是同质请求就忽略。

还有就是线程时间的控制上面有较大的偏差，不是特别精确。

发现别人的bug

此次我测试的同窗的bug主要出在格式问题上面，输出的时候括号不少没有按照指导书的要求输出。

第六次做业：IFTTT文件管理系统

设计策略

本次做业中，我从主线程开启输入控制器，从输入中获取须要开启的文件监控器，监控器线程开始对文件进行实时监控，测试线程也同时开启，对文件进行修改操做，监控器检测到文件的变化，将信息发送给操做线程，对相应的文件执行相应的操做。

在同步控制方面，对文件信息的读取和修改须要进行同步操做。

还有一个stop线程是用来控制系统终止的，输入相应的指令，系统会自动退出。

度量分析及类图

• 类图：

• 度量分析：

在InputHandler当中，平均操做复杂度较高，由于在判断格式的方面写的代码较长，能够考虑更加模块化的判断。

各个触发器的平均操做复杂度也比较高。这也和个人设计思路有关，由于一开始没有注意到不少触发器须要监控目录下全部文件的变化，因此一开始没有对文件夹进行监控，后来增长了文件夹监控之后，代码变得冗长。

其实能够用嵌套循环单个文件监控的方式实现文件夹的监控，这样写起来会比较简洁。

bug分析&自我分析

• bug

  在测试较深的目录的时候，个人输出状况会很不稳定，好比未删除前一次的recorddetail.txt的话很容易会不稳定，线程安全的问题没有解决。

• 自我分析

  我把全部的类放在了默认的package里面，这样的架构不是很好。监控器类和操做类均可以分别放在单独的包中，监控器类也能够写成继承一个父类的方式，他们都有对文件进行监控的功能。个人程序的可拓展性和可维护性还有所欠缺。

  程序比较好的地方是用了一个Operation类来对操做进行选择，每次只须要调用Operation，而不须要单独调用每一个操做的方法。

发现别人的bug

对方在线程安全的设计上有所欠缺，不少文件进行了修改之后监控器能够检测到，可是并无进行相应的操做，致使了不少输出是空。

第七次做业：出租车调度系统

设计策略

对于每个出租车，我都开了一个线程，每个符合要求的请求，我都会开一个调度器线程来对出租车进行调度，把符合要求的出租车加入到调度器线程的队列当中，调度器线程运行了3s之后，从队列中筛选出最合适的出租车并将请求发送给出租车执行，请求执行过程当中，出租车须要被上锁，防止其余调度器线程对出租车进行调度。

度量分析及类图：

类图：

此次把不一样功能模块放在了不一样的package里面，information用来存储数据，taxi用来存储出租车和出租车队列，locaiton用来存储坐标和地图，scheduler用来调度，passenger用来存储请求队列，输入请求。

度量分析：

除去gui，平均复杂度最高的是taxi类，taxi的移动和状态转换的确须要不少函数来判断实现，因此不可避免的复杂度升高。

bug分析&自我分析

• 起点终点一致的时候我没有判断错误，而是让出租车进行接单。还有出租车信息文件的输出没有实时输出。

  老问题，输出的时间间隔又有偏差。发现系统的sleep方法的确会产生偏差，因此后面本身写了个sleep的方法进行精确的控制睡眠时间。

• 原本此次做业想使用观察者模式，可是因为涉及的观察者类不是不少，我用了observer和notifier之后反而使代码变得十分冗杂，因此最后仍是放弃了使用这种方法，感受设计模式上还须要多加研究。

发现别人的bug

在线程调度的时间发现了问题，同时输入两条一样的请求被当作两个时间的请求，多是中间代码出现了延迟。

在出租车自由行走之后，经过控制台输出，发现有些没有在规定时间中止一秒。

还有寻找最短路径的过程没有输出。

心得体会

一、在代码结构和设计模式上还须要多加研究，从一开始把全部类都写在一块儿，到后面对不一样类的功能分门别类，也有了一些进步。对于接口和抽象类的使用还须要多加练习，加强程序的可维护性和可拓展性。

二、在线程的控制方面，老是会在时间的精确度上出一些问题，主要是在线程的调度方面会发生一些延迟，这些问题目前尚未找到合适的解决方案，如今能作的就是尽可能简化代码的运行量。

三、感受每次作做业以前都没有进行系统的学习就开始写代码，致使中间不少环节不会写又要到回头去学习，并且没有一个总体的框架。仍是要把基础知识巩固才行。