窝窝第二次博客作业

第二次博客作业

前言

java混沌之源——多线程的名气早有耳闻,第一次写具有一定规模的多线程代码还是挺刺激的。

不过,由于之前长期考虑过多线程电梯的架构,这三次虽然写得很绝望,性能分也不算高,但多少

还是没被测出Bug,这一点实属幸运。

1615461-20190420103120441-982463566.png

接下来就主要谈谈三次作业自己的一些设计思路以及优化思路,顺便谈谈自己搭评测姬遇到的一些坑点。

前排感谢 lsj、wsb、shh、xcb四位巨巨(排序由随机函数生成)

1615461-20190420103013788-549431311.png

1615461-20190420103102462-415239796.png

第五次作业

类图

1615461-20190420103209333-1973287613.png

这里,为了观看体验,我把方法以及变量隐去了。

Dispatcher线程负责和电梯的控制器线程(Scheduler)直接交互,DispatcherMain传入的请求分配给电梯的控制器。电梯的控制器周期性苏醒,检查自己的任务列表,对电梯发出指令。

此外,GlobalPermissionDispatcherClose是两个用于控制进程结束的对象。

时序图

Main方法输入端与Dispatcher的交互

1615461-20190420103224986-1309581802.png

Scheduler与Dispatcher的交互

1615461-20190420103240426-2036628316.png

电梯指令(三次电梯作业都沿用)
public enum ElevatorOrder {
    GO_UP,GO_DOWN,STAY_IDLE,OPEN_DOOR,CLOSE_DOOR
}

Elevator的工作机制是这样的,每一个最小时间周期苏醒一次,这代表上一个周期scheduler给电梯下达的指令,电梯已经完成。此时电梯需要向电梯发送自己最新的状态报告,之后根据自身已得到的任务作出下一个周期的指令,并进入执行状态(sleep)

Dispatcher通过blockqueue来查询电梯的状态,即,只有每一个电梯都给分配器发送了自己最新状态的报告,分配器才会认为此时得到的电梯信息足够新鲜,可以作为任务分配依据,才会给各个电梯进行任务分配。

后来在实践中,笔者认识到,这个架构极其 愚蠢 ,原因如下

  1. 在电梯发送自身报告之后,会立刻去检查已经被分配给自己的任务,这就可能出现,dispatcher收集到足够信息刚刚要分配任务时,电梯已经完成了任务检查,那么,这个报告机制失去了它的意义。
  2. 这个“报告”机制导致我需要在线程结束的顺序上做出更多的工作,如果电梯线程先于dispatcher线程结束,那么,dispatcher就可能陷入死等报告的状态,无法结束。这要求,我们必须保证dispatcher线程先于电梯线程结束,这就是为什么,我的设计里有一个突兀的DispatcherClose类。

代码分析报告

Methodev(G)iv(G)v(G)
elevator.Dispatcher.Dispatcher(int,ArrayList<>,Permission,Close)111
elevator.Dispatcher.dispatch()122
elevator.Dispatcher.getNewRequests()111
elevator.Dispatcher.hasWork()122
elevator.Dispatcher.run()144
elevator.Dispatcher.updateReports()122
elevator.Dispatcher.updateRequests()111
elevator.DispatcherClose.close()111
elevator.DispatcherClose.isClosed()111
elevator.Elevator.Elevator(int)111
elevator.Elevator.executeOrder()121116
elevator.Elevator.getRecord()111
elevator.Elevator.getState()111
elevator.Elevator.isInteger(BigDecimal)111
elevator.Elevator.setOrder(ElevatorOrder)111
elevator.ElevatorRecord.ElevatorRecord(int,BigDecimal)111
elevator.ElevatorRecord.getMileage()111
elevator.ElevatorState.ElevatorState(BigDecimal,boolean,ElevatorOrder)111
elevator.ElevatorState.getDoorOpen()111
elevator.ElevatorState.getFloor()111
elevator.ElevatorState.getToDo()111
elevator.ElevatorState.toString()111
elevator.GlobalPermission.forbid()111
elevator.GlobalPermission.getPermitted()111
elevator.Main.main(String[])344
elevator.Scheduler.Scheduler(int,GlobalPermission,DispatcherClose)111
elevator.Scheduler.getDispatchedRequests()111
elevator.Scheduler.getNewRequests()111
elevator.Scheduler.getReportBox()111
elevator.Scheduler.hasWork()133
elevator.Scheduler.meetRequest()134
elevator.Scheduler.pickRequest()134
elevator.Scheduler.run()155
elevator.Scheduler.schedule()646
elevator.Scheduler.sendOrder(ElevatorOrder)111
elevator.Scheduler.sendReport()111
elevator.Sleeper.sleep(long)133
ClassOCavgWMC
elevator.Dispatcher1.4310
elevator.DispatcherClose12
elevator.Elevator318
elevator.ElevatorOrdern/a0
elevator.ElevatorRecord12
elevator.ElevatorState15
elevator.GlobalPermission12
elevator.Main33
elevator.Scheduler1.9121
elevator.Sleeper33
Packagev(G)avgv(G)tot
elevator2.1680
Modulev(G)avgv(G)tot
P52.1680
Projectv(G)avgv(G)tot
project2.1680

