引起飢餓的cpu調度演算法

1. 多核CPU調度有哪幾種演算法 比如單核的有優先順序、先來先服務。那多核的有哪幾種呢

一般多核任務調度演算法有全局隊列調度和局部隊列調度。前者是指操作系統維護一個全局的任務等待隊列，當系統中有一個CPU核心空閑時，操作系統就從全局任務等待隊列中選取就緒任務開始在此核心上執行。這種方法的優點是CPU核心利用率較高。後者是指操作系統為每個CPU內核維護一個局部的任務等待隊列，當系統中有一個CPU內核空閑時，便從該核心的任務等待隊列中選取恰當的任務執行，這種方法的優點是任務基本上無需在多個CPU核心間切換，有利於提高CPU核心局部Cache命中率。目前多數多核CPU操作系統採用的是基於全局隊列的任務調度演算法。

2. SJF調度演算法

SJF調度演算法：最短作業優先演算法SJF（Shortest Job First )，SJF演算法以進入系統的作業所要求的CPU時間為標准，總選取估計計算時間最短的作業投入運行。

SJF 調度演算法優缺點：演算法易於實現。但效率不高，主要弱點是忽視了作業等待時間;會出現飢餓現象。SJF 調度演算法可證明為最佳的，這是因為對於給定的一組進程， SJF 演算法的平均等待時間最小。雖然 SJF 演算法最佳，但是它不能在短期CPU 調度層次上加以實現。因為沒有辦法知道下一個 CPU 區間的長度。

SJF演算法Gantt圖:

進程 區間時間

PI 6

P2 8

P3 7

P4 3

進程 P1 的等待時間是 3 ms，進程P2的等待時間為 16 ms，進程P3的等待時間為 9ms，進程P4的等待時間為 0ms。因此，平均等待時間為(3 + 16 + 9 +0) / 4 = 7 ms。

3. 檢測到CPU 飢餓.當前線程調度延遲X秒.求助

HMGR0152W信息報出說明這個進程中存在JVM線程調度延遲。

WebSphere Application Server高可用管理器組件中包含線程調度延遲檢測邏輯，它會周期性的啟動一個線程， 用這個線程去跟蹤是否線程已經被分派，是否按照計劃運行。默認情況下,延遲檢測線程每30秒鍾運行一次, 如果超過計劃5秒鍾沒有運行就會在日誌中記錄一條HMGR0152W消息。這條消息顯示了延遲的時間或者與該線程期望得到CPU和實際得到CPU的時間差。

HMGR0152W甚至可能在CPU資源可用的情況下報出。有很多原因可能導致這個調度線程不能以適時的方式獲得CPU.下面是一些常見的原因:

1. 物理內存被過量使用並且產生了分頁.

2. 進程的堆大小太小導致垃圾回收頻繁或者過長阻塞了其他線程的執行.

3. 系統中運行著太多線程,負載過高可能導致CPU使用過高.
HMGR0152W警告信息試圖告訴您出現了一個如果不及時修正可能導致不穩定的情況.您需要分析為什麼調度線程發生了延遲,需要採取哪些措施.下面是一些常用的解決方法:
1. 增加物理內存防止分頁.
2. 優化JVM堆內存配置,從而優化垃圾回收.
3. 降低系統的整體負載到一個可以接受的值.
如果HMGR0152W信息不是經常報出,並且從報出的消息看延遲很短(例如小於20秒), 通常不會有其他問題發生,這個時候這個消息可以被忽略.

高可用管理線程調度延遲檢測可以通過配置下面兩個定製屬性中的一個來實現:
1. IBM_CS_THREAD_SCHED_DETECT_PERIOD 參數決定延遲檢測線程多長時間運行一次.默認值是30秒.
2. IBM_CS_THREAD_SCHED_DETECT_ERROR 參數決定多長時間的延遲需要被用這個警告信息記錄在日誌中.

這些屬性轄域在核心組上,您可以按照如下方法配置:
1. 在管理控制台中, 點擊伺服器 > 核心組 > 核心組設置, 然後選擇核心組名字.
2. 在其它屬性下, 點擊定製屬性 > 新建.
3. 輸入屬性名和值.
4. 保存配置.
5. 如果是網路部署環境, 請注意同步所有節點.
6. 重新啟動所有的伺服器是該配置在該伺服器上生效.

雖然我們可以用上面兩個屬性增加線程調度檢測時間, 但是不建議通過它們使HMGR0152W警告消息完全不再報出. 這個方法只是用於優化系統消除線程調度延遲.

4. 不會發生飢餓現象的調度演算法

