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

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

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

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

心得体会

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

2、在线程的控制方面，总是会在时间的精确度上出一些问题，主要是在线程的调度方面会发生一些延迟，这些问题目前还没有找到合适的解决方案，现在能做的就是尽量简化代码的运行量。

3、感觉每次做作业之前都没有进行系统的学习就开始写代码，导致中间很多环节不会写又要到回头去学习，而且没有一个整体的框架。还是要把基础知识巩固才行。