zoukankan      html  css  js  c++  java
  • OO第二次博客作业

    To begin with

      在多线程的海洋里遨游了三周后,同学们又有了这难得的一个月一次的OO博客(休息)时间。多线程的各种"玄学"问题可是给我带来了不少困扰和麻烦。而且这三次作业的共性特点就是特别难debug,不仅是难以给自己debug,给别人debug也不容易。就趁这个时间来回顾下这三周的时光吧!

    第五次作业

    1.简述

      经过了傻瓜式电梯、ALS电梯后,同学们又"欢天喜地"地提了三台多线程电梯。这是我正式初识多线程,在迷雾未现的时候进入了这个玄学领域。这次虽说大体上继承了ALS电梯的思路,但由于这次要完全模拟真实情况,我选择了完全推翻重写的策略,让我的代码整体结构和思想和之前的ALS电梯完全不同,以模拟现实的逻辑思路实现了这次作业。我依然保留了一个请求队列来存储电梯请求,在此之外,我还构建了一个等待队列,作为该电梯线程即将执行的请求。与之前相同,我还构建了调度类和主调度方法来对请求队列的请求进行调度。每一台电梯作为一个独立运作的线程,调度类再独立作为一个线程对整体的运作进行调度,共同访问请求队列。

      这一次作业的一大要点便是线程之间的竞争和安全关系。为了使我们的三台电梯不互相争抢请求,修改相关信息,我们不得不使用synchroniezd锁来锁住方法或对象,来避免多线程所谓的"玄学"情况。

    2.程序结构

    Metrics:

     

     UML:

    Uml Sequence:

     3.BUG分析

      这次出现的BUG主要是线程安全的问题。因为是第一次写多线程代码,对线程安全还没有什么认知概念,有些时候只锁了方法却没有锁对象,导致真运行起来还是会出现线程不安全的情况。现在对线程之间的运作有了更深的理解,也理解了锁方法和锁对象(代码块)的实际运行情况,再遇到这种问题时,就知道怎么去解决了。

    第六次作业

    1.简述

      终于送别了电梯,这次作业是对文件/目录进行监控管理,算是对线程安全进行了一次强化训练来加深理解。这次作业难度体现在各种对目录的操作。监控目录时需要监控目录下所有的文件的变化情况,因而需要递归遍历该目录下所有的文件和子目录来获得所有文件的状态变化。值得一提的是,File.io库提供的各种文件操作的方法并不是线程安全的。所以,我们建立了线程安全的SafeFile类来将各种操作方法"安全化"(加上synchroniezd方法锁)。除此之外还对每个触发器各自构建了一个类,根据目录/文件两种方式进行监控。这一次作业的逻辑思考方面比多线程电梯要简单一些,但是对线程要求的处理要求更高。

      值得一提的是,这次测试采用了自动化测试。通过编写Test线程来对自己的代码进行测试,这种测试方法更智能,而且对每一个操作的时间间隔把控准确,更方便人为去判断结果是否符合预期。

    2.程序结构

    Metrics:

    UML:

     

    Uml Sequence:

    3.Bug分析

      这次的bug主要在于对目录监控。对文件监控的四种触发器都比较容易完成,问题主要存在与对目录监控时的path-change trigger。我在判断目录下文件路径移动时有时候嵌套深了会产生一些问题,后来我想了想,应该还是代码逻辑上写的有些错误,跟线程安全什么的应该没有太大关系。而且因为我每个监控请求都开了一个线程,所以如果一个文件/目录同时被多个线程监控并且做出了多个会出发相应触发器的变化时,summary/detail记录的内容值可能会累计,如果一个文件/目录被recover,还可能会导致另外的请求线程记录相应的变化,有时也存在一些无法预料的结果,但一般都是能进行解释的。

    第7次作业

    1.简述

      这次开始写出租车了。第一次就是多线程出租车,但是好在有之前两次多线程作业的基础,加上这次作业的逻辑也不是很复杂,此次作业并没花费太多时间去完成。这次的一大特点是引入了gui,让我们写完代码运行的时候能更直观地去观察出租车运行的效果。我觉得这次作业是写OO以来最有趣的一次,因为GUI动起来以后让人看着很有成就感,很满足,毕竟这100个电梯怎么动都是自己写的,切切实实地感受到了自己的努力终于有了成果。

      这次作业里,我把每辆出租车各自开了一个线程。由于把每个乘客请求都独起了一个线程进行调度,所以并没有写请求队列这种东西。我这次的调度策略是请求选择出租车,在请求类里写上了主调度方法,请求类对象start()后就会调用相应调度方法,每个请求线程的生命周期只有3s,当成功调度选择好出租车后就结束这个请求线程。

    2.程序结构

    Metrics:

     

    UML:

    Uml Sequence:

    3.BUG分析

      这次我在本地测试的时候发现了几个bug,后来都解决了。因为这次出租车的初始位置和移动是随机的,所以有些Bug需要多次测试才能复现。其中一个是请求在调度分配的时候没有把对象和代码块锁起来,导致可能出现一个请求分给多辆车的情况。这也属于线程安全的问题。在多线程编程时线程安全是十分重要的问题,我们应该在平时写代码的时候就有意识去避免线程不安全的情况,以免测试的时候不完备,没有测试到这种bug。

    心得与体会

      转眼间,我们也从电梯写到了出租车。OO的代码作业也没几次了。虽然每次写OO代码的时候都心力交瘁,怨声载道,但是不得不说,这些大量的代码量的积累,对我们本身大有裨益。多次的高强度代码编写,让我也习惯了长时间坐在电脑前coding。我觉得最用成长的就是测试环节了。以前学数据结构的时候,大多都是本地随便测两个弱测然后就交上去让评测机debug,这种方式没有让我的测试能力得到锻炼。但是每次OO作业的大量测试,是我通过bug分支树,自己对指导书和题目的理解,不断地编写测试代码/样例来完成的。而且第六次作业开始引入了自动化测试,让我也是见识到了新的世界。希望自己能在最后几次代码作业中拼尽全力,不让之前每一次的努力留下遗憾。

  • 相关阅读:
    (转)CortexM3 (NXP LPC1788)之IIS控制器
    (转)ARMThumb 过程调用标准
    (转)CortexM3 (NXP LPC1788)之看门狗定时器对Flash编程的影响
    (转)CortexM3 (NXP LPC1788)之ADC数模转换器的应用
    (笔记)电路设计(一)之上拉电阻与下拉电阻的应用
    (转)CortexM3 (NXP LPC1788)之EEPROM存储器
    (转)CortexM3 (NXP LPC1788)之IIS应用UDA1380进行音频数据播放
    (转)CortexM3 (NXP LPC1788)之WDT窗口看门狗定时器
    (转)CortexM3 (NXP LPC1788)之SDRAM操作
    (转)CortexM3 (NXP LPC1788)之IIC应用PCA9532进行IO扩展和LED亮度控制
  • 原文地址:https://www.cnblogs.com/feiyue666/p/8973767.html
Copyright © 2011-2022 走看看