可以看出,笔者的这次,因为业务逻辑较为简单,没有出现业务逻辑过于密集的类,但是因为对于电梯控制缺乏经验,与产生电梯指令,执行电梯指令相关的

elevator.Scheduler.schedule()elevator.Elevator.executeOrder()两个方法的复杂度有点过高。

关于SOLID原则

本次作业功能较为简单,本人的重点放在了线程协作架构的可拓展性上了,对于功能的拓展并未做过多深入,故无法提现SOLID原则,其中由于Shceduler类完成了发送报告的工作,违反了SPR原则。

测试

本次的测试不论是自己测自己还是测别人都与前几次作业有很大不同,关于评测姬的搭建,笔者将其放到文末,此处仅仅简要报告测试情况。

自测

本人在自测阶段发现了自己前文所述如果线程退出顺序不对,出现无法结束程序的问题。其它问题,并没有出现。

强测 & 互测

由于业务逻辑简单,故大家都开心无伤过。

顺便%一下shh的23行单线程解决问题的代码,orz

第六次作业

类图

1615461-20190420103335073-78121586.png

本次作业由于引入了地下楼层这个神奇的机制,于是我依据wsb巨巨的建议设置了楼层类,并通过轨道类来管理楼层类。电梯以及其控制器保存同一个Rail(轨道)对象,用于实现与楼层编号相关的计算与转换。此外,这次设计放弃了发送报告的机制,采用ElevatorStatusBuffer作为电梯把自己信息提供给Dispatcher的中转站。

时序图

输入端与Dispatcher的交互

1615461-20190420103352544-1315322238.png

DispatcherElevator的交互

1615461-20190420103402976-1752809106.png

本次我的线程写作关系受到了OS课程的启发

以下文段出自OS指导书

用户态和内核态的概念相信大家也不陌生,内核态即计组实验中所提到的特权态,用户态就是非特权态。mips 汇编中使用一些特权指令如mtc0、mfc0、syscall等都会陷入特权态(内核态)。

而我们这次实验,根据./include/mmu.h里面的布局来说,我们是2G/2G 模式,用户态占用2G,内核态占用2G。接下来,也是最容易产生混淆的地方,进程从用户态提升到内核态的过程,操作系统中发生了什么?

是从当前进程切换成一个所谓的“内核进程”来管理一切了吗?不!还是一样的配方,还是一样的进程!改变的其实只是进程的权限!我们打一个比方,你所在的班级里没有班长,任何人都可以以合理的理由到老师那申请当临时班长。你是班里的成员吗?当然是的。某天你申请当临时班长,申请成功了,那么现在你还是班里的成员吗?当然还是的。那么你前后有什么区别呢?是权限的变化。可能你之前和其他成员是完全平等,互不干涉的。那么现在你可以根据花名册点名,你可以安排班里的成员做些事情,你可以开班长会议等等。那么我们能说你是班长吗?不能,因为你并不是永久的班长。但能说你拥有成为班长的资格吗?当然可以,这种成为临时班长的资格,我们可以粗略地认为它就是内核态的精髓所在。

而在操作系统中,每个完整的进程都拥有这种成为临时内核的资格,即所有的进程都可以发出申请变成内核态下运行的进程。内核态下进程可访问的资源更多,更加自由。在之后我们会提到一种“申请”的方式,就叫做“系统调用”。

我把Dispatcher视为内核,只有一个线程抢到了内核权限,它才能够更新全部电梯在Dispatcher记录的状态,并给各个电梯(包括非“内核态”下的自己)分配任务。

现在看来,我的这个设计有一个问题,如果此时有多部电梯,那么电梯A退出内核态到更新ElevatorStatusBuffer的时间间隙另一个电梯B进入内核态开始查询状态,可能会出现在B分配任务的时候,利用的是一个已经过时的状态,这个问题虽然不一定影响正确性但在某些边界条件下可能会影响性能。

代码质量报告

