一、需求分析
利用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