OO Unit2 Summary

OO Unit2 Summary

目录

  • 一、三次作业分析

  • 二、bug分析

  • 三、心得体会

在第一部分将结合三次作业的uml类图，先分别介绍每次作业的设计思路、同步块与锁的选择以及调度器设计，再展示UML协作图。在第二部分将介绍程序bug、hack和test策略。第三部分讲述心得体会。

一、三次作业分析

1. 第五次作业

UML类图

设计思路

第五次作业要求实现5个单座电梯的运行模拟。

由于第五次作业仅仅为每座1个电梯，且没有动态增加电梯的需求，较为简单。因此第五次作业我采用了输入线程和电梯线程的双线程设计。以RequestTable类对象processQueue作为共享对象，实现输入线程与电梯线程之间的交互。对于电梯的运行，我通过strategy维护电梯的direction和destination变量，当电梯的position与destination相同时，就执行开关门操作。而strategy采取的更新方式是look策略。

同步块与锁的设计

第五次作业在我的设计中，有下列情况需要加锁：

  • 共享对象方法加锁：在共享对象类内定义的方法中，如果涉及对其的读写操作，都需要加锁。

// RequestTable.java
public synchronized void addRequest(PersonRequest pr) {
    requests.add(pr);
    notifyAll();
}

  • 线程中加锁同步块：一些方法不便于直接定义在共享对象类中，但涉及对共享对象的读写操作，这时需要将其加锁。

// Elevator.java
public void pickUpPerson() {
    ArrayList<PersonRequest> renew = new ArrayList<>();
    synchronized (processQueue) {
        ArrayList<PersonRequest> requestTable = processQueue.getRequestTable();
        for (PersonRequest pr : requestTable) {
            if (pr.getFromFloor() == position && insidePerson.size() < capacity &&
                    strategy.toPick(position, direction, insidePerson.size(), pr,
                            processQueue)) {
                insidePerson.add(pr);
                SafeOutput.println(
                        String.format("IN-%d-%c-%d-%d", pr.getPersonId(),
                                id + 'A' - 1, position, id));
            } else {
                renew.add(pr);
            }
        }
        requestTable.clear();
        requestTable.addAll(renew);
    }
}

调度器设计

第五次作业我没有设计调度器线程，我采用的方法是直接在输入线程将对应请求分配到电梯的等待队列。电梯作为线程运行，strategy类帮电梯进行决策，策略是look。

2. 第六次作业

UML类图

 

设计思路

第六次作业增加了动态增加电梯和环形运输的需求。

对于动态增加电梯需求，我设计了调度器线程，用来响应增加电梯请求以及分派乘客。

对于环形运输需求，可以考虑把A->B->C->D->E->A定义为up方向，反向定义为down方法。我设计了一个方法类Direction，该类可以通过输入fromfloor、tofloor或fromBuilding、toBuilding返回一个方向。由于环形电梯和线性电梯逻辑吻合度高，我给电梯增加了type属性，大部分方法得到了复用。只需要针对性设计动作act即可。

此外，由于第五次作业Elevator线程个人设计欠佳，维护direction和destination的方法过于臃肿，导致bug不断。所以第六次作业索性进行了重构，电梯的运行逻辑改为了有限状态机。

 

电梯的运行流程变成了状态转换state transfer以及根据状态运行act。

同步块与锁的设计

由于增加了调度器线程，因此除了电梯和调度器共享的请求队列processQueue，还增加了调度器与输入线程的共享的请求队列waitQueue。但同步块和锁的设计无太大改变，仍然是共享对象方法加锁和线程中加锁同步块的方式。

调度器设计

本次作业中，我增加了调度器线程，其作用是管理相同类的一组电梯(也就是15个调度器)。

  1. 接受增加电梯请求，在队列里增加一个电梯进行管理并启动该电梯线程。为此，需要有与输入线程的共享对象waitQueue以及elevators.

  2. 接受来自输入线程的乘客请求，按照按序依次分配给各个电梯。为此需要有index来标示下一个分配电梯的序号，每分配完一个请求后更新index到下一个电梯。

3. 第七次作业

UML类图

 

设计思路

第七次增加了跨楼座和层之间的请求，给电梯增加了可修改的属性，以及停靠限制。

对于电梯可修改属性和停靠限制，处理很简单，只需要给电梯增添对应的属性即可。

对于跨楼座和层之间的请求。首先我采用了在输入线程静态分解的方式，具体分解方式参考停靠限制、纵向距离最短原则以及各层的空闲程度。其次在各输入线程增加了一个unreadyQueue管理还没有被触发的分请求。当前分请求完成后，在电梯线程将对应调度器线程的下一个分请求调入就绪的队列，等待分配。通过这两点完成了跨楼座和层请求的需求。

同时我设计了AllDispatcher类用于管理所有的dispatcher。它并不是一个线程。

同步块与锁的设计

在第七次作业中，由于在调度器线程中增加了一个新的unreadyQueue队列，就需要在该线程中同时维护两个共享对象，这是本次作业的锁设计的难点。在我的设计中，主要体现在要wait()时应该使用哪个对象的锁？