Methodev(G)iv(G)v(G)
ElevatorSystem.main(String[])355
dispatcher.Dispatcher.Dispatcher(Rail,GlobalPermission)111
dispatcher.Dispatcher.addAlsElevator()111
dispatcher.Dispatcher.addLookElevator()111
dispatcher.Dispatcher.addNaiveElevator()111
dispatcher.Dispatcher.addSillyElevator()111
dispatcher.Dispatcher.dispatchRequests()144
dispatcher.Dispatcher.getBuffer()111
dispatcher.Dispatcher.getElevators()111
dispatcher.Dispatcher.hasMoreWork()133
dispatcher.Dispatcher.setElevators(ArrayList)111
dispatcher.Dispatcher.updateRequests()111
elevator.Elevator.Elevator(int,Rail,SchedulerType,Dispatcher)226
elevator.Elevator.closeDoor()122
elevator.Elevator.executeOrder(ElevatorOrder)277
elevator.Elevator.getDispatcher()111
elevator.Elevator.getHelper()111
elevator.Elevator.getOrderAndUpdateBuffer()111
elevator.Elevator.getRail()111
elevator.Elevator.getScheduler()111
elevator.Elevator.getStatus()111
elevator.Elevator.getStatusBuffer()111
elevator.Elevator.hasMoreWork()111
elevator.Elevator.openDoor()122
elevator.Elevator.run()122
elevator.Elevator.servePassengers()122
elevator.Elevator.updateStatusBuffer(ElevatorOrder)226
elevator.ElevatorFactory.ElevatorFactory(Rail,Dispatcher)111
elevator.ElevatorFactory.produceAlsElevator()111
elevator.ElevatorFactory.produceLookElevator()111
elevator.ElevatorFactory.produceNaiveElevator()111
elevator.ElevatorFactory.produceSillyElevator()111
elevator.ElevatorStatus.ElevatorStatus(int,int,int,boolean,ElevatorOrder)111
elevator.ElevatorStatus.getExecutingOrder()111
elevator.ElevatorStatus.getFloorIndex()111
elevator.ElevatorStatus.getMileage()111
elevator.ElevatorStatusBuffer.ElevatorStatusBuffer(ElevatorStatus)111
elevator.ElevatorStatusBuffer.getStatus()111
elevator.ElevatorStatusBuffer.setStatus(ElevatorStatus)111
exception.FloorIdException.FloorIdException(int)111
floor.Floor.Floor(int)111
floor.Floor.getId()111
floor.Rail.Rail(int,int)113
floor.Rail.getFloorId(int)111
floor.Rail.getFromFloorIndex(PersonRequest)122
floor.Rail.getIndex(int)315
floor.Rail.getToFloorIndex(PersonRequest)122
scheduler.AlsSchedule.AlsSchedule(Elevator)111
scheduler.AlsSchedule.canGetOut(MarkRequest)223
scheduler.AlsSchedule.canPick(MarkRequest)335
scheduler.AlsSchedule.dispatchRequest(PersonRequest)111
scheduler.AlsSchedule.getOrder()727
scheduler.AlsSchedule.hasMoreWork()133
scheduler.AlsSchedule.isNeedServe()535
scheduler.AlsSchedule.meetPassengers()134
scheduler.AlsSchedule.passengersServe()111
scheduler.AlsSchedule.pickPassengers()133
scheduler.AlsSchedule.toString()111
scheduler.AlsSchedule.updateMainRequest()234
scheduler.LookScheduler.LookScheduler(Elevator)111
scheduler.LookScheduler.canGetOut(MarkRequest)223
scheduler.LookScheduler.canPick(MarkRequest)81016
scheduler.LookScheduler.cntNeedDown()123
scheduler.LookScheduler.cntNeedUp()123
scheduler.LookScheduler.dispatchRequest(PersonRequest)111
scheduler.LookScheduler.getOrder()12212
scheduler.LookScheduler.hasMoreWork()122
scheduler.LookScheduler.isNeedServe()535
scheduler.LookScheduler.passengersServe()144
scheduler.LookScheduler.toString()111
scheduler.MarkRequest.MarkRequest(Rail,PersonRequest)113
scheduler.MarkRequest.equals(Object)313
scheduler.MarkRequest.getDirection()111
scheduler.MarkRequest.getFromFloorIndex()111
scheduler.MarkRequest.getNowNeedDirection(int)313
scheduler.MarkRequest.getPersonId()111
scheduler.MarkRequest.getPersonRequest()111
scheduler.MarkRequest.getTargetIndex()222
scheduler.MarkRequest.getToFloorIndex()111
scheduler.MarkRequest.isPicked()111
scheduler.MarkRequest.pick()111
scheduler.NaiveScheduler.NaiveScheduler(Elevator)111
scheduler.NaiveScheduler.dispatchRequest(PersonRequest)111
scheduler.NaiveScheduler.getOrder()737
scheduler.NaiveScheduler.hasMoreWork()133
scheduler.NaiveScheduler.meetRequests()133
scheduler.NaiveScheduler.passengersServe()111
scheduler.NaiveScheduler.pickPassengers()133
scheduler.NaiveScheduler.toString()111
scheduler.RunTarget.RunTarget(int,Direction)111
scheduler.RunTarget.getRunDirection()111
scheduler.RunTarget.getTargetIndex()111
scheduler.RunTarget.toString()111
scheduler.SillyScheduler.SillyScheduler(Elevator)111
scheduler.SillyScheduler.canGetOut(MarkRequest)223
scheduler.SillyScheduler.canPick(MarkRequest)7510
scheduler.SillyScheduler.dispatchRequest(PersonRequest)111
scheduler.SillyScheduler.getDistance(MarkRequest)111
scheduler.SillyScheduler.getOrder()515
scheduler.SillyScheduler.getRunDirection(MarkRequest)313
scheduler.SillyScheduler.hasMoreWork()122
scheduler.SillyScheduler.isNeedServe()535
scheduler.SillyScheduler.passengersServe()156
scheduler.SillyScheduler.selectMaintarget(int,int,int,int,int)8812
scheduler.SillyScheduler.setMainTarget(int,Direction)111
scheduler.SillyScheduler.toString()111
scheduler.SillyScheduler.updateMainTarget()547
tools.GlobalPermission.isSystemContinue()111
tools.GlobalPermission.systemQuit()111
tools.GlobalPermission.systemStart()111
tools.OutputHelper.finalOutput()122
tools.OutputHelper.output(OutputHelper)122
tools.OutputHelper.println(String)111
tools.TimeManager.idleSleep()123
tools.TimeManager.moveSleep()123
tools.TimeManager.serveSleep()123
ClassOCavgWMC
ElevatorSystem33
dispatcher.Dispatcher1.1813
elevator.Elevator2.233
elevator.ElevatorFactory15
elevator.ElevatorOrdern/a0
elevator.ElevatorStatus14
elevator.ElevatorStatusBuffer13
exception.FloorIdException11
floor.Floor12
floor.Rail1.89
scheduler.AlsSchedule2.7533
scheduler.LookScheduler3.7341
scheduler.MarkRequest1.6418
scheduler.NaiveScheduler2.2518
scheduler.RunTarget14
scheduler.SchedulerTypen/a0
scheduler.SillyScheduler3.5750
tools.Directionn/a0
tools.GlobalPermission13
tools.OutputHelper1.675
tools.TimeManager26
Packagev(G)avgv(G)tot
55
dispatcher1.4516
elevator1.7447
exception11
floor2.1415
scheduler3.15189
tools1.8917
Modulev(G)avgv(G)tot
Project62.5290
Projectv(G)avgv(G)tot
project2.5290