不會發生飢餓現象的調度演算法，這叫什麼話呀？我們中國人現在不都是衣食無憂了嗎？怎麼還會飢餓現象出現呢？你不是想到了什麼時候的年代的事？

5. SJF是什麼意思

是網路上的一個梗，指stg界最高毒奶。

SJF指射擊游戲（Shooting game），游戲類型的一種，也是動作游戲的一種。射擊游戲帶有很明顯的動作游戲特點，也沒有純然的射擊游戲，因為射擊必須要經過一種動作方式來呈現它的「射擊」。

「毒奶」指反向加油、拖累隊友。

詳解：

奶，在電競中作為名詞時候，指使用於游戲治療輔助職業；在電競中作為動詞時即指治療的動作。

毒奶，顧名思義，有毒的奶，即起到治療的反作用，害死隊友的行為。

6. cpu調度的基本方式

我們知道，程序需要獲得CPU的資源才能被調度和執行，那麼當一個進程由於某種原因放棄CPU然後進入阻塞狀態，下一個獲得CPU資源去被調度執行的進程會是誰呢？下圖中，進程1因為阻塞放棄CPU資源，此時，進程2剛IO操作結束，可以獲得CPU資源去被調度，進程3的時間片輪轉結束，也同樣可以獲得CPU資源去被調度，那麼，此時的操作系統應該安排哪個進程去獲得CPU資源呢？這就涉及到我們操作系統的CPU調度策略了。

根據生活中的例子，我們很容易想到以下兩種策略CPU調度的直觀想法：1.FIFO誰先進入，先調度誰，這是一種非常簡單有效的方法，就好比我們去飯堂打飯，誰先到就給誰先打飯。但是這種策略會遇到一個問題：如果遇到一個很小的任務，但是它是最後進入的，那麼必須得前面一大堆任務結束完後才能執行這個小小的任務，這樣就感覺很不劃算呀！因為我只是簡簡單單的一個小任務，但是從打開這個任務到結束這個任務要很久。這顯然不符合我們的需求，因而我們會想到第2種策略，就是先調度小任務，後調度大任務。2.Priority很簡單，就是任務短的優先執行，但是此時又有問題了，任務雖然短，但是它的執行時間不一定短，就好比在一個銀行業務中，客戶填寫一個表，這是一個非常短的任務吧——就單單填個表，但是這個表很長很長，那麼這個短任務它的執行時間就很長了，我們怎麼知道這個短的任務將來會執行多長的時間呢？所以，這樣的策略還是依然有問題。那麼，面對諸多的場景，如何設計調度演算法呢？首先，我們要明白我們的演算法應該讓什麼更好呢？面對客戶：銀行調度演算法的設計目標應該是用戶滿意；而面對進程：CPU調度的目標應該是進程滿意。那怎麼才能讓進程滿意呢？那就是時間了。進程希望盡早地結束任務，這就是周轉時間(從任務到達到任務結束)要短，而且希望用戶的操作能夠盡快地被響應，這就是響應時間(從操作發生到響應)要短。而且系統內耗時間要少，吞吐量(任務的完成量)要大，系統需要把更多的時間用在任務的執行上，而不能老是去做無關緊要的事情，例如：頻繁切換任務，切換棧，分配資源等事情。同時，系統還要去合理地調配任務。那麼，CPU的調度策略如何做到合理呢？首先得明白系統中有以下的幾種矛盾。1.吞吐量和響應時間之間有矛盾響應時間小=>切換次數多=>系統內耗大=>吞吐量小由於需要較短的響應時間，那麼就得頻繁地切換任務，這樣系統的很多時間都花在切換任務上面了，系統的內耗大了，吞吐量就小了。2.前台任務和後台任務的關注點不同前台任務關注響應時間，後台任務關注周轉時間。前台任務例如我們的word文檔，我們打一個字，需要立馬顯示在文檔中，這就是word文檔這個任務關注的是響應時間；而後台任務中，例如我們的javac編譯java代碼，它的周轉時間要小，即該任務從進入到結束所花的時間要小，即編譯完成的時間要小。http://3.IO約束型任務和CPU約束型任務各有各的特點IO約束型任務就是使用CPU的時間較少，進行IO操作的時間較長，CPU約束型的任務就是使用CPU的時間較長。因此，要做到合理，需要折中、綜合考慮以上的幾種矛盾。由此，產生了一些CPU的調度演算法，在下一節我們將重點講述這些CPU調度演算法。

關注小鯨融創，一起深度學習金融科技！

編輯於 2019-12-11 · 著作權歸作者所有
贊同 1
評論
展開全部

7. 飢餓導致餓死和死鎖有什麼區別