// Dispatcher.java
synchronized (waitQueue) {
    if (waitQueue.isEmpty()) {
        if (!waitQueue.isEnd() || !unreadyQueue.isEmpty()) {
            try {
                waitQueue.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
    if (!waitQueue.isEmpty()) {
        request = waitQueue.getOneRequest();
    }
}

这里我使用了waitQueue的锁进行wait().

其他地方与前两次作业没有太大差异，此处不再赘述。

调度器设计

在本次作业中，由于电梯的属性可设计，因此不宜采用均分分配乘客的策略。这里我给每个电梯设计一个量busy。计算方法是busy = (1.5 * 电梯待处理请求数量 + 电梯内部请求数量) * 移动一楼层所需时间 / 容量。系数采用1.5是考虑到，平均来说，待处理请求要花费时间较内部请求长。调度器分配时查看其管理的电梯哪个busy最小，就将乘客分配给哪个电梯。

同时需求静态分解也有一定的策略可循，在满足停靠限制、纵向距离最短原则基础上，寻找尽可能空闲的层，分配给该层的调度器。这里我设计了多种计量方式，经过实验比较最终选择了一种较为简单的策略：即选择待处理请求较少的层进行横向运输。

可扩展性分析

我认为我的架构具备一定的可扩展性，比如说对于纵向的停靠限制电梯，只需要在输入线程的静态分解方法判定即可。不需要对分配策略以及代码架构进行大变动即可维持较高性能。

4. UML协作图

 

二、bug、test及hack

bug

第五次作业出现了严重bug，bug是电梯判断人能进入时应该满足内部的人数 < 电梯容量，我写成了 内部人数 <= 电梯容量。同时在look策略的一处地方也是这个人数问题。这两处bug导致了电梯运行故障，于是就wa了很多点。修复这两处bug只需要将等号去掉即可。

我痛定思痛，认为根本原因还是电梯运行逻辑太过混乱，因此也决定第六次作业进行重构。

第六次和第七次作业强测均没有出现bug。第七次作业中测出现了一些bug，主要是因为第七次作业我给调度器线程新增了一个维护的队列，刚开始并没有处理好两个队列的管理关系，导致了诸多线程问题。幸运的是，在思考过后就修改成功了。

test

由于多线程的不可复现性，因此，我的测试方法主要是随机数据进行大量测试。尽可能做到数据全覆盖且线程运行顺序多样。为此，针对第六次和第七次作业我设计了随机数据生成器。以下为部分代码：

if (period == self.period_upper):
    period = 0
    for i in range(self.elevator_add_num):
        file.write("[" + str(round(time, 1)) + "]ADD-floor-" + str(elevator_id) + "-" + str(
            self.rdfloor()) + "-" + str(self.rdcapacity()) + "-" + str(self.rdspeed()) + "-" + str(
            self.rdswiInfo()) + "\n")
        elevator_id += 1
// 周期性动态增加电梯
​
for i in range(self.cross_num):
    fromfloor = self.rdfloor()
    tofloor = self.rdfloor()
    frombuilding = self.rdbuilding()
    tobuilding = self.nofromrdbuilding(frombuilding)
    file.write("[" + str(round(time, 1)) + "]" + str(person_id) + "-FROM-" + frombuilding + "-" + str(fromfloor) + "-TO-" + tobuilding + "-" + str(tofloor) + "\n")
    person_id += 1
// 随机生成跨层跨楼座请求

hack

我的hack策略为针对性构造数据以及大量随机数据攻击。第五次作业时我设计了针对性数据成功hack同房人。第六次和第七次作业采取的随机数据攻击的方式进行hack，可惜的是由于多线程程序的不确定性，虽然在本地运行时hack成功了，但是提交以后bug没有得到复现。

三、心得体会

线程安全

电梯月让我初次接触了多线程编程。一个让我时刻保持警惕的问题就是线程安全，为此也是投入了一些心思。虽然三次作业并没有因为线程安全问题丢分，但是我的架构中仍存在诸多不完美的地方：

  • 没有实现较好的封装。最好的设计是将尽可能多的锁加在共享对象的方法上，以实现外部的无锁结构。离它还有很大距离。

  • 共享对象管理。在最后一次作业时新增了一个队列作为共享对象，本来以为复刻一下第一周的做法就行了，结果同时管理两个队列遇到了诸多问题。好在最后逐一解决了。

层次化设计

反思起来，层次化设计还有许多可以改进的地方。

  1. 第六、七次作业我将电梯的状态变化和策略都写在了Elevator类中，导致其异常庞大，这不是一个优秀的层次化设计，应该考虑将策略和电梯运行分离。

  2. 共享对象的设计也存在不足，我为了处理方便，在设计中多用组合关系(UML类图中可见)，这存在逻辑问题。在进行更高要求的设计时很可能会进行重构。

一些感想

电梯月总算是过完了。第一周时写作业感觉挺顺的，也就没怎么测试，结果强测就来了个下马威。之后每一周都抱着很谨慎的态度对待作业，生怕强测再wa一片。

总之还是不能太浪，对待再简单的作业也得认真。

 
posted @ 2022-04-29 09:58  SleepEarlyGuy  阅读(59)  评论(2)  编辑  收藏  举报