搞定操做系統面試，看這篇就夠了（一）
1、概述
基本特徵
1. 併發
併發是指宏觀上在一段時間內能同時運行多個程序，而並行則指同一時刻能運行多個指令。算法
並行須要硬件支持，如多流水線、多核處理器或者分佈式計算系統。瀏覽器
操做系統經過引入進程和線程，使得程序可以併發運行。安全
2. 共享
共享是指系統中的資源能夠被多個併發進程共同使用。bash
有兩種共享方式：互斥共享和同時共享。服務器
互斥共享的資源稱爲臨界資源，例如打印機等，在同一時間只容許一個進程訪問，須要用同步機制來實現對臨界資源的訪問。多線程
3. 虛擬
虛擬技術把一個物理實體轉換爲多個邏輯實體。架構
主要有兩種虛擬技術：時分複用技術和空分複用技術。併發
多個進程能在同一個處理器上併發執行使用了時分複用技術，讓每一個進程輪流佔有處理器，每次只執行一小個時間片並快速切換。異步
虛擬內存使用了空分複用技術，它將物理內存抽象爲地址空間，每一個進程都有各自的地址空間。地址空間的頁被映射到物理內存，地址空間的頁並不須要所有在物理內存中，當使用到一個沒有在物理內存的頁時，執行頁面置換算法，將該頁置換到內存中。分佈式
4. 異步
異步指進程不是一次性執行完畢，而是走走停停，以不可知的速度向前推動。
（文章純乾貨 請仔細閱讀 整理不易！）
基本功能
1. 進程管理
進程控制、進程同步、進程通訊、死鎖處理、處理機調度等。
2. 內存管理
內存分配、地址映射、內存保護與共享、虛擬內存等。
3. 文件管理
文件存儲空間的管理、目錄管理、文件讀寫管理和保護等。
4. 設備管理
完成用戶的 I/O 請求，方便用戶使用各類設備，並提升設備的利用率。
主要包括緩衝管理、設備分配、設備處理、虛擬設備等。
系統調用
若是一個進程在用戶態須要使用內核態的功能，就進行系統調用從而陷入內核，由操做系統代爲完成。
Linux 的系統調用主要有如下這些：
| Task | Commands |
|---|---|
| 進程控制 | fork(); exit(); wait(); |
| 進程通訊 | pipe(); shmget(); mmap(); |
| 文件操做 | open(); read(); write(); |
| 設備操做 | ioctl(); read(); write(); |
| 信息維護 | getpid(); alarm(); sleep(); |
| 安全 | chmod(); umask(); chown(); |
大內核和微內核
1. 大內核
大內核是將操做系統功能做爲一個緊密結合的總體放到內核。
因爲各模塊共享信息，所以有很高的性能。
2. 微內核
因爲操做系統不斷複雜，所以將一部分操做系統功能移出內核，從而下降內核的複雜性。移出的部分根據分層的原則劃分紅若干服務，相互獨立。
在微內核結構下，操做系統被劃分紅小的、定義良好的模塊，只有微內核這一個模塊運行在內核態，其他模塊運行在用戶態。
由於須要頻繁地在用戶態和核心態之間進行切換，因此會有必定的性能損失。
中斷分類
1. 外中斷
由 CPU 執行指令之外的事件引發，如 I/O 完成中斷，表示設備輸入/輸出處理已經完成，處理器可以發送下一個輸入/輸出請求。此外還有時鐘中斷、控制檯中斷等。
2. 異常
由 CPU 執行指令的內部事件引發，如非法操做碼、地址越界、算術溢出等。
3. 陷入
在用戶程序中使用系統調用。
2、進程管理
進程與線程
1. 進程
進程是資源分配的基本單位。
進程控制塊 (Process Control Block, PCB) 描述進程的基本信息和運行狀態，所謂的建立進程和撤銷進程，都是指對 PCB 的操做。
下圖顯示了 4 個程序建立了 4 個進程，這 4 個進程能夠併發地執行。
2. 線程
線程是獨立調度的基本單位。
一個進程中能夠有多個線程，它們共享進程資源。
QQ 和瀏覽器是兩個進程，瀏覽器進程裏面有不少線程，例如 HTTP 請求線程、事件響應線程、渲染線程等等，線程的併發執行使得在瀏覽器中點擊一個新連接從而發起 HTTP 請求時，瀏覽器還能夠響應用戶的其它事件。
3. 區別
Ⅰ 擁有資源
進程是資源分配的基本單位，可是線程不擁有資源，線程能夠訪問隸屬進程的資源。
Ⅱ 調度
線程是獨立調度的基本單位，在同一進程中，線程的切換不會引發進程切換，從一個進程中的線程切換到另外一個進程中的線程時，會引發進程切換。
Ⅲ 系統開銷
因爲建立或撤銷進程時，系統都要爲之分配或回收資源，如內存空間、I/O 設備等，所付出的開銷遠大於建立或撤銷線程時的開銷。相似地，在進行進程切換時，涉及當前執行進程 CPU 環境的保存及新調度進程 CPU 環境的設置，而線程切換時只需保存和設置少許寄存器內容，開銷很小。
Ⅳ 通訊方面
線程間能夠經過直接讀寫同一進程中的數據進行通訊，可是進程通訊須要藉助 IPC。
進程狀態的切換
就緒狀態（ready）：等待被調度
運行狀態（running）
阻塞狀態（waiting）：等待資源
應該注意如下內容：
只有就緒態和運行態能夠相互轉換，其它的都是單向轉換。就緒狀態的進程經過調度算法從而得到 CPU 時間，轉爲運行狀態；而運行狀態的進程，在分配給它的 CPU 時間片用完以後就會轉爲就緒狀態，等待下一次調度。
阻塞狀態是缺乏須要的資源從而由運行狀態轉換而來，可是該資源不包括 CPU 時間，缺乏 CPU 時間會從運行態轉換爲就緒態。
進程調度算法
不一樣環境的調度算法目標不一樣，所以須要針對不一樣環境來討論調度算法。
1. 批處理系統
批處理系統沒有太多的用戶操做，在該系統中，調度算法目標是保證吞吐量和週轉時間（從提交到終止的時間）。
1.1 先來先服務 first-come first-serverd（FCFS）
按照請求的順序進行調度。
有利於長做業，但不利於短做業，由於短做業必須一直等待前面的長做業執行完畢才能執行，而長做業又須要執行很長時間，形成了短做業等待時間過長。
1.2 短做業優先 shortest job first（SJF）
按估計運行時間最短的順序進行調度。
長做業有可能會餓死，處於一直等待短做業執行完畢的狀態。由於若是一直有短做業到來，那麼長做業永遠得不到調度。
1.3 最短剩餘時間優先 shortest remaining time next（SRTN）
按估計剩餘時間最短的順序進行調度。
2. 交互式系統
交互式系統有大量的用戶交互操做，在該系統中調度算法的目標是快速地進行響應。
2.1 時間片輪轉
將全部就緒進程按 FCFS 的原則排成一個隊列，每次調度時，把 CPU 時間分配給隊首進程，該進程能夠執行一個時間片。當時間片用完時，由計時器發出時鐘中斷，調度程序便中止該進程的執行，並將它送往就緒隊列的末尾，同時繼續把 CPU 時間分配給隊首的進程。
時間片輪轉算法的效率和時間片的大小有很大關係：
由於進程切換都要保存進程的信息而且載入新進程的信息，若是時間片過小，會致使進程切換得太頻繁，在進程切換上就會花過多時間。
而若是時間片過長，那麼實時性就不能獲得保證。
2.2 優先級調度
爲每一個進程分配一個優先級，按優先級進行調度。
爲了防止低優先級的進程永遠等不到調度，能夠隨着時間的推移增長等待進程的優先級。
2.3 多級反饋隊列
一個進程須要執行 100 個時間片，若是採用時間片輪轉調度算法，那麼須要交換 100 次。
多級隊列是爲這種須要連續執行多個時間片的進程考慮，它設置了多個隊列，每一個隊列時間片大小都不一樣，例如 1,2,4,8,..。進程在第一個隊列沒執行完，就會被移到下一個隊列。這種方式下，以前的進程只須要交換 7 次。
每一個隊列優先權也不一樣，最上面的優先權最高。所以只有上一個隊列沒有進程在排隊，才能調度當前隊列上的進程。
能夠將這種調度算法當作是時間片輪轉調度算法和優先級調度算法的結合。
3. 實時系統
實時系統要求一個請求在一個肯定時間內獲得響應。
分爲硬實時和軟實時，前者必須知足絕對的截止時間，後者能夠容忍必定的超時。
進程同步
1. 臨界區
對臨界資源進行訪問的那段代碼稱爲臨界區。
爲了互斥訪問臨界資源，每一個進程在進入臨界區以前，須要先進行檢查。
// entry section
// critical section;
// exit section
複製代碼
2. 同步與互斥
同步：多個進程按必定順序執行；
互斥：多個進程在同一時刻只有一個進程能進入臨界區。
3. 信號量
信號量（Semaphore）是一個整型變量，能夠對其執行 down 和 up 操做，也就是常見的 P 和 V 操做。
down : 若是信號量大於 0 ，執行 -1 操做；若是信號量等於 0，進程睡眠，等待信號量大於 0；
up ：對信號量執行 +1 操做，喚醒睡眠的進程讓其完成 down 操做。
down 和 up 操做須要被設計成原語，不可分割，一般的作法是在執行這些操做的時候屏蔽中斷。
若是信號量的取值只能爲 0 或者 1，那麼就成爲了 互斥量（Mutex） ，0 表示臨界區已經加鎖，1 表示臨界區解鎖。
typedef int semaphore;
semaphore mutex = 1;
void P1() {
down(&mutex);
// 臨界區
up(&mutex);
}
void P2() {
down(&mutex);
// 臨界區
up(&mutex);
}
複製代碼
使用信號量實現生產者-消費者問題
問題描述：使用一個緩衝區來保存物品，只有緩衝區沒有滿，生產者才能夠放入物品；只有緩衝區不爲空，消費者才能夠拿走物品。
由於緩衝區屬於臨界資源，所以須要使用一個互斥量 mutex 來控制對緩衝區的互斥訪問。
爲了同步生產者和消費者的行爲，須要記錄緩衝區中物品的數量。數量可使用信號量來進行統計，這裏須要使用兩個信號量：empty 記錄空緩衝區的數量，full 記錄滿緩衝區的數量。其中，empty 信號量是在生產者進程中使用，當 empty 不爲 0 時，生產者才能夠放入物品；full 信號量是在消費者進程中使用，當 full 信號量不爲 0 時，消費者才能夠取走物品。
注意，不能先對緩衝區進行加鎖，再測試信號量。也就是說，不能先執行 down(mutex) 再執行 down(empty)。若是這麼作了，那麼可能會出現這種狀況：生產者對緩衝區加鎖後，執行 down(empty) 操做，發現 empty = 0，此時生產者睡眠。消費者不能進入臨界區，由於生產者對緩衝區加鎖了，消費者就沒法執行 up(empty) 操做，empty 永遠都爲 0，致使生產者永遠等待下，不會釋放鎖，消費者所以也會永遠等待下去。
#define N 100
typedef int semaphore;
semaphore mutex = 1;
semaphore empty = N;
semaphore full = 0;
void producer() {
while(TRUE) {
int item = produce_item();
down(&empty);
down(&mutex);
insert_item(item);
up(&mutex);
up(&full);
}
}
void consumer() {
while(TRUE) {
down(&full);
down(&mutex);
int item = remove_item();
consume_item(item);
up(&mutex);
up(&empty);
}
}
複製代碼
4. 管程
使用信號量機制實現的生產者消費者問題須要客戶端代碼作不少控制，而管程把控制的代碼獨立出來，不只不容易出錯，也使得客戶端代碼調用更容易。
c 語言不支持管程，下面的示例代碼使用了類 Pascal 語言來描述管程。示例代碼的管程提供了 insert() 和 remove() 方法，客戶端代碼經過調用這兩個方法來解決生產者-消費者問題。
monitor ProducerConsumer
integer i;
condition c;
procedure insert();
begin
// ...
end;
procedure remove();
begin
// ...
end;
end monitor;
複製代碼
管程有一個重要特性：在一個時刻只能有一個進程使用管程。進程在沒法繼續執行的時候不能一直佔用管程，否者其它進程永遠不能使用管程。
管程引入了 條件變量 以及相關的操做：wait() 和 signal() 來實現同步操做。對條件變量執行 wait() 操做會致使調用進程阻塞，把管程讓出來給另外一個進程持有。signal() 操做用於喚醒被阻塞的進程。
使用管程實現生產者-消費者問題
// 管程// 管程
monitor ProducerConsumer
condition full, empty;
integer count := 0;
condition c;
procedure insert(item: integer);
begin
if count = N then wait(full);
insert_item(item);
count := count + 1;
if count = 1 then signal(empty);
end;
function remove: integer;
begin
if count = 0 then wait(empty);
remove = remove_item;
count := count - 1;
if count = N -1 then signal(full);
end;
end monitor;
// 生產者客戶端
procedure producer
begin
while true do
begin
item = produce_item;
ProducerConsumer.insert(item);
end
end;
// 消費者客戶端
procedure consumer
begin
while true do
begin
item = ProducerConsumer.remove;
consume_item(item);
end
end;
複製代碼
經典同步問題
生產者和消費者問題前面已經討論過了。
1. 讀者-寫者問題
容許多個進程同時對數據進行讀操做，可是不容許讀和寫以及寫和寫操做同時發生。
一個整型變量 count 記錄在對數據進行讀操做的進程數量，一個互斥量 count_mutex 用於對 count 加鎖，一個互斥量 data_mutex 用於對讀寫的數據加鎖。
typedef int semaphore;
semaphore count_mutex = 1;
semaphore data_mutex = 1;
int count = 0;
void reader() {
while(TRUE) {
down(&count_mutex);
count++;
if(count == 1) down(&data_mutex); // 第一個讀者須要對數據進行加鎖，防止寫進程訪問
up(&count_mutex);
read();
down(&count_mutex);
count--;
if(count == 0) up(&data_mutex);
up(&count_mutex);
}
}
void writer() {
while(TRUE) {
down(&data_mutex);
write();
up(&data_mutex);
}
}
複製代碼
如下內容由 @Bandi Yugandhar 提供。
The first case may result Writer to starve. This case favous Writers i.e no writer, once added to the queue, shall be kept waiting longer than absolutely necessary(only when there are readers that entered the queue before the writer).
int readcount, writecount; //(initial value = 0)
semaphore rmutex, wmutex, readLock, resource; //(initial value = 1)
//READER
void reader() {
<ENTRY Section>
down(&readLock); // reader is trying to enter
down(&rmutex); // lock to increase readcount
readcount++;
if (readcount == 1)
down(&resource); //if you are the first reader then lock the resource
up(&rmutex); //release for other readers
up(&readLock); //Done with trying to access the resource
<CRITICAL Section>
//reading is performed
<EXIT Section>
down(&rmutex); //reserve exit section - avoids race condition with readers
readcount--; //indicate you're leaving
if (readcount == 0) //checks if you are last reader leaving
up(&resource); //if last, you must release the locked resource
up(&rmutex); //release exit section for other readers
}
//WRITER
void writer() {
<ENTRY Section>
down(&wmutex); //reserve entry section for writers - avoids race conditions
writecount++; //report yourself as a writer entering
if (writecount == 1) //checks if you're first writer
down(&readLock); //if you're first, then you must lock the readers out. Prevent them from trying to enter CS
up(&wmutex); //release entry section
<CRITICAL Section>
down(&resource); //reserve the resource for yourself - prevents other writers from simultaneously editing the shared resource
//writing is performed
up(&resource); //release file
<EXIT Section>
down(&wmutex); //reserve exit section
writecount--; //indicate you're leaving
if (writecount == 0) //checks if you're the last writer
up(&readLock); //if you're last writer, you must unlock the readers. Allows them to try enter CS for reading
up(&wmutex); //release exit section
}
複製代碼
We can observe that every reader is forced to acquire ReadLock. On the otherhand, writers doesn’t need to lock individually. Once the first writer locks the ReadLock, it will be released only when there is no writer left in the queue.
From the both cases we observed that either reader or writer has to starve. Below solutionadds the constraint that no thread shall be allowed to starve; that is, the operation of obtaining a lock on the shared data will always terminate in a bounded amount of time.
int readCount; // init to 0; number of readers currently accessing resource
// all semaphores initialised to 1
Semaphore resourceAccess; // controls access (read/write) to the resource
Semaphore readCountAccess; // for syncing changes to shared variable readCount
Semaphore serviceQueue; // FAIRNESS: preserves ordering of requests (signaling must be FIFO)
void writer() {
down(&serviceQueue); // wait in line to be servicexs
// <ENTER>
down(&resourceAccess); // request exclusive access to resource
// </ENTER>
up(&serviceQueue); // let next in line be serviced
// <WRITE>
writeResource(); // writing is performed
// </WRITE>
// <EXIT>
up(&resourceAccess); // release resource access for next reader/writer
// </EXIT>
}
void reader() {
down(&serviceQueue); // wait in line to be serviced
down(&readCountAccess); // request exclusive access to readCount
// <ENTER>
if (readCount == 0) // if there are no readers already reading:
down(&resourceAccess); // request resource access for readers (writers blocked)
readCount++; // update count of active readers
// </ENTER>
up(&serviceQueue); // let next in line be serviced
up(&readCountAccess); // release access to readCount
// <READ>
readResource(); // reading is performed
// </READ>
down(&readCountAccess); // request exclusive access to readCount
// <EXIT>
readCount--; // update count of active readers
if (readCount == 0) // if there are no readers left:
up(&resourceAccess); // release resource access for all
// </EXIT>
up(&readCountAccess); // release access to readCount
}
複製代碼
2. 哲學家進餐問題
五個哲學家圍着一張圓桌，每一個哲學家面前放着食物。哲學家的生活有兩種交替活動：吃飯以及思考。當一個哲學家吃飯時，須要先拿起本身左右兩邊的兩根筷子，而且一次只能拿起一根筷子。
下面是一種錯誤的解法，考慮到若是全部哲學家同時拿起左手邊的筷子，那麼就沒法拿起右手邊的筷子，形成死鎖。
#define N 5
void philosopher(int i) {
while(TRUE) {
think();
take(i); // 拿起左邊的筷子
take((i+1)%N); // 拿起右邊的筷子
eat();
put(i);
put((i+1)%N);
}
}
複製代碼
爲了防止死鎖的發生，能夠設置兩個條件：
必須同時拿起左右兩根筷子；
只有在兩個鄰居都沒有進餐的狀況下才容許進餐。
#define N 5
#define LEFT (i + N - 1) % N // 左鄰居
#define RIGHT (i + 1) % N // 右鄰居
#define THINKING 0
#define HUNGRY 1
#define EATING 2
typedef int semaphore;
int state[N]; // 跟蹤每一個哲學家的狀態
semaphore mutex = 1; // 臨界區的互斥
semaphore s[N]; // 每一個哲學家一個信號量
void philosopher(int i) {
while(TRUE) {
think();
take_two(i);
eat();
put_two(i);
}
}
void take_two(int i) {
down(&mutex);
state[i] = HUNGRY;
test(i);
up(&mutex);
down(&s[i]);
}
void put_two(i) {
down(&mutex);
state[i] = THINKING;
test(LEFT);
test(RIGHT);
up(&mutex);
}
void test(i) { // 嘗試拿起兩把筷子
if(state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] !=EATING) {
state[i] = EATING;
up(&s[i]);
}
}
複製代碼
進程通訊
進程同步與進程通訊很容易混淆，它們的區別在於：
進程同步：控制多個進程按必定順序執行；
進程通訊：進程間傳輸信息。
進程通訊是一種手段，而進程同步是一種目的。也能夠說，爲了可以達到進程同步的目的，須要讓進程進行通訊，傳輸一些進程同步所須要的信息。
1. 管道
管道是經過調用 pipe 函數建立的，fd[0] 用於讀，fd[1] 用於寫。
#include <unistd.h>
int pipe(int fd[2]);
複製代碼
它具備如下限制：
只支持半雙工通訊（單向交替傳輸）；
只能在父子進程中使用。
2. FIFO
也稱爲命名管道，去除了管道只能在父子進程中使用的限制。
#include <sys/stat.h>
int mkfifo(const char *path, mode_t mode);
int mkfifoat(int fd, const char *path, mode_t mode);
複製代碼
FIFO 經常使用於客戶-服務器應用程序中，FIFO 用做匯聚點，在客戶進程和服務器進程之間傳遞數據。
3. 消息隊列
相比於 FIFO，消息隊列具備如下優勢：
消息隊列能夠獨立於讀寫進程存在，從而避免了 FIFO 中同步管道的打開和關閉時可能產生的困難；
避免了 FIFO 的同步阻塞問題，不須要進程本身提供同步方法；
讀進程能夠根據消息類型有選擇地接收消息，而不像 FIFO 那樣只能默認地接收。
4. 信號量
它是一個計數器，用於爲多個進程提供對共享數據對象的訪問。
5. 共享存儲
容許多個進程共享一個給定的存儲區。由於數據不須要在進程之間複製，因此這是最快的一種 IPC。
須要使用信號量用來同步對共享存儲的訪問。
多個進程能夠將同一個文件映射到它們的地址空間從而實現共享內存。另外 XSI 共享內存不是使用文件，而是使用使用內存的匿名段。
6. 套接字
與其它通訊機制不一樣的是，它可用於不一樣機器間的進程通訊。
（文章 實在太長 分兩篇完成 ）續......
推薦閱讀：阿里騰訊Android開發十年，到中年危機就只剩下這套移動架構體系了！
- 1. 搞定操做系統面試，看這篇就夠了（二）
- 2. 搞定操做系統面試，看這篇就夠了
- 3. 搞定操作系統面試，看這篇就夠了（一）
- 4. 搞定操作系統面試，看這篇就夠了（二）
- 5. 搞定SEO，看這一篇就夠了
- 6. python面試看這一篇就夠了
- 7. 面試 ConcurrentHashMap ，看這一篇就夠了！
- 8. 搞定計算機網絡面試，看這篇就夠了
- 9. 搞定markdown，這一篇就夠了
- 10. Git 操做，看這篇就夠了！
- 更多相關文章...
- • 系統定義的TypeHandler - MyBatis教程
- • 操作系統（OS）平臺 統計 - 瀏覽器信息
- • Docker容器實戰(七) - 容器眼光下的文件系統
- • 再有人問你分佈式事務，把這篇扔給他
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 安裝cuda+cuDNN
- 2. GitHub的使用說明
- 3. phpDocumentor使用教程【安裝PHPDocumentor】
- 4. yarn run build報錯Component is not found in path 「npm/taro-ui/dist/weapp/components/rate/index「
- 5. 精講Haproxy搭建Web集羣
- 6. 安全測試基礎之MySQL
- 7. C/C++編程筆記：C語言中的複雜聲明分析，用實例帶你完全讀懂
- 8. Python3教程(1)----搭建Python環境
- 9. 李宏毅機器學習課程筆記2：Classification、Logistic Regression、Brief Introduction of Deep Learning
- 10. 阿里雲ECS配置速記