哥，飢餓是什麼？是進程無法得到資源，（cpu或者io資源或者別的什麼資源），所以無法進行下去，稱為餓死，比較常見的就是在優先順序調度中，不停的有高優先順序的進程創建，導致的無法分配cpu，從而飢餓。而按照《操作系統概念》當中介紹的，死鎖必須具備以下四個條件 ： 1， 自己佔有資源並且等待其他進程的資源，2 兩個進程相互等待對方佔有的資源 3 資源不能被搶占 4資源不能共享。 換句話說，死鎖是兩個或者多個進程，相互等待對方佔有的資源，而又不能釋放自己的資源，所以這些進程都進入死鎖狀態了，進入死鎖狀態後，由於沒有釋放自己佔有的資源，所以新的進程在請求這些資源的時候可能不能得到資源，於是就飢餓了。此時，cpu的佔用率和吞吐量會降低，因為所有的進程都處於waiting狀態，此時os會認為是因為多道程序處理時，並行度不夠，所以會調入更多的進程，導致更多的進程陷入死鎖，從而導致系統的性能大幅度下降，最終只能通過重啟來解決（現代的os一般沒有應用死鎖解決方案，因為這樣對性能的損失太大了）。不知道這樣說你能不能明白。

8. 哪種調度演算法會導致飢餓

一、處理機調度相關基本概念
1、調度方式和調度演算法的若干准則
1)面向用戶的准則：周轉時間短（CPU執行用時Ts、周轉時間T=Ts+Tw、帶權周轉時間W= T/Ts）、響應時間快、均衡性、截止時間的保證、優先權准則
2)面向系統的准則：系統吞吐量高、處理機利用率好、各類資源的平衡利用
3)批處理系統為照顧為數眾多的短作業，應採用短作業優先的調度演算法；分時系統為保證系統具有合理的響應時間，應採用輪轉法進行調度
二、常用調度演算法
1、先來先服務調度演算法FCFS
（1）按照作業提交，或進程變為就緒狀態的先後次序分派CPU；
（2）新作業只有當當前作業或進程執行完或阻塞才獲得CPU運行
（3）被喚醒的作業或進程不立即恢復執行，通常等到當前作業或進程出讓CPU。（所以，默認即是非搶占方式）
（4）有利於CPU繁忙型的作業，而不利於I/O繁忙的作業（進程）。

2、短作業（進程）優先調度演算法SJF（非搶占）/SPF（搶占）
（1）平均周轉時間、平均帶權周轉時間都有明顯改善。SJF/SPF調度演算法能有效的降低作業的平均等待時間，提高系統吞吐量。
（2）未考慮作業的緊迫程度，因而不能保證緊迫性作業（進程）的及時處理、對長作業的不利、作業（進程）的長短含主觀因素，不一定能真正做到短作業優先。

3、高優先權優先調度演算法HPF
（1）兩種方式：非搶占式優先權演算法、搶占式優先權演算法（關鍵點：新作業產生時）
（2）類型:靜態優先權：創建進程時確定，整個運行期間保持不變。動態優先權：創建進程時賦予的優先權可隨進程的推進或隨其等待時間的增加而改變。
（3）高響應比優先調度演算法HRRN
HRRN為每個作業引入動態優先權，使作業的優先順序隨著等待時間的增加而以速率a提高：優先權 =（等待時間+要求服務時間)/要求服務時間= 響應時間 / 要求服務時間。
什麼時候計算各進程的響應比優先權？（作業完成時、新作業產生時（搶占、非搶占）、時間片完成時、進程阻塞時）

9. 優先權調度是否會導致進程進入飢餓狀態為什麼

當一個進程正在運行時，系統可以基於某種原則，剝奪已分配給它的處理機，將之分配給其它進程。剝奪原則有：優先權原則、短進程優先原則、時間片原則。例如，有三個進程P1、P2、P3先後到達，它們分別需要20、4和2個單位時間運行完畢。假如它們就按P1、P2、P3的順序執行，且不可剝奪，則三進程各自的周轉時間分別為20、24、26個單位時間，平均周轉時間是23.33個時間單位。假如用時間片原則的剝奪調度方式，可得到：可見：P1、P2、P3的周轉時間分別為26、10、6個單位時間(假設時間片為2個單位時間)，平均周轉時間為14個單位時間。衡量進程調度性能的指標有：周轉時間、響應時間、CPU-I/O執行期。

10. 《操作系統》—進程調度演算法

搶占式調度演算法可能導致高優先順序的進程一直佔用CPU，而那些低優先順序的進程可能一直得不到CPU而餓死。