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

一、需求分析

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

1)单部多线程傻瓜调度(FAFS)电梯

2)单部多线程可捎带调度(ALS)电梯

3)多部多线程智能(SS)调度电梯

二、思路分析

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

流程时序图(利用SequenceDiagram插件)

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

Input类(三次作业复用):

Elevator类:

第一次

 

第二次

图太大了戳这里

第三次

图太大了戳这里

代码行数统计(利用Statistic插件)

第一次

第二次

第三次

代码设计复杂度(利用MetricsReloaded插件)

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

第一次

第二次

第三次

2、BUG分析

第一次:

强测中得分 100

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

第二次:

在强测中得分 82.558(所有数据性能分几乎为0)

未被hack。未hack到别人。

第三次:

在强测中得分  76.9294(WA两个数据点,其余数据性能分几乎为0)

被hack1次,hack他人1次。

自己错误:出现了电梯容量已满却仍进人的情况。

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

三、知识技能总结

1、代码编写层面的优化

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     }

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

1)单例模式

2)生产者—消费者模式

3)线程池(Worker Thread模式)

4)观察者模式

3、输出日志信息 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>

4、JProfiler的使用

5、定点投放的实现

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

python程序已上传至GitHub

6、线程安全容器总结

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

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

四、自己的一点思考

1、程序测试方法

随机数据测试(测试cpu-time和基本的功能)+构造数据测试(测试电梯是否满足所有限制条件)

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

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

是否满足楼层限制

是否满足容量要求

除此之外,三次作业重难点在于:

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

2)HW6:是否可将所有请求捎带(如果有请求的区间与当前等待队列区间不重合,是否将其放入等待队列?)、同一楼层是否会开关两次门

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

2、优化方法

四、疑问与建议

1、对拍器的意义?

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

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

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

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

2、架构or性能?

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

如果说性能优化基于架构的话,那性能优化的方向是什么呢?

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

3、b站都开源了,大佬们的代码可以开源吗

 如果助教觉得上面的话都没道理的话......我只是想请求看一看大佬们的优秀代码,学习一下。/小纠结

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

原文地址:https://www.cnblogs.com/Ryan0v0/p/10752795.html