產生死鎖的緣由主要是:
(1) 由於系統資源不足。
(2) 進程運行推動的順序不合適。
(3) 資源分配不當等。
產生死鎖的四個必要條件:
(1)互斥條件:一個資源每次只能被一個進程使用。
(2)請求與保持條件:一個進程因請求資源而阻塞時,對已得到的資源保持不放。
(3)不可剝奪條件:進程已得到的資源,在末使用完以前,不能強行剝奪。
(4)循環等待條件:若干進程之間造成一種頭尾相接的循環等待資源關係。算法
避免死鎖:
死鎖的預防是經過破壞產生條件來阻止死鎖的產生,但這種方法破壞了系統的並行性和併發性。
死鎖產生的前三個條件是死鎖產生的必要條件,也就是說要產生死鎖必須具有的條件,而不是存在這3個條件就必定產生死鎖,那麼只要在邏輯上回避了第四個條件就能夠避免死鎖。
避免死鎖採用的是容許前三個條件存在,但經過合理的資源分配算法來確保永遠不會造成環形等待的封閉進程鏈,從而避免死鎖。該方法支持多個進程的並行執行,爲了不死鎖,系統動態的肯定是否分配一個資源給請求的進程。
預防死鎖:具體的作法是破壞產生死鎖的四個必要條件之一。數據庫
面向對象的3個基本要素:封裝、繼承、多態
面向對象的5個基本設計原則:
單一職責原則(Single-Resposibility Principle)
其核心思想爲:一個類,最好只作一件事,只有一個引發它的變化。單一職責原則能夠看作是低耦合、高內聚在面向對象原則上的引伸,將職責定義爲引發變化的緣由,以提升內聚性來減小引發變化的緣由。職責過多,可能引發它變化的緣由就越多,這將致使職責依賴,相互之間就產生影響,從而大大損傷其內聚性和耦合度。一般意義下的單一職責,就是指只有一種單一功能,不要爲類實現過多的功能點,以保證明體只有一個引發它變化的緣由。
專一,是一我的優良的品質;一樣的,單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別彆扭牽一髮而動全身,有失美感和必然致使醜陋的系統錯誤風險。
開放封閉原則(Open-Closed principle)
其核心思想是:軟件實體應該是可擴展的,而不可修改的。也就是,對擴展開放,對修改封閉的。開放封閉原則主要體如今兩個方面一、對擴展開放,意味着有新的需求或變化時,能夠對現有代碼進行擴展,以適應新的狀況。二、對修改封閉,意味着類一旦設計完成,就能夠獨立完成其工做,而不要對其進行任未嘗試的修改。
實現開開放封閉原則的核心思想就是對抽象編程,而不對具體編程,由於抽象相對穩定。讓類依賴於固定的抽象,因此修改就是封閉的;而經過面向對象的繼承和多態機制,又能夠實現對抽象類的繼承,經過覆寫其方法來改變固有行爲,實現新的拓展方法,因此就是開放的。
「需求老是變化」沒有不變的軟件,因此就須要用封閉開放原則來封閉變化知足需求,同時還能保持軟件內部的封裝體系穩定,不被需求的變化影響。
Liskov替換原則(Liskov-Substituion Principle)
其核心思想是:子類必須可以替換其基類。這一思想體現爲對繼承機制的約束規範,只有子類可以替換基類時,才能保證系統在運行期內識別子類,這是保證繼承複用的基礎。在父類和子類的具體行爲中,必須嚴格把握繼承層次中的關係和特徵,將基類替換爲子類,程序的行爲不會發生任何變化。同時,這一約束反過來則是不成立的,子類能夠替換基類,可是基類不必定能替換子類。
Liskov替換原則,主要着眼於對抽象和多態創建在繼承的基礎上,所以只有遵循了Liskov替換原則,才能保證繼承複用是可靠地。實現的方法是面向接口編程:將公共部分抽象爲基類接口或抽象類,經過Extract Abstract Class,在子類中經過覆寫父類的方法實現新的方式支持一樣的職責。
Liskov替換原則是關於繼承機制的設計原則,違反了Liskov替換原則就必然致使違反開放封閉原則。
Liskov替換原則可以保證系統具備良好的拓展性,同時實現基於多態的抽象機制,可以減小代碼冗餘,避免運行期的類型判別。
依賴倒置原則(Dependecy-Inversion Principle)
其核心思想是:依賴於抽象。具體而言就是高層模塊不依賴於底層模塊,兩者都同依賴於抽象;抽象不依賴於具體,具體依賴於抽象。
咱們知道,依賴必定會存在於類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關係時,最好的方法就是分離接口和實現:在依賴之間定義一個抽象的接口使得高層模塊調用接口,而底層模塊實現接口的定義,以此來有效控制耦合關係,達到依賴於抽象的設計目標。
抽象的穩定性決定了系統的穩定性,由於抽象是不變的,依賴於抽象是面向對象設計的精髓,也是依賴倒置原則的核心。
依賴於抽象是一個通用的原則,而某些時候依賴於細節則是在所不免的,必須權衡在抽象和具體之間的取捨,方法不是一層不變的。依賴於抽象,就是對接口編程,不要對實現編程。
接口隔離原則(Interface-Segregation Principle)
其核心思想是:使用多個小的專門的接口,而不要使用一個大的總接口。
具體而言,接口隔離原則體如今:接口應該是內聚的,應該避免「胖」接口。一個類對另一個類的依賴應該創建在最小的接口上,不要強迫依賴不用的方法,這是一種接口污染。
接口有效地將細節和抽象隔離,體現了對抽象編程的一切好處,接口隔離強調接口的單一性。而胖接口存在明顯的弊端,會致使實現的類型必須徹底實現接口的全部方法、屬性等;而某些時候,實現類型並不是須要全部的接口定義,在設計上這是「浪費」,並且在實施上這會帶來潛在的問題,對胖接口的修改將致使一連串的客戶端程序須要修改,有時候這是一種災難。在這種狀況下,將胖接口分解爲多個特色的定製化方法,使得客戶端僅僅依賴於它們的實際調用的方法,從而解除了客戶端不會依賴於它們不用的方法。
分離的手段主要有如下兩種:一、委託分離,經過增長一個新的類型來委託客戶的請求,隔離客戶和接口的直接依賴,可是會增長系統的開銷。二、多重繼承分離,經過接口多繼承來實現客戶的需求,這種方式是較好的。 編程
(1)塊式管理。把主存分爲一大塊、一大塊的,當所需的程序片斷不在主存時就分配一塊主存空間,把程序片斷加載到主存,就算所須要的程序片斷只有幾個字節也只能把這塊分配給它。優勢:易於管理;缺點:浪費空間。windows
(2)頁式管理。把主存分爲一頁一頁的,每一頁的空間要比一塊一塊的空間小不少,顯然這種方式的空間利用率要比塊式管理高出不少。併發
(3)段式管理。把主存分爲一段一段的,每一段的空間又要比一頁一頁的空間小不少,這種方法在空間利用率上比頁式管理高出不少,但也有另一個缺點,一個程序片斷可能會被分爲幾十個段,這樣不少時間就會浪費在計算每一段的物理地址上。(I/O操做)ui
(4)段頁式管理。結合了段式管理和頁式管理的優勢。把主存分爲若干頁,每一頁又分爲若干段。線程