经过分析可以发现,方法的复杂性依旧体现在调度算法的实现上,这一类方法始终是复杂度最高的方法。

此外此次作业中电梯类的设计耦合度过高,主要是因为我在设计构造方法的时候欠考虑了,导致电梯的构造与管理非常混乱。

关于SOLID原则
  1. 单一责任原则:

    删去了Scheduler的发送报告方法,使其功能更加单一——根据请求与电梯状态控制电梯行为

  2. 开放封闭原则

    我的RailFloor支持扩展,且不必修改任何原有的功能方法,并且在第三次作业中得到了应用,这两个类符合开闭原则。

  3. 里氏替换原则

    本次设计本人未使用继承操作,故不涉及。

  4. 依赖倒置原则

    本次作业本人采用了多种电梯的控制策略,都采用了Scheduler这一接口,同时他们的实现各有特点。

  5. 接口分离原则

    这次的设计仅仅使用了Scheduler这唯一的接口,且都是有必要的方法,故不涉及。

性能优化

奇技淫巧

关于测试

我方Bug

本人这次的Look算法有很严重的Bug:如果此时电梯处于Idle状态,且上下同时各自来一个请求,且无后续请求,那么电梯将卡死不动。但是,这个Bug被我的奇技淫巧优化给巧妙地回避了。所以在强测和互测都没有翻车。

对方Bug

这次同屋神仙有丶多,代码风格好看,命名规范,算法强大,鄙人才学疏浅实在找不出问题。

第七次作业

类图

