2023年北航OO第二单元总结

2023年北航OO第二单元总结

2023年北航OO第二单元总结

第一次作业

需求分析

这次作业需要我们实现六部电梯，让六部电梯将乘客从出发位置运动到目标位置，因为有多部电梯，所以需要对请求进行分配，在指导书中推荐使用ALS算法，本单元作业都需要使用多线程。

实现方法

该单元需要使用多线程的知识来解题，我也是第一次接触多线程的知识，所以开始的时候一直处于一种很懵的状态，特别是在进行调度的时候，我希望写一个好的调度算法来是的程序运行的时间减少，但是调度的时候就需要看到电梯的状态，但是电梯的状态是一直在改变，所以就一直想一直想，最后迫不得已使用了最简单的均等分配调度策略。
本次我一共开了三个线程：输入线程、调度线程、电梯线程。其中输入线程负责将请求放入到waitPool中，调度线程负责将waitPool中的请求分配到每一个电梯当中，电梯负责将每一个人运输到指定位置。
在这一个过程中，线程安全十分重要，在第一次中我使用了synchronized、wait和notifyAll。使用synchronized将每一个线程中的代码块给框住，这样确实是线程安全了，但是强侧全部寄了……

电梯运行策略

电梯负责将人运输到指定位置，我在电梯类总有创建了两个对象，waitQueue和runQueue，我认为这个的好处是，我锁住的地方就仅仅只为将requestQueue中的请求放入waitQueue中的过程，而其他的我都不需要锁住，这样提高的效率。
在电梯中有一个对象direction，这个对象表示电梯的运行方向，1为向上-1为向下0代表暂停。while中电梯每次只运动一层，当电梯第一次运行时，会先判断direction是否为0，如果为0那么将看waitQueue和runQueue中是否为空，如果为空，那么continue，否者从waitQueue中随意拿出一个人判断电梯该往哪一个方向。每移动一层，电梯就需要判断一下电梯是否需要停下来，比如当direction为1，而此时在11层，或者runQueue和waitQueue中没有人时，那么就需要停下来。

结构分析

UML图：

Class metrics：

Method metrics：

代码规模：

本次代码一共有450行，相对来说规模比较小。

第二次作业

第二次作业添加了两个要求，一是电梯的维修，二是电梯的添加。
对于第二个要求，本次作业中比较容易实现，只需要设置好电梯的参数，然后开一个线程即可。最要命的是第一个要求，这个要求让我找bug找了很久，在发出电梯维修的请求之后，电梯需要在移动两层之内将人给释放出来，也就是要将这些没有结束旅程的人回到waitPool中。这样要求就对线程安全十分看重，我在debug的时候遇到最让我难受的bug就是当将人放到电梯当中，电梯维修的时候，将电梯中的人弹到waitPool中发现电梯当中的人不见了，也就是发生了及其严重的线程安全问题。也就是这次作业让我深刻体会到了线程安全的重要性。

结构分析

本次的结构和第一次相同，只是对各线程做了一些修改。
UML类图：

Class metrics：

Method metrics：

代码规模：

这次相对于第一次增添的代码并不是很多，主要是保证线程的安全。

debug思路

线程安全是十分debug的，因为没办法使用idea中单步调试没法使用，所以只能根据printf打印出信息来自己找问题，但据说printf也会影响线程，不过我在用printf到没遇到这种情况，感觉在单线程中使用printf打印每一个线程的状态确实是一个debug的好方法。

第三次作业

在这次作业中，在前两次作业的基础上添加了可达性问题，也就是一个电梯只能在某些楼层进行接放人，同时限制了一个楼层中服务中和只接人的电梯数量。
对于第二个问题比较容易解决，使用Semaphore就可以解决这个问题。
对于第一个添加的内容就十分困难，因为需要根据电梯的可达性情况来进行分析乘客的换乘情况。这个问题，我是将新创建了一个类来继承PersonRequest，在这个类中，我会将电梯的可达性情况输入到这个类中，该可达性情况使用一个二维数组存下来，在该类中可以调用一个createJournal的方法来生成该乘客的换乘请款，具体的算法是使用深度优先算法来实现，类似于走迷宫的方式，一直向下寻找，知道找到了一条路径到达最终的楼层，在这个类中我覆写了getToFloor和getFromFloor，这样的好处是我在电梯中的很多代码就都不用修改了，而在电梯中当一个乘客到达目的地时（到达getToFloor，并不一定是真的目的地），就会做一个判断该用户类型是PersonRequest还是其派生的一个类型，如果是PersonRequest，那么该乘客的旅程就直接结束了，否者就调用派生类中的isOver来判断该请求是否结束，如果没有则需要重新插入到waitPool中。

结构分析

UML图：

Class metrics：

Method metrics：

代码规模：

本次代码规模也没有很大，主要添加在于先创建了一个类。并实现该类中的方法。

debug思路

在本次debug我首先测试生成路线的模块是否正确，然后在考虑各种数据排列组合的情况。
其实在本次作业写完之后，我发现了一个大的bug，本次作业在最开始的时候告诉我们每一个请求都有一个可达路劲。但是当对一个电梯进行维修时，该电梯中的人就都要出来，如果这个人没有到达自己的目的地，那么这是我们就需要弹回去，并改变这个人的getFromFloor，这个时候这个人的起始位置发生了改变，那很有可能电梯中就没有一条路径让这个人到达自己的目标位置。但是这次弱侧和中测比较弱，并没有测出这个bug。

个人体验

本单元作业是我做的最痛苦的一个单元，主要还是对多线程的理解不够深入，还有就是debug实在太困难。尽管这三次作业做完，但我仍觉得自己对多线程还是很懵的状态，这很多程度上在于我个人不注重理论知识，而仅关注实验结果，但这次代码很多bug在本地无法复现，自己就改这里测试一遍，改那里测试一遍，导致效率很低，做了需要无用功，最后效果也不好。这提醒我自己以后要多注重理论知识。