OO第二单元总结——多线程的魅力

目录

  • 设计策略
  • 代码度量
  • Bug分析
  • 测试策略
  • 心得体会

一、设计策略:

  这三次作业我都采用了”生产者-消费者模式“,以调度器为生产者,电梯为消费者。不同之处在于第一次和第二次都只用了一个生产者-消费者队列,而第三次则使用了三个生产者-消费者队列。

  为什么需要使用“生产者-消费者模式”?

  因为在作业中,调度器产生 request 速度和电梯处理 request 的速度不相同,需要使用队列来作为缓冲器,平衡两者的处理速度。同时通过队列传递消息,避免调度器和电梯的直接交互,一方面可以解耦,另一方面也可以简化线程安全的实现,在这种模式下,由于不同线程只能通过队列进行消息传递,因此只需要保证队列的线程安全性即可。

二、代码度量:

  1. 类图:

    • 第一次作业:
      1615703-20190422213025203-244765630.png

    • 第二次作业:
      1615703-20190422213101709-1530778081.png

    • 第三次作业:
      1615703-20190422212905665-1404582707.png

  2. 度量:

    • 第一次作业:

      Methodev(G)iv(G)v(G)
      Dispatcher.Dispatcher()111
      Dispatcher.addRequest(PersonRequest)111
      Dispatcher.getInstance()113
      Dispatcher.kill()111
      Dispatcher.patchRequest()267
      Dispatcher.resister(Elevator)111
      Dispatcher.run()167
      Elevator.Direction.Direction(int)111
      Elevator.Direction.getDirection()111
      Elevator.Elevator()111
      Elevator.close()112
      Elevator.determineDirection(int,int)113
      Elevator.getRequestQueue()111
      Elevator.move()112
      Elevator.open()112
      Elevator.passengerIn(int)111
      Elevator.passengerOut(int)111
      Elevator.pickPassenger(int)123
      Elevator.run()334
      Main.main(String[])324
      RequestQueue.getRequest()324
      RequestQueue.isEmpty()111
      RequestQueue.kill()111
      RequestQueue.putRequest(PersonRequest)111
      ClassOCavgWMC
      Dispatcher2.5718
      Elevator1.616
      Elevator.Direction12
      Main33
      RequestQueue1.56
    • 第二次作业:

      Methodev(G)iv(G)v(G)
      Direction.Direction(int)111
      Direction.getDirection()111
      Dispatcher.Dispatcher()111
      Dispatcher.addRequest(MyRequest)111
      Dispatcher.getInstance()113
      Dispatcher.kill()111
      Dispatcher.patchRequest()122
      Dispatcher.resister(Elevator)111
      Dispatcher.run()168
      Elevator.Elevator(int,int,int,int)111
      Elevator.arrive()111
      Elevator.close()111
      Elevator.determineDestination(ArrayList)327
      Elevator.determineDestination(int,int)112
      Elevator.determineDirection(int)112
      Elevator.getRequestQueue()111
      Elevator.getSame()126
      Elevator.isOut()133
      Elevator.move()116
      Elevator.open()112
      Elevator.passengersIn(ArrayList)122
      Elevator.passengersOut(ArrayList)122
      Elevator.run()5710
      Main.main(String[])324
      MyRequest.MyRequest(PersonRequest)111
      MyRequest.equals(Object)212
      MyRequest.getDirection()112
      MyRequest.getFromFloor()111
      MyRequest.getPersonId()111
      MyRequest.getToFloor()111
      MyRequest.hashCode()111
      MyRequest.toString()111
      RequestQueue.getRequest(int,int,int)324
      RequestQueue.getSame(int,Direction)1810
      RequestQueue.isEmpty()111
      RequestQueue.kill()111
      RequestQueue.putRequest(MyRequest)111
      RequestQueue.tryGetRequest(int,Direction)133
      ClassOCavgWMC
      Direction12
      Dispatcher1.8613
      Elevator2.6437
      Main33
      MyRequest1.2510
      RequestQueue3.1719
    • 第三次作业:

      Methodev(G)iv(G)v(G)
      Direction.Direction(int)111
      Direction.getDirection()111
      Dispatcher.Dispatcher()111
      Dispatcher.Node.Node(int,int)111
      Dispatcher.addRequest(MyRequest)111
      Dispatcher.addTransfer(MyRequest,int,RequestQueue,RequestQueue)111
      Dispatcher.divReq(MyRequest,ArrayList)71419
      Dispatcher.getInstance()113
      Dispatcher.kill()111
      Dispatcher.nodeInit(ArrayList)324
      Dispatcher.patchRequest()133
      Dispatcher.resister(Elevator)111
      Dispatcher.run()168
      Dispatcher.trySimPat(MyRequest,ArrayList)344
      Elevator.Elevator(String,int,int,int,int,int,TreeSet)111
      Elevator.arrive()111
      Elevator.close()111
      Elevator.determineDestination(ArrayList)327
      Elevator.determineDestination(int,int)112
      Elevator.determineDirection(int)112
      Elevator.getPasNum()111
      Elevator.getRequestQueue()111
      Elevator.getSame()126
      Elevator.getStopFloors()111
      Elevator.isOut()133
      Elevator.move()116
      Elevator.open()112
      Elevator.passengersIn(ArrayList)122
      Elevator.passengersOut(ArrayList)122
      Elevator.run()5811
      Main.init()166
      Main.main(String[])324
      MyRequest.MyRequest(PersonRequest)111
      MyRequest.MyRequest(PersonRequest,MyRequest)111
      MyRequest.equals(Object)414
      MyRequest.getDirection()112
      MyRequest.getFromFloor()111
      MyRequest.getOut()112
      MyRequest.getPersonId()111
      MyRequest.getToFloor()111
      MyRequest.hasArrived()111
      MyRequest.hashCode()111
      MyRequest.toString()111
      RequestQueue.getReqNum()111
      RequestQueue.getRequest(int)537
      RequestQueue.getSame(int,Direction)3811
      RequestQueue.kill()111
      RequestQueue.putRequest(MyRequest)111
      RequestQueue.tryGetReq(int,Direction,int,int)346
      ClassOCavgWMC
      Direction12
      Dispatcher3.0934
      Dispatcher.Node11
      Elevator2.540
      Main4.59
      MyRequest1.4516
      RequestQueue424
  3. UML协作图:

    因为我三次使用的都是生产者-消费者模式,就只给出一个协作图,避免冗余。

    1615703-20190422215003433-1173337889.png

  4. 设计分析:

    这三次的作业基本上遵守了开闭原则,并且由于调度器和电梯解耦的程度比较高,我每次增添新需求的时候改动的代码都极少、增加完代码后需要修补的Bug也很少,因此作业完成的速度很快。

    但同时也有不少问题:

    • 首先,第一次我在楼层、开关门时间、运行时间上都使用了硬编码,这是在写面向对象程序时非常致命的问题,往后写程序的时候也要注意这个问题。

    • 其次,从度量数据可以看出来,在第二、第三次作业中,Elevator和Dispatcher类的复杂度都是极高的,这是由于大量的任务都积累到这两个类来完成,而不是采用拆分的方式去完成。这就导致了代码比较复杂,可读性和维护性都有所下降,并且我目前也没有想到很好的方法去解决。