1615461-20190420103508963-415345844.jpg

本次作业中,我给Floor加入了访问权限这一设定,每一部电梯通过自己私有的Rail可以查询自己是否有权限在当前楼层停靠。为了便于实现换乘的功能,我引入了TemRequest这个概念(为了保证类图的简洁直观,并未在图中体现),这类对象的作用在于,划分行动路径,把难以一步到位的请求分割成多个可一步到位的请求,把这些可以一步到位的请求称之为TemRequest。本次设计中,我引入了Person类,其保存了乘客的楼层位置信息TemRequest请求是否分配给电梯等信息。前文提到,我们需要实现对请求的分割,RequestDivider所完成的即是这一工作。至于识别请求可否一步到位,这个任务交给了RegionJudger来完成。其余部分与第六次作业设计类似,故不赘述。

时序图

输入端与Dispatcher的交互

1615461-20190420103524175-1660376576.png

DispatcherElevator的交互

1615461-20190420103533252-601822414.png

本次设计我沿用了第六次作业的内核态模式,不过更加“集权”。此次设计中,各个线程在没有Dispatcher权限的时候,甚至无法给自己下达指令,无法改变自己的状态。这么设计看似有丶违背常理,但是这么做有一个好处,我可以保证线程在Dispatcher权限下查询到的各个电梯的信息,在完成此次任务分配时都一定时有效的信息,即,与此时各个电梯的状态完全一致。

代码分析报告

