BUAA-OO 第二单元做业“电梯调度”总结与思考

1、需求分析

利用java线程的相关知识实现

1）单部多线程傻瓜调度（FAFS）电梯

2）单部多线程可捎带调度（ALS）电梯

3）多部多线程智能（SS）调度电梯

2、思路分析

一、基于度量的程序结构分析

流程时序图（利用SequenceDiagram插件）

注：使用UML Support插件时，采用实现runnable接口的方法生成的类关系图更优美一点

Input类（三次做业复用）：

Elevator类：

第一次

 

第二次

图太大了戳这里

第三次

图太大了戳这里

代码行数统计（利用Statistic插件）

第一次

第二次

第三次

代码设计复杂度（利用MetricsReloaded插件）

ev(G)基本复杂度，用来衡量程序非结构化程度
iv(G)模块设计复杂度，用来衡量模块断定结构
v(G)独立路径条数

第一次

第二次

第三次

 

二、BUG分析

第一次：

强测中得分 100

互测：未被hack。未hack别人。

第二次：

在强测中得分 82.558（全部数据性能分几乎为0）

未被hack。未hack到别人。

第三次：

在强测中得分  76.9294（WA两个数据点，其他数据性能分几乎为0）

被hack1次，hack他人1次。

本身错误：出现了电梯容量已满却仍进人的状况。

他人错误：电梯换向时到了21层。

 

3、知识技能总结

一、代码编写层面的优化

1）第三次做业中一种快速处理换乘楼层的写法

记A电梯为001，B电梯为010，C电梯为100.

则可乘坐的电梯的类型能够用三位二进制数来表示，例如：

在1层的人能够乘坐A、B电梯，则创建楼层1到二进制数011的映射(map)。

在3层的人只能乘坐C电梯，则简历楼层3到二进制数100的映射。

这样避免了用八个等待队列储存全部状况的繁杂写法。

 

2）电梯不一样状态间的切换：run方法中，用状态机来实现，简单直观

 1     public void run() {  2         while (true) {  3             synchronized (this) {  4                 try {  5                     if (state == 0) {  6                         break;  7  }  8                     if (state == 1) { //main request
 9                         while (true) { 10                             if (Singleton.getInstance().isend()) { 11  close(); 12                                 state = 0; 13                                 break; 14  } 15                             mainRequest = Singleton.getInstance().getMainRequest(); 16                             if (mainRequest == null) { 17                                 synchronized (Singleton.getInstance()) { 18  Singleton.getInstance().wait(); 19  } 20                             } else { 21  solveMain(); 22                                 break; 23  } 24  } 25  } 26                     else if (state == 2) { solveUp(); } 27                     else if (state == 3) { solveDown(); } 28                 } catch (InterruptedException e) { 29                     //DO STH
30  } 31  } 32  } 33     }

 

二、多线程设计模式的实际运用

1）单例模式

2）生产者—消费者模式

3）线程池（Worker Thread模式）

4）观察者模式

三、输出日志信息 Log4j

配置log4j2-test.xml文件：

 1 <?xml version="1.0" encoding="UTF-8"?>
 2 <configuration status="OFF">
 3     <appenders> <!—输出模块-->
 4         <Console name="Console" target="SYSTEM_OUT">
 5             <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
 6         </Console>
 7     </appenders>
 8     <loggers><!—日志模块-->
 9 <logger name=“elevator.WorkerThread" level="trace" additivity="false">
10             <appender-ref ref="Console"/>
11         </logger>
12         <root level="error">
13             <appender-ref ref="Console"/>
14         </root>
15     </loggers>
16 </configuration>

 

四、JProfiler的使用

五、定点投放的实现

思路：正则表达式分离时间戳+sleep

python程序已上传至GitHub

六、线程安全容器总结

这一单元做业中我采用了CopyOnWriteArrayList做为线程安全数组

COW(Copy On Write)机制的介绍：https://yq.aliyun.com/articles/665359

 

4、本身的一点思考

一、程序测试方法

随机数据测试（测试cpu-time和基本的功能）+构造数据测试（测试电梯是否知足全部限制条件）

对拍器SPJ测试的功能，同时也是构造数据时重点检验的功能：

是否知足到达——开门——出入人——关门的顺序。

是否知足楼层限制

是否知足容量要求

除此以外，三次做业重难点在于：

1）HW5:是否可正常退出线程：接收器再也不接收请求，电梯继续处理完已经读入的请求

2）HW6:是否可将全部请求捎带（若是有请求的区间与当前等待队列区间不重合，是否将其放入等待队列？）、同一楼层是否会开关两次门

3）HW7:2->三、4->3的换乘须要特殊处理。换乘指令拆解后是否按顺序执行（在人下电梯后才能从同楼层上另外一电梯）。

二、优化方法

4、疑问与建议

一、对拍器的意义？

助教说，A组强测和互测成绩远好于B组和C组的一大缘由是“大佬们基本人手一个评测机”。

我认可互测的确是测试的有效手段，这致使我这一单元的最大收获就是学会写得一手好脚本。

但当我发现本身用在写评测机的时间远远大于学习多线程思想的时间的时候，我感受本身在面向“评测机”编程。

不知道老师和助教为什么大力鼓励同窗们来写评测机。知识无穷，学什么只要用心了都会有收获，也都会有相应的欢喜和知足。但这种偏离正轨的导向仍是会让人感受食之无味，弃之惋惜。

二、架构or性能？

自我感受第二单元做业的难度要低于第一单元。程序的大致架构老师在课上已经基本讲过，剩下的添添补补，这三次做业居然没有重构。

若是说性能优化基于架构的话，那性能优化的方向是什么呢？

当我问及性能的问题时，助教和老师都在强调正确性为主，但做为两次被性能分踩死的选手，仍是想要了解一下助教出题时构想的优化的可能思路。T_T

三、b站都开源了，大佬们的代码能够开源吗

 若是助教以为上面的话都没道理的话......我只是想请求看一看大佬们的优秀代码，学习一下。/小纠结

PS. 实验课的题面在结束以后能够开放吗？这样还能复习巩固一下下。