OO第二次博客做業——多線程電梯

1、基於度量的做業分析

　　h1能夠說是一個很是傻瓜的多線程電梯，原理很是簡單直接粗暴

　　實際運用可能會被客戶投訴（是必定）

 

　　在第二次做業中，我採用了一種很是複雜的寫法

 

　　能夠看到複雜度最高的地方集中在電梯的運行函數和調度函數中，但其實這種複雜性對於電梯的運行並無任何的幫助，只是因爲對於多線程知識的只知其一;不知其二和架構設計不清晰而造成的這種結構

 

　　相較於第二次做業來講，電梯的設計有了必定的改進，將一些沒必要要單列的線程和功能進行了抽象化和集中

　　可是電梯的複雜度仍是比較高的，儘管指導書要求咱們寫的應該是一個有着實際運用價值的電梯，可是個人電梯的目的只是爲了過中測性能和調度算法仍是比較差的

 

　　2、設計策略

 

在前兩次的電梯做業中，我對於多線程的瞭解都只是錯誤或者不全面的

重點敘述一下第三次電梯做業的設計策略

首先，電梯問題是一個很經典的「生產者——消費者模型」

生產者——需求

在這裏需求分爲兩類

1.能直達

2.不能直達（從起點到換乘樓層，從換乘樓層到達目的樓層），至關於兩個需求，可是這兩個需求是有時間的前後順序的

消費者——電梯

因爲三部電梯擁有不一樣的到達樓層，乘客可能有換乘的狀況發生，因此在需求產生的時候，我就將這個乘客是否須要換乘，在那層樓換乘進行了一個判斷

對於每一個電梯，都有一個運行序列，主需求序列經過調度器將各個乘客分配到三部電梯的運行序列中

調度器的運行是在電梯上下樓之間的時間完成的，也就是說，沒上升或者降低一層樓，都會對電梯進行一次調度，同時根據電梯的運行狀態（上行或者下行，是否滿載），來進行乘客的進出

 

 

3、發現的bug以及處理

1. 電梯不能讀入請求

　　這裏的問題主要是線程安全致使的，對於讓電梯和調度器wait和喚醒時的設置有問題

        2.超載

　　最開始沒有設計電梯容量，在電梯的運行函數中修改

　　3.電梯瘋狂向一個方向跑

　　對於判斷電梯運行狀態的方法設計有問題，修改

　　4.需求不能執行完，執行幾條以後就不執行了

　　這裏是線程安全的問題，出現了部分死鎖的狀況

 

　　4、分析本身程序的bug和分析本身發現別人程序bug所採用的策略

　　bug仍是挺多的，設計自己有問題。

　　主要出如今調度算法的漏洞，電梯僅依靠判斷本電梯運行序列中乘客的狀況判斷是否上下人，而後有時候調度器錯誤的調度就致使電梯不能正確執行指令

　　關於debug的方法：

　　先設計好數據，而後黑盒測試，對於有問題的數據進行代碼的調試和bug的定位

　　（這裏感謝ffdl的定時投放數據腳本）

 

　　5、心得體會

首先，多線程是真的挺難的。

對於如何讓本身的代碼兼具高效和正確性對我來講仍是一個比較大的挑戰。

在學習多線程的過程當中，我認爲仍是多和同窗進行交流，這樣就能夠及時的將一些錯誤的理解避免，免除沒必要要的代碼工做

更重要的一點是，必定要在認真閱讀過指導書後在進行設計，而後再進行代碼

否則就有可能整個程序架構崩盤（你問我怎麼知道的？呵呵）