OO第二单元总结~~

最新推荐文章于 2024-04-20 11:19:16 发布

weixin_30454481

最新推荐文章于 2024-04-20 11:19:16 发布

阅读量108

点赞数

原文链接：http://www.cnblogs.com/ziyeryyyyyyyy/p/10756764.html

版权

OO第二单元总结~~

残念的对着电梯的三周很快就过去了，现在就让我叙述一下这三周对于多线程的学习与认识吧。其实多线程说来难也不难，只要能够理解他们并发的本质与相互沟通的方法，熟练的使用其某些语法与特性。

一、 三次作业的思路与错误反思

第一次作业：

　　在这一次作业中我实际上并没有搞明白什么是多线程，我对于作业的理解完全错误了。在这一次作业中，我的电梯只是一个普通的类，里面只有一个carry函数用来输出，而我把每个人当成了一个线程，每一个人进电梯就化为一个线程，人的run方法就是调用电梯的carry方法。

　　所以有人在看了我的代码之后告诉我，你这个其实就是一个单线程…不过由于这次作业确实比较简单，甚至有人写了薛定谔的电梯也直接通过了，所以我并没有遇到什么大问题。

第二次作业：

在这一次作业中需要使用捎带的方法来调度电梯，由于上次写的完全思路错误，所以这次进行了一次重构。在这一起作业中我自己写了一个线程安全类，叫做Requestqueue，这个类中有两个Arraylist<Request>[]队列，一个队列存上行需求，一个队列存下行需求，因为我是按照楼层存储需求的，所以就使用了Arraylist数组。

输入线程和电梯线程共用了同一个队列，即一个标准的生产者-消费者模型。

在这一次作业中我并没有写调度器，而是使用了轮询的方法，电梯每一趟都会上到最高层或者是下到最底层。电梯在每到达一层的时候，电梯在上行到每一层时就检查这一层有没有人要上行，在下行到每一层时就检查这一层有没有人要下行，并且检查目前在电梯里的人有没有目的地在这一层的，如果有，就开门上下人。

第三次作业：

这一次的作业相比于上一次，有的电梯不能到达某些层，导致必须要换乘，而且电梯有人数的限制。

于是这次我有了一个全局调度器，给每个电梯分配人，具体分配的标准是，分配给能够到起点也能够到终点的电梯，如果没有这样的电梯，则分配给能到起点的电梯，如果多个电梯同时达到了要求，就分配给当前队列里人最少的电梯，如果人数相同，就分配给上下行一层时间最短的电梯。

关于换乘，这次我写了一个比较笨的方法，我先自己手动的看了看三个电梯，对于每一个必须要换乘的需求指定一个换乘楼层，我建立了一个自己的request类，这个类包含起点、终点、换乘点、是否要换乘，在每个输入进来的时候就把这几个属性用request类的方法填好。由总调度器分给某个电梯，该电梯跑完自己负责的一段时候，若发现这是一个需要换乘的任务，就将起点终点修改一下之后，把需要换乘设置为false，再回抛给总调度器，总调度器会继续分配这个任务。

这次每个电梯自己的运行调度相比起上次有了一些进步。如果在上行，就先查看更上层有没有继续要上行的人，或是有人的上行目的地在更上层，如果没有，就调转任务，去接受下行任务，如果更上层没有需要下行的人，就调转电梯方向，不再继续上行。

第三次作业遇到的一个困扰了挺久的问题：

　　关于我的所有线程如何才能够结束。这个本来是一个比较简单的问题，但是由于我的设计，在换乘的时候会有回抛的环节，所以调度器如果先行结束，就接受不到回抛的任务，而如果电梯先结束，调度器重新分配的新任务就会接不到，就比如说输入结束后，A回抛了一个任务给调度器，这个任务调度器应该给B，但是B以为自己没有任务就已经先结束了，导致了输出有误。

　　后来我认识到这个问题的关键在于电梯和调度器什么时候觉得自己能够结束了。怎样才能预知自己之后还会不会接到任务，所以我在调度器里加入了一个参数叫做wait，初始值为0，调度器每次分配出一个需要换乘的任务，wait++，而有电梯抛回一个任务时，wait--，这样其他条件都满足时，等到wait=0时就可以结束。

二、 基于度量分析我的程序架构

三、互测~

　　这几次作业的互测中我实际上并没有怎么参与…因为正如分享课的大佬分享自动化测试的时候说，之后的多线程作业，其实大部分人都不会犯一些能够手动查出来的错，这些错误大部分都隐藏在临界条件冲突的部分，所以我在不使用别人对拍器的情况下，其实很难发现其他人代码的错误。

我认为这几次的错误主要在这几个地方：

1）超时：

　　CPU超时：这个主要是因为线程的设计有问题，在该wait的时候没有wait，强行占据了CPU的时间

　　计算时间超时，这个可能是因为电梯调度方法的问题，当然我认为200+s运行40条指令还是比较宽裕的，所以一般出现这种情况大部分是因为某些地方的调度写错了。

2）电梯惊魂：

没有进去的人出来了，进去的人没有出来，电梯冲破楼顶了，一号乘客被迫害了…emmm这些谜之错误的出现往往是因为某些细节的问题没有处理好，所以写的时候一定要细心！细心！细心！

　　这次出现的无数种错误没有办法很详尽的分析具体是错在哪了，因为一千个人有一千种写法，即便是同样的错误，原因也不尽相同，所以只能够祈祷自己写代码的时候身体健康，头脑清醒，不要写出让人吐血的bug

四、 可以改进的地方

　　我认为第三次作业我写的最垃圾的地方还是我换乘楼层的分析，是自己事先手动分析好然后录入进去的…三部电梯的话还是可以接受的，但是要是更多的话估计就会lay死。上次上研讨课的时候有一个大佬介绍自己的算法，我听到他说乘客要作为一个独立的对象，他们自己需要会换乘，知道自己在哪里换乘，这就需要在passenger（request）类里面再做功夫，让乘客知道哪部电梯能到哪不能到哪，所以这样乘客可以选择自己在几层下电梯，我认为这个方法很好，因为我觉得这次写的电梯其实还是要贴近生活的，这样能够体现人的主观性，更加符合面向对象的设计方法。

　　之前看到有小伙伴介绍自己的电梯调度算法的时候，为了节省一些时间，在某几层之间反复上下、来回接人，达到总时间减少的目的。不过我个人认为，这个写法是能够缩短时间，但是无意义，也不现实，比方说作为一个乘客，如果你自己在电梯里，看着电梯不顾你的需求胡乱的跑来跑去…那么这个电梯确实是很逊哦（不是）0w0

转载于:https://www.cnblogs.com/ziyeryyyyyyyy/p/10756764.html