2026OO Unit2总结

王正易-24373224 2026-04-28 15:07:08

2026OO Unit2总结

本次 Unit2 是针对多线程的安全与通信等问题的综合考察，难度很高。在三次迭代中，深刻体会多线程锁的使用。

同步块设置

本次作业中，我的同步块设置都比较粗，很容易导致死锁问题，这也是我后面迭代出现的主要bug。主要的同步块设置在了总请求队列 RequestQuque 和电梯处理队列 ProcessingQueue 中的新增请求和取出请求，和电梯线程的状态获取。设计架构主要仿照第二单元的训练题目，虽然在请求处理上并不是队列的形式，但一定程度上依旧先进先出。

除此之外，在电梯线程类 ElevatorThread 的下车方法需要获取锁，用于操作电梯内部乘客的容器。（但是似乎可以不加锁）

private synchronized void dealOut() {
    if (!personIn.isEmpty()) {
        Iterator<PersonRequest> iterator = personIn.iterator();
        while (iterator.hasNext()) { // 有没有到的下
            PersonRequest request = iterator.next();
            if (Statics.floorToInt(request.getToFloor()) == currentFloor) {
                openDoor();
                getOut(request, iterator);
            }
        }
    }
}

以及电梯捎带请求的获取方法（在 ProcessingQueue 类中加锁），用于保护两个容器的删除操作。

public synchronized ArrayList<PersonRequest> getByTheWay(
            int currentFloor, boolean isUp, int curWeight) {
    Iterator<PersonRequest> iterator = floorIndex.get(currentFloor).iterator();
    ArrayList<PersonRequest> byTheWay = new ArrayList<>();
    int currentWeight = curWeight;
    while (iterator.hasNext()) {
        PersonRequest request = iterator.next();
        if (isByTheWay(request, isUp)) {
            if (currentWeight + request.getWeight() <= 400) {
                byTheWay.add(request);
                iterator.remove();
                currentWeight += request.getWeight();
            }
        }
    }
    if (!byTheWay.isEmpty()) {
        queue.removeAll(byTheWay);
    }
    return byTheWay;
}

其实，上述的锁操作完全可以替换为对类内部某一个容器单独的加锁，这里对整个对象加锁，粒度过粗，容易死锁。

调度器设计

交互

private final HashMap<Integer, ProcessingQueue> queueMap;
private final HashMap<Integer, ElevatorThread> elevatorThreads;

通过在创建调度器时，加入两个容器，用于访问每台电梯的等待队列，以及每台电梯本身。使用电梯类和队列类自身的get方法来获取线程信息。

...
queueMap.get(id).offer(personRequest); // 分配请求
...
for (HashMap.Entry<Integer, ElevatorThread> entry: elevatorThreads.entrySet()) { // 遍历电梯线程
    ElevatorThread elevatorThread = entry.getValue();
    ...
}

策略设计

// DispatchThread
private void dispatch(Request request) {
    if (request instanceof PersonRequest) {
        PersonRequest personRequest = (PersonRequest) request;
        for (int i = 0; i < 6; i++) {
            // 获取电梯状态
            if ( /* 主电梯 NORMAL 且能接 */) {
                ...
            } else if ( /* 主电梯 DOUBLE/WAIT */ ){
                if ( /* 主电梯能接 */ ){
                    ...
                } else if ( /* 备用电梯 DOUBLE/WAIT 且能接 */ ) {
                    ...
                }
            }
        }
        try {
            sleep(100);
        } catch (InterruptedException e) {
            //
        }
        requestQueue.offerBack(personRequest);
    } else if ( /* 特殊请求 */ ) {
        ...
    }

在调度策略上，没有采用什么较好的分配逻辑，使用了简单的 1 到 6 的循环分配。但是在判断电梯能否接人，加入了对等待队列大小的判断 state == Statics.ElevatorState.NORMAL && size < 10 。这个策略是在 U2 第一次研讨课上想出来的，也分享给了组员和其他同学，很好的避免了 hw6 中对五台电梯同时维修导致请求堆积而超时的 hack。

除此之外，我的设计中，电梯对于每一次处理的等待请求的选取，也设置了一定的策略。

// ProcessingQueue
private final HashMap<Integer, ArrayList<PersonRequest>> floorIndex;
public synchronized Request poll(int currentFloor) {
    ...
    if (!queue.isEmpty()) {
        PersonRequest request;
            if (!floorIndex.get(currentFloor).isEmpty()) {
                request = floorIndex.get(currentFloor).get(0);
                floorIndex.get(currentFloor).remove(request);
                queue.remove(request);
            } else {
                request = queue.get(0);
                floorIndex.get(Statics.floorToInt(request.getFromFloor())).remove(request);
                queue.remove(request);
           }
        return request;
    }
    ...
}

通过按楼层索引，优先获取当前停靠楼层的乘客，如果没有，去接第一个调度的乘客。

其实这里的 else 可以设计为接最近楼层的乘客，但是如果最近楼层的反倒会导致行动总长度变长呢，比如电梯停靠在 F2，共两个请求，一个请求是F1->B4，一个是F7->B4。显然先接F7的乘客，下来捎带F1的乘客是更优的，但是如果按楼层最近反倒性能更低。
因此这里选择按最先摁电梯的请求进行处理（~~符合实际~~）（~~其实是懒得写~~）

但是，实际上这些都可以通过在调度器中使用更好的调度策略来避免，比如通过影子电梯，计算出新请求对于每个电梯新增的最小代价，进行分配，让电梯按照自身等待队列顺序处理，可能效果会更优。

这里只是对我的循环分配进行的一个折中的优化。用较为简单的方式实现一个较为经济的性能。