代码复杂度
Methodev(G)iv(G)v(G)
ElevatorSystem.main(String[])366
algorithm.Allocater.Allocater(RegionJudger)111
algorithm.Allocater.canByTheWay(int,Direction,PersonRequest)337
algorithm.Allocater.selectAb(PersonRequest)426
algorithm.Allocater.selectAbc(PersonRequest)11120
algorithm.Allocater.selectBc(PersonRequest)636
algorithm.Allocater.selectElevatorAllocate(Person,Status,Status,Status)858
algorithm.Allocater.updateValue(Request,Status,Status,Status)111
algorithm.RegionJudger.ACanSolo(PersonRequest)122
algorithm.RegionJudger.BCanSolo(PersonRequest)122
algorithm.RegionJudger.CCanSolo(PersonRequest)122
algorithm.RegionJudger.RegionJudger(Rail,Rail,Rail)111
algorithm.RegionJudger.canSolo(PersonRequest)133
algorithm.RegionJudger.floorIndexInAHighRegion(int)122
algorithm.RegionJudger.floorIndexInALowRegion(int)112
algorithm.RegionJudger.fromARegion(PersonRequest)111
algorithm.RegionJudger.fromBRegion(PersonRequest)111
algorithm.RegionJudger.fromCRegion(PersonRequest)111
algorithm.RegionJudger.getCanTakeMode(PersonRequest)6510
algorithm.RegionJudger.inHighRegionA(PersonRequest)122
algorithm.RegionJudger.inLowRegionA(PersonRequest)122
algorithm.RegionJudger.onlyACanSolo(PersonRequest)133
algorithm.RegionJudger.toARegion(PersonRequest)111
algorithm.RegionJudger.toBRegion(PersonRequest)111
algorithm.RegionJudger.toCRegion(PersonRequest)111
algorithm.RequestDivider.RequestDivider(Rail,Rail,Rail,RegionJudger)111
algorithm.RequestDivider.setPersonTemRequest(Person)141516
algorithm.RequestDivider.setPersonTemRequest1(Person)131213
algorithm.RequestDivider.setTemRequest(Person,int,int)111
dispatcher.Dispatcher.Dispatcher(GlobalPermission)111
dispatcher.Dispatcher.allocatePerson()155
dispatcher.Dispatcher.allocatePersonToElevator(Person,int)113
dispatcher.Dispatcher.checkPersonArriveDestination()424
dispatcher.Dispatcher.dispatch()111
dispatcher.Dispatcher.getBuffer()111
dispatcher.Dispatcher.getElevators()111
dispatcher.Dispatcher.getNewInputRequests()122
dispatcher.Dispatcher.getPersonById(int)323
dispatcher.Dispatcher.hasMoreWork()133
dispatcher.Dispatcher.passengersIn(ArrayList,int,int)122
dispatcher.Dispatcher.passengersOut(ArrayList,int,int)122
dispatcher.Dispatcher.personIn(Person,int,int)113
dispatcher.Dispatcher.personOut(Person,int)111
dispatcher.Dispatcher.update()111
dispatcher.Dispatcher.updateElevatorStatus()111
dispatcher.Dispatcher.updatePersonFloor()267
dispatcher.Dispatcher.updateRequestsDivision()122
elevator.Elevator.Elevator(String,int,Rail,Dispatcher,Timer,Type)225
elevator.Elevator.closeDoor()122
elevator.Elevator.dispatchRequest(PersonRequest)111
elevator.Elevator.executeOrder(ElevatorOrder)255
elevator.Elevator.getCapacity()111
elevator.Elevator.getDispatcher()111
elevator.Elevator.getName()111
elevator.Elevator.getOrderAndPresetStatus()236
elevator.Elevator.getRail()111
elevator.Elevator.getStatus()111
elevator.Elevator.isNeedService()111
elevator.Elevator.notServing()111
elevator.Elevator.openDoor()122
elevator.Elevator.run()122
elevator.Elevator.servePassengers()111
elevator.Elevator.willServing()111
elevator.ElevatorStatus.ElevatorStatus(int,int,int,int,int,Direction)111
elevator.ElevatorStatus.getAllocatedNum()111
elevator.ElevatorStatus.getCapacity()111
elevator.ElevatorStatus.getCarryNum()111
elevator.ElevatorStatus.getDirection()111
elevator.ElevatorStatus.getFloorIndex()111
elevator.ElevatorStatus.getId()111
elevator.ElevatorStatus.isFull()111
exception.FloorIdException.FloorIdException(int)111
floor.Floor.Floor(int,boolean)111
floor.Floor.getId()111
floor.Floor.isCanMooring()111
floor.Floor.setPermission(boolean)111
floor.Rail.Rail(int,int)113
floor.Rail.Rail(int,int,int[])124
floor.Rail.canMooringById(int)111
floor.Rail.canMooringByIndex(int)111
floor.Rail.getFloorId(int)111
floor.Rail.getFloorsSize()111
floor.Rail.getFromFloorIndex(PersonRequest)122
floor.Rail.getIndex(int)346
floor.Rail.getToFloorIndex(PersonRequest)122
person.Person.Person(PersonRequest)111
person.Person.arriveTotalTarget()111
person.Person.getAllocateStatus()111
person.Person.getId()111
person.Person.getLocationId()111
person.Person.getLocationIndex()111
person.Person.getState()111
person.Person.getTargetFloorId()111
person.Person.getTargetFloorIndex()111
person.Person.getTemRequest()111
person.Person.getTotalRequest()111
person.Person.isInA()111
person.Person.isInB()111
person.Person.isInC()111
person.Person.isOutElevator()111
person.Person.setAllocateStatus(AllocateStatus)111
person.Person.setLocationById(int)111
person.Person.setLocationByIndex(int)111
person.Person.setState(PersonState)111
person.Person.setTemRequest(PersonRequest)111
person.Person.toString()111
person.PersonMoveOrder.PersonMoveOrder(MoveOrderType,int)111
person.PersonMoveOrder.getPersonId()111
person.PersonMoveOrder.getType()111
scheduler.MarkRequest.MarkRequest(Rail,PersonRequest)113
scheduler.MarkRequest.equals(Object)313
scheduler.MarkRequest.getDirection()111
scheduler.MarkRequest.getFromFloorIndex()111
scheduler.MarkRequest.getNowNeedDirection(int)313
scheduler.MarkRequest.getPersonId()111
scheduler.MarkRequest.getPersonRequest()111
scheduler.MarkRequest.getTargetIndex()222
scheduler.MarkRequest.getToFloorIndex()111
scheduler.MarkRequest.isPicked()111
scheduler.MarkRequest.pick()111
scheduler.SchedulerForA.SchedulerForA(Elevator)111
scheduler.SchedulerForA.canGetOut(MarkRequest)223
scheduler.SchedulerForA.canPick(MarkRequest)101018
scheduler.SchedulerForA.cntNeedDown()145
scheduler.SchedulerForA.cntNeedUp()145
scheduler.SchedulerForA.defaultMode()313
scheduler.SchedulerForA.dispatchRequest(PersonRequest)111
scheduler.SchedulerForA.getCarryNum()111
scheduler.SchedulerForA.getDirection()111
scheduler.SchedulerForA.getOrder()181920
scheduler.SchedulerForA.getRequestsNum()111
scheduler.SchedulerForA.isFull()111
scheduler.SchedulerForA.isNeedServe()144
scheduler.SchedulerForA.needGetIn()323
scheduler.SchedulerForA.needGetOut()323
scheduler.SchedulerForA.needReAllocated()6512
scheduler.SchedulerForA.passengersGetIn()155
scheduler.SchedulerForA.passengersGetOut()133
scheduler.SchedulerForA.toString()111
scheduler.SchedulerForA.updateMainDirection(Direction)313
scheduler.SchedulerForB.SchedulerForB(Elevator)111
scheduler.SchedulerForB.canGetOut(MarkRequest)223
scheduler.SchedulerForB.canPick(MarkRequest)101018
scheduler.SchedulerForB.cntNeedDown()145
scheduler.SchedulerForB.cntNeedUp()145
scheduler.SchedulerForB.defaultMode()313
scheduler.SchedulerForB.dispatchRequest(PersonRequest)111
scheduler.SchedulerForB.getCarryNum()111
scheduler.SchedulerForB.getDirection()111
scheduler.SchedulerForB.getOrder()151415
scheduler.SchedulerForB.getRequestsNum()111
scheduler.SchedulerForB.isFull()111
scheduler.SchedulerForB.isNeedServe()144
scheduler.SchedulerForB.needGetIn()323
scheduler.SchedulerForB.needGetOut()323
scheduler.SchedulerForB.needReAllocated()6411
scheduler.SchedulerForB.passengersGetIn()155
scheduler.SchedulerForB.passengersGetOut()133
scheduler.SchedulerForB.toString()111
scheduler.SchedulerForB.updateMainDirection(Direction)313
scheduler.SchedulerForC.SchedulerForC(Elevator)111
scheduler.SchedulerForC.canGetOut(MarkRequest)223
scheduler.SchedulerForC.canPick(MarkRequest)101018
scheduler.SchedulerForC.cntNeedDown()145
scheduler.SchedulerForC.cntNeedUp()145
scheduler.SchedulerForC.defaultMode()313
scheduler.SchedulerForC.dispatchRequest(PersonRequest)111
scheduler.SchedulerForC.getCarryNum()111
scheduler.SchedulerForC.getDirection()111
scheduler.SchedulerForC.getOrder()15815
scheduler.SchedulerForC.getRequestsNum()111
scheduler.SchedulerForC.isFull()111
scheduler.SchedulerForC.isNeedServe()133
scheduler.SchedulerForC.needGetIn()323
scheduler.SchedulerForC.needGetOut()323
scheduler.SchedulerForC.passengersGetIn()155
scheduler.SchedulerForC.passengersGetOut()133
scheduler.SchedulerForC.toString()111
scheduler.SchedulerForC.updateMainDirection(Direction)313
tools.GlobalPermission.isSystemContinue()111
tools.GlobalPermission.systemQuit()111
tools.GlobalPermission.systemStart()111
tools.OutputHelper.OutputHelper()111
tools.OutputHelper.println(Object)111
tools.OutputHelper.println(boolean)111
tools.OutputHelper.println(char)111
tools.OutputHelper.println(char[])111
tools.OutputHelper.println(double)111
tools.OutputHelper.println(float)111
tools.OutputHelper.println(int)111
tools.OutputHelper.println(long)111
tools.TimeManager.TimeManager(int,int,int)111
tools.TimeManager.idleSleep()122
tools.TimeManager.moveSleep()122
tools.TimeManager.serveSleep()122
ClassOCavgWMC
ElevatorSystem44
algorithm.AllocateStatusn/a0
algorithm.Allocater4.8634
algorithm.CanTakeModen/a0
algorithm.RegionJudger1.2922
algorithm.RequestDivider7.2529
dispatcher.Dispatcher2.2841
elevator.Elevator232
elevator.ElevatorOrdern/a0
elevator.ElevatorStatus18
exception.FloorIdException11
floor.Floor14
floor.Rail1.7816
person.MoveOrderTypen/a0
person.Person121
person.PersonMoveOrder13
person.PersonStaten/a0
scheduler.MarkRequest1.6418
scheduler.SchedulerForA3.672
scheduler.SchedulerForB3.3567
scheduler.SchedulerForC3.1159
scheduler.SchedulerTypen/a0
tools.Directionn/a0
tools.GlobalPermission13
tools.OutputHelper19
tools.TimeManager14
Packagev(G)avgv(G)tot
66
algorithm4.18117
dispatcher2.3943
elevator1.6740
exception11
floor1.9225
person124
scheduler3.94276
tools1.1919
Modulev(G)avgv(G)tot
Project72.83551
Projectv(G)avgv(G)tot
project2.83551