三、Bug分析:

  由于我在写代码之前就详细分析过了线程之间交互的方式,并且严格控制共享对量及其访问途径,因此公测和互测的时候均没有被找出Bug。

  同时我写完代码测试的时候也基本上没有出现过Bug,唯一的一个Bug还是因为修改代码的时候不小心把synchronized给删了导致的。

  多线程Debug是十分困难的,因此我非常推崇在写代码之前就仔细分析好共享变量的问题,在写代码之前就预防Bug的出现,要比在写完代码之后痛苦地Debug要好很多,至少对于多线程编程而言是如此。

四、测试策略:

  我无论是测试自己的代码还是测试互测时同组人的代码,都是用评测机自动生成请求、自动评测的,这一做法虽然并不高明,可能一些隐蔽的问题需要很长时间的测试才能测出来,甚至由于平台、负载的原因无法测出来。但是它能够基本解放人的劳动,提高效率。

  因为有评测机,我就没有结合他人的具体代码去设计测试用例了,同时我使用的测试方法与第一单元相同——都是使用评测机。

五、心得体会:

  1. 线程安全方面:
    • 首先是对共享变量的访问控制问题,尽量文档化共享变量可能的访问途径,并且控制访问途径,以简化线程安全性的分析。
    • 注意相互依赖状态的修改问题,相互依赖的状态不能分开同步。
    • 要善于使用 volatile 和 final 来解决同步性的问题,不要无脑使用 synchronized,要意识到对于多线程的性能优先原则。
    • 牢记 Java 虚拟机提供给并发编程人员的保证—— happens-before 原则。
  2. 设计原则方面:
    • 在设计原则方面,因为自己犯了硬编码的错误,因此我对这个问题深有感触。在面向对象程序设计过程中,要时刻意识到需求是会不断变化的,通过可变状态来控制行为无论是从可维护性上还是从可读性上都要远远好过硬编码的方式。
    • 遵守开闭原则,许多的设计模式都是以此为基础的,面向不同的需求、可能的扩展需求和程序的实现方式要灵活地采用设计模式。

转载于:https://www.cnblogs.com/Nemory/p/10753175.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值