OO第二次博客作业
作业总结分析
多线程电梯
(1)作业设计
本次作业要求完成能捎带的3个电梯的运行;需要多线程。
这次作业每部的电梯都和之前的电梯大致相同,由请求处理后的请求队列,请求调度,电梯来完成请求,不同的是这次是3部电梯同时运行。
根据需求,将输入处理,请求分配,电梯设计为线程。
输入请求队列并处理后的是需要调度的请求队列,每个电梯线程也拥有自己的请求队列,便于进同质和捎带的判断。
(2)程序分析
本次作业的请求队列是共享资源,输入处理后的请求队列和电梯需要执行的请求队列都没有被写成线程安全类。
对捎带问题上的处理有错,本次捎带是沿用上次电梯的捎带方法。应该对电梯的获得的请求队列判断,遍历当前请求,如果符合就放入电梯的执行队列中。
输出问题,将完成请求后需要输出的信息格式不对。
本次作业第一次使用多线程解决需求,一开始不能理解多线程编程和以前作业的区别,导致设计时出了很多问题。由于第一次使用多线程,对run方法的写法上又很多不合适的地方,run方法太冗杂,对锁的运用也不好,对共享资源的访问处理方法都没有加锁。调度算法也用的很低效的,类的设计不清晰,对多线程仅有大概但不清晰的了解。
IFTTT
(1)作业设计
本次作业目的为实现IF XXX THEN XXX的文件监控与相应操作。
程序设计分为获得监控任务,监控事件触发,完成相应的监控任务。
对每个监控任务创造一个线程,每个监控任务触发后的的输出创建一个输出的线程。
(2)程序分析
在监控任务产生时,因为构造文件系统时每一级目录下的文件都是用线性表来构造,所以每次遍历目录下文件时复杂度很高,上次作业的问题这次作业依旧出现,run方法的还是很复杂,4中触发器的判断和3种任务的执行全部在run中进行。最大的问题是在最初设计时,仅考虑到当前目录下文件改变的情况,没有考虑目录触发器的问题,以及目录改变的情况下recover任务的处理。
这次作业无效,问题在设计时考虑不全,而且run方法冗杂导致后来发现错误想改都改不了,在触发path-changed的时候如果路径改为当前目录下的目录中时无法处理。在遍历方法也很粗糙,遍历可以优化,例如构造时采用树的形式。run方法的内容也可以改的更简便一些。
出租车系统
(1)作业设计
设计100辆出租车的抢单调度系统
大致设计为:
乘客系统交互产生的数据:下单的地址,时间,目的地位置,是否有车接单
出租车与系统的交互:出租车当前位置,出租车状态,信用,乘客位置,目的地位置,抢单结果
系统与乘客的交互,通过控制台输入每个请求,用一个线程处理请求并为这个请求调度出租车,100辆独立的出租车每100ms与系统交互,反馈自身的信息,根据反馈信息在对乘客请求处理反馈,最后信息的输出有一个单独的线程处理。
(2)程序分析
这次作业,将所有出租车存在一个出租车数组中,但是在设计时,没有考虑到SOLID原则,对以后的延展会有隐藏风险,还有对线程安全问题的不了解。
总结
这三次作业让我对多线程有了一些初步浅显的了解,还需要更多的学习。学习线程安全的问题。知道设计时需要满足的12个基本准则,尤其是上次作业,要求满足SOLID原则,者要求代码有鲜明的层次,最高层的需求与对象间的交互,再到对象信息的交互,再细节到每个类对应的具体方法,和对类内信息的维护。