可见,本人这次的Scheduler,Allocater,RequestDivider等几个类的复杂度过高,这次的电梯设计较为复杂,判断逻辑较为复杂,时间也比较紧,本人没来得及解决这个问题,实属遗憾。

关于SOLID原则
  1. 单一责任原则

    本次设计中,我的各个类的职责分工还是比较明确的,比如RegionJudger,RequestDivider,Dispatcher,Rail,Scheduler几个类的协同工作,各司其职,井然有序,基本符合单一职责原则

  2. 开放封闭原则

    本次设计的开放封闭原则主要体现在Rail上,这个类本身仅仅是给电梯一个楼层编号计算的支持,以及判断是否具有停靠权限,且这是个不可变对象。此次设计中,这个判断是否具有停靠权限的功能就在不做任何修改的情况下直接应用于RegionJuder的工作,体现了开放封闭原则。

  3. 里氏替换原则

    本人此次设计又未使用继承机制,故不涉及此处。

  4. 依赖倒置原则

    本次作业本人采用了多种电梯的控制策略,都采用了Scheduler这一接口,使其具有相同类型的业务功能。体现了依赖倒置原则

  5. 接口分离原则

    这次的设计仅仅使用了Scheduler这唯一的接口,且都是有必要的方法,故不涉及。

性能优化

