文章详细描述了一个基于多线程的电梯调度系统，包括输入线程处理请求、Elevator类的运行逻辑、RequestTable的共享资源管理和策略类的调度决策。作者通过迭代学习了线程安全、同步控制和生产者-消费者模型的应用，强调了框架和设计对代码迭代的重要性。
1.最终架构
1.1基本框架
在Main中设置三个线程为输入线程、电梯运行服务线程、调度器线程，用来实现电梯任务的完成。
1.1.1InputThread类
public void run() {
ElevatorInput elevatorInput = new ElevatorInput(System.in);
while (true) {
Request request = elevatorInput.nextRequest();
// when request == null
// it means there are no more lines in stdin
if (request == null) {
waitPersonRequest.setEnd();
break;
} else {
// a new valid request9
if (request instanceof PersonRequest) {
waitPersonRequest.addRequest((PersonRequest) request);
//requestTables.get(request.getElevatorId() - 1).addRequest(request);
} else if (request instanceof NormalResetRequest) {
requestTables.get(((NormalResetRequest) request).getElevatorId() - 1)
.addResetRequest((NormalResetRequest)request);
} else if (request instanceof DoubleCarResetRequest) {
requestTables.get(((DoubleCarResetRequest) request).getElevatorId() - 1)
.beDoubleCar((DoubleCarResetRequest)request);
Main.MakeElevator((DoubleCarResetRequest)request, waitPersonRequest);
}
}
}
try {
elevatorInput.close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}用于判断输入请求的类型，分配给电梯线程或者分配给调度器。
当输入结束后，标志输入线程结束，同时给予调度器线程一个信号。
1.1.2 Elevator类
1.2串联类
RequestTable类是三大线程的共享资源。其中的requestMap以楼层为key,其他线程分配来这一个电梯（线程）key楼层的requests为value。isEnd和isRun用于调整线程的运行、暂停。
private int requestNum;
private boolean isEnd;
private boolean isRun;
private HashMap<Integer, ArrayList<PersonRequest>> requestMap;
//...1.3策略类
Strategy类处理DcElevator和Elevator的run()的分支处理。
public Execute getExecute(int nowFloor, int nowNum, int direction
, RequestTable requestTable, ArrayList<PersonRequest> nowRequests, int maxNum) {
//判断现在是否可以上下电梯
if (requestTable.isNeedReset() == true) {
return Execute.RESET;
}
if (canOpenDoorIn(nowFloor, nowNum, direction, requestTable, maxNum)
|| canOpenDoorOut(nowFloor, nowRequests)) {
return Execute.OPEN;
}
if (nowNum != 0) {
return Execute.MOVE;
} else {
if (requestTable.isEmpty()) {
if (requestTable.isEnd()) {
return Execute.OVER;
} else {
return Execute.WAIT;
}
} else {
if (hasReqInOriginDirection(nowFloor, direction, requestTable)) {
return Execute.MOVE;
} else {
return Execute.REVERSE;
}
}
}
}以上是这个单元的地基，迭代均基于此。
2.作业迭代
2.1第五次作业
请求已经确定选择的电梯，从而无需调度，直接分配，故这次作业并没有设计Schedule类。
2.1.1同步块与锁
public synchronized void addRequest(PersonRequest personRequest) {
requestMap.get(personRequest.getFromFloor()).add(personRequest);
requests.add(personRequest);
requestNum++;
notifyAll();
}
public synchronized void delRequest(int key, int arrayNum) {
requests.remove(requestMap.get(key).get(arrayNum));
requestMap.get(key).remove(arrayNum);
requestNum--;
notifyAll();
}
public synchronized HashMap<Integer, ArrayList<PersonRequest>> getRequestMap() {
return requestMap;
}
public synchronized boolean isEmpty() {
notifyAll();//
return requestNum == 0;
}
public synchronized boolean isEnd() {
notifyAll();//
return isEnd;
}
//...我对共享资源类的函数使用synchronized同步块封装，保证了函数的原子性，不会在读写时与其他线程互斥。上锁之后，同步块中的共享资源（requestTable）只能一个线程使用，从而确保了资源的正确使用。
2.1.2bug分析
报错信息：
Exception in thread "Thread-0" java.util.ConcurrentModificationException at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) at java.util.ArrayList$Itr.next(ArrayList.java:859) at Elevator.openAndClose(Elevator.java:60) at Elevator.run(Elevator.java:40)
根据信息，直接就知道自己在使用容器的循环中，更改了容器的内容，这是由于输入线程干扰，
只需加在循环外加一个syncronized同步控制，则可以防止此bug。
更改后如下：
synchronized (requestTable) {
for (PersonRequest pr : requestTable.getRequestMap().get(nowFloor)) {
if ((pr.getToFloor() - pr.getFromFloor()) * nowDirection > 0) {
if (nowNum < this.maxNum) {
nowRequests.add(pr);
x.add(i);
this.nowNum += 1;
TimableOutput.println("IN-" + pr.getPersonId() + "-"
+ this.nowFloor + "-" + this.id);
}
}
i++;
}
for (int j = x.size() - 1; j >= 0; j--) {
requestTable.delRequest(nowFloor, (int)x.get(j));
}
}2.2第六次作业
这次作业中共增加了两个改动，乘客不再提前选择电梯，而是等待程序自己实现请求的管理，
而且电梯的性质也可以根据命令改变，显然这个命令不需要经过Schedule类分配。
2.2.1同步块与锁
这次作业需要实现调度器，从而将共享资源的使用上锁，防止调度器与输入线程或者电梯互斥。
上锁之后，同步块中的共享资源（requestTable）只能一个线程使用，从而确保了资源的正确使用。
2.2.2调度策略
if ((min > (requestTables.get(i).size() + elevators.get(i).getNowNum()))
&& requestTables.get(i).isNeedReset() == false) {
min = requestTables.get(i).size() + elevators.get(i).getNowNum();
}我的调度策略是把请求分配给任务少的电梯。
2.2.3bug分析
2.2.3.1cpu轮询
这个bug在多线程中非常常见，他会占用cpu，在run()中不停的while，这会导致CTLE，
只需在while块内部的第一个语句设置
System.out.println("1");如果发现程序在实现功能的同时出现几千上万行1，则确定此线程没有wait()或sleep,而是不停的占用cpu，浪费资源，这种方法简单粗暴地测试出轮询相关的bug。
2.2.3.2reset相关的bug
强测暴毙的主要原因，在我的策略类中，需要根据电梯限载人数和已载人数的比较判断是否OPEN
if (nowNum < maxNum) {
return true;
}在第五次作业中我的代码是nowNum < 6,忘记更改6为maxNum，导致电梯限载人数小于6时，会不停的返回OPEN
在对reset的每个性能变化测试后，充分测试reset的限载时发现程序卡在OPEN，TLE！！！
2.2.3.3死锁？
在本地正常结束而在强测中报RTLE的情况，但根据我的分析，这并非死锁，死锁是两个线程抢占资源,但均wait()，导致无法唤醒而造成。我的bug是在schedule中的结束控制，我的结束逻辑中，可能会在电梯结束后，schedule却在wait(),这是由于代码的顺序执行产生，以及多线程的异步性导致，因为无法确定多线程代码的执行顺序。
所以可能会在Schedule判断需要wait时，但还没wait()时，判断的值已经不正确了（由于其他线程的代码执行），我的bug是电梯还没结束，schedule得到信号需要wait（）了，但是电梯结束了，信号的不及时性和错误，此时schedule却wait()了，从而无法被电梯中的代码唤醒。
从而我在wait时设置了一个wait时间的上限值，防止无限等下去。
总结：死锁的bug很难找到，但是同时死锁也很难产生，所以我们要在使用wait-notify时多加思考，也不能按单线程的顺序执行而忘记多线程的异步性。
2.3第七次作业
2.3.1调度策略
我很后悔没有使用random来分配，而是使用把请求分配给任务的电梯，性能明显不如随机分配。
2.3.2双轿厢的实现
主要参考了讨论区的精华，模仿构造了Flag类，用来判断换乘层的占用情况。大佬的代码十分优雅，无需多言上代码：
public void move() {
this.nowFloor = this.nowFloor + nowDirection;
if (nowFloor == transferFloor) {
occupied.setOccupied();
}
if (type == 'a') {
TimableOutput.println("ARRIVE-" + this.nowFloor + "-" + this.id + "-" + 'A');
} else {
TimableOutput.println("ARRIVE-" + this.nowFloor + "-" + this.id + "-" + 'B');
}
if (nowFloor - nowDirection == transferFloor) {
occupied.releaseOccupied();
}
}本质是占用更改楼层，占用资源（setOccupied()在无资源时等待），释放资源，唤醒其他等待的。
2.3.3bug分析
无bug。
3.心得体会
本单元是我第一次接触多线程设计，对于线程安全的感受也是非常深，很好地理解了如何避免cpu被浪费（改掉轮询），也深刻感受到了多线程的异步性对结果的影响，所以我在三次作业中深刻地领会了同步块和锁的使用。在新增Schedule类后，我对多线程对共享资源的使用的理解更加深刻了，正确地保持了写requestTable的时候其他线程无法访问。
这次设计本质是生产者-消费者，三类线程的实现维持了系统。让我深刻地认识到框架和设计确定了程序的根基，在多次迭代中都是基于这个根基，利于迭代。调度的独立性也利于调度的优化，层次化设计让我们感受到工程之美，希望未来的单元可以收获更多。
1077
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