本次本人的优化主要使用的是wsb巨巨的优化策略,俗称“电踢”策略,来实现半动态规划。

测试

我方Bug
  1. RegionJuder考虑不周

    RegionJudger的业务逻辑较为复杂,稍有不慎就会出现考虑不周的情况。本人在早期确实在此处有几个Bug。不过这种Bug比较容易发现,评测机的大量数据下,这种Bug基本都能暴露出来。

  2. Look算法出现的Bug

    当一个电梯处于IDLE状态,且此时上下同时各来一个请求且无其他请求,那么电梯将陷入永久保持IDLE的状态,这个Bug是中测样例查出来的。

  3. B电梯在3楼开门

    由于本人给B电梯加入了根据自身负载决定是否在奇数楼层踢人下去分配给C电梯的功能且没处理好3楼这个边界条件,故在评测机的扫射下测出了一组B在3层开门的错误,加上一个特判后,问题就解决了。

以上问题全部在提交截止前解决,所以本人在强测与互测中未被查出Bug。

对方Bug

这次我好像又一次误入了神仙屋,他们不仅仅没有被我查出Bug,性能还贼强,我太菜了,哭了。

评测姬遇到的几个问题与解决方案

  • 输出时间戳与自己设定输入时间间的误差影响评测

    解决方案

    1、根据第一条输出的时间与第一条输入的时间进行误差修正,同时放宽对时间的判断的限度,加入0.05s的允许误差。

    2、使用hdl封装的接口,据说用这个可以基本消除这个误差,orz

  • 管道被写满

    之前的评测由于输出较短,一般不会出现这种情况,所以本人没有意识到这个问题,第七次作业中,本人给自己的代码对拍时,发现会各种TLE,后来发现是管道写满了,写入被阻塞,导致TLE

    解决方案

    在不断轮训等待“输入时间窗口”的时候判断被测程序是否往管道中写入了信息,如果写入就读出保存。

    在Java可以通过ImputStreamavailable()方法判断管道内是否已经被写入了信息(如果被写入,那么available != 0)。

  • 使用Java对调用输出流的println一类的方法后,待测程序没有接收到

    解决方案

    随手flush是个好文明。

  • 遇到死锁的程序判处其TLE并防止它继续耗费资源

    解决方案

    不断通过sleep轮训process.isAlive()与是否超过最大时限,如果超过最大时限(轮训结束,且process.isAlive()为真)则判处TLE,同时杀进程。

    关于杀进程

    ubuntu16.04:直接process.destroy()可以把整个进程给杀干净。

    win10:仅仅通过process.destroy无法杀死整个进程,可以通过taskkill来杀死超时的进程。

  • 关于CPU时间的测试

    解决方案

    水群里一位同学的方案,使用time命令可以查询CPU时间,本人尚未亲自尝试,下次窝窝作业可以一试。

    顺便,time命令好像win没有诶,哭哭。

总结

  • 之前的几次作业复杂度都不大,很多类的分工上的不合理并不会造成什么影响,但是到了第七次作业,各种相对复杂的问题扑面而来,原有的沙雕设计难以支持,笔者真正感受到了单一职责原则的强大。
  • 笔者之前一直纠结于分配器线程的设计,学习了OS之后,我想到了可以采用这种类似于内核权限的设计方法,所以说,设计的灵感可以在学习的多个方面找到。
  • 一个好的架构是优化的基础,比如第三次作业,我的内核态模式就较好地支持这种“电踢”半动态规划的优化方案,使得我心态没有完全爆炸

转载于:https://www.cnblogs.com/BerserkerRuaaaaaaa/p/10740157.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值