操做系統與服務器

瀑布模型

瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協做，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟件生命週期劃分爲可行性分析、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

對於常常變化的項目而言，瀑布模型毫無價值

簡述模型優缺點，簡述其餘模型如何彌補瀑布模型的不足

優勢：階段劃分清晰，各階段人員的職責明確，便於先後活動的銜接，有利於活動的重用和管理

缺點：缺少靈活性，沒法解決需求常常變化的問題

用其餘彌補不足：

原型化模型：用於解決需求不明確的狀況

螺旋模型：強調風險分析，特別適合龐大而複雜的、高風險的系統

 

進程和線程

1.對進程和線程的描述，一下（）是正確的

　　A 父進程的全部線程共享相同的地址空間，父進程的全部子進程共享相同的地址空間

　　B 改變進程裏面主線程的狀態會影響其餘線程的行爲，改變父進程的狀態不會影響其餘子進程

　　C 多線程會引發死鎖，而多進程則不會

　　D 以上都不對

D   進程擁有獨立的地址空間，A錯；多進程中父進程與子進程互不會影響，B錯；多線程和多進程都會引發死鎖，通常提及死鎖指的都是進程間的死鎖，C錯。

 

 什麼是進程（Process）和線程（Thread）

進程（Process）是應用程序的一次運行活動。從操做系統核心角度來講，進程是操做系統分配和調度系統內存資源、cpu時間片等資源的基本單位，爲正在運行的應用程序提供

運行環境。

線程（Thread）是程序內部有併發性的順序代碼流。是cpu調度資源的最小單元。

單位大小

進程是操做系統分配和調度系統內存資源、cpu時間片 等資源的基本單位；一個進程至少包括一個線程。進程是操做系統資源管理的實體。
線程是cpu調度資源的最小單元。線程是進程的實體。

系統資源分配上

每一個進程都有本身的內存地址空間。
線程沒有本身獨立的內存資源，它只有本身的執行堆棧和局部變量。可是在同屬一個進程的多個線程中他們能夠共享進程的內存

 

執行過程當中

執行過程當中，進程有內存單元的初始入口點，在存活階段裏擁有獨立的地址空間。
進程是應用程序的一次運行活動，獨立地執行；因此某一個進程崩潰之後，在保護模式下不會影響其餘的進程，健壯性好。

每一個已建立的進程均可以建立進程，建立進程的進程稱爲父進程，被建立的新進程爲子進程，這樣便造成一個進程樹。

父進程與子進程可並行執行；父進程等 待子進程終止執行。父進程終止後，全部的子進程也都必需要終止。

而線程不能獨立地執行，它必須依附在一個運行中的應用程序上。
可是，同一個進程中的多個線程能夠併發地執行，併發性高，系統在數據交換上花費的資源少，運行效率高。

每一個進程裏都會有一個主線程，由它建立其餘線程。

（

父進程爲何要建立子進程 

在程序設計時，某一個具體的功能模塊能夠經過函數或是線程等不一樣的形式來實現。對於同一進程而言，這些函數、線程都是存在於同一個地址空間下的，並且在執行時，大多隻對與其相關的一些數據進行處理。若是算法存在某種錯誤，將有可能破壞與其同處一個地址空間的其餘一些重要內容，這將形成比較嚴重的後果。爲保護地址空間中的內容能夠考慮將那些須要對地址空間中的數據進行訪問的操做部分放到另一個進程的地址空間中運行，而且只容許其訪問原進程地址空間中的相關數據。

）

 

共同點
Process和Thread都有生命週期：
create 建立，ready就緒，running運行，waitSleepJoin阻塞，suspend掛起，stoped死亡

 

 

請闡述進程與線程的區別。

解答：

• ①從概念上：
• 進程：一個程序對一個數據集的動態執行過程，是分配資源的基本單位。
• 線程：一個進程內的基本調度單位。線程的劃分尺度小於進程，一個進程包含一個或者更多的線程。
• ②從執行過程當中來看：
• 進程：擁有獨立的內存單元，而多個線程共享內存，從而提升了應用程序的運行效率。
• 線程：每個獨立的線程，都有一個程序運行的入口、順序執行序列、和程序的出口。可是線程不可以獨立的執行，必須依存在應用程序中，由應用程序提供多個線程執行控制。
• ③從邏輯角度來看（重要區別）：
• 多線程的意義在於一個應用程序中，有多個執行部分能夠同時執行。可是，操做系統並無將多個線程看作多個獨立的應用，來實現進程的調度和管理及資源分配。

 

進程通訊方式有哪些？

進程間通信的方式： 管道通信,消息隊列，信號量，共享內存,信號，套接字

解答：主要有如下6種：

• 一、管道：管道是單向的、先進先出的、無結構的、固定大小的字節流，它把一個進程的標準輸出和另外一個進程的標準輸入鏈接在一塊兒。寫進程在管道的尾端寫入數據，讀進程在管道的道端讀出數據。數據讀出後將從管道中移走，其它讀進程都不能再讀到這些數據。管道提供了簡單的流控制機制。進程試圖讀空管道時，在有數據寫入管道前，進程將一直阻塞。一樣地，管道已經滿時，進程再試圖寫管道，在其它進程從管道中移走數據以前，寫進程將一直阻塞。
• 無名管道：管道是一種半雙工的通訊方式，數據只能單向流動，並且只能在具備親緣關係（一般是指父子進程關係）的進程間使用。
• 命名管道：命名管道也是半雙工的通訊方式，在文件系統中做爲一個特殊的設備文件而存在，可是它容許無親緣關係進程間的通訊。當共享管道的進程執行完全部的I/O操做之後，命名管道將繼續保存在文件系統中以便之後使用。
• 二、信號量：信號量是一個計數器，能夠用來控制多個進程對共享資源的訪問。它常做爲一種鎖機制，防止某進程正在訪問共享資源時，其它進程也訪問該資源。所以，主要做爲進程間以及同一進程內不一樣線程之間的同步手段。
• 三、消息隊列：消息隊列是由消息的鏈表，存放在內核中並由消息隊列標識符標識。消息隊列克服了信號傳遞信息少、管道只能承載無格式字節流以及緩衝區大小受限等缺點。
• 四、信號：信號是一種比較複雜的通訊方式，用於通知接收進程某個事件已經發生。
• 五、共享內存：共享內存就是映射一段能被其它進程所訪問的內存，這段共享內存由一個進程建立，但多個進程均可以訪問。共享內存是最快的IPC方式，它是針對其它進程間通訊方式運行效率低而專門設計的。它每每與其它通訊機制（如信號量）配合使用，來實現進程間的同步和通訊。
• 六、套接字：套接字也是一種進程間通訊機制，與其它通訊機制不一樣的是，它可用於不一樣機器間的進程通訊。

幾種方式的比較：

• 管道：速度慢，容量有限
• 消息隊列：容量受到系統限制，且要注意第一次讀的時候，要考慮上一次沒有讀完數據的問題。
• 信號量：不能傳遞複雜消息，只能用來同步
• 共享內存區：可以很容易控制容量，速度快，但要保持同步，好比一個進程在寫的時候，另外一個進程要注意讀寫的問題，至關於線程中的線程安全，固然，共享內存區一樣能夠用做線程間通信，不過沒這個必要，線程間原本就已經共享了一塊內存的。

 

同步的方式有哪些？

線程同步指多個線程同時訪問某資源時，採用一系列的機制以保證同時最多隻能一個線程訪問該資源。線程同步是多線程中必須考慮和解決的問題，由於極可能發生多個線程同時訪問（主要是寫操做）同一資源，若是不進行線程同步，極可能會引發數據混亂，形成線程死鎖等問題；

線程同步的方式：臨界區，互斥對象機制，信號量對象，事件信號

• 臨界區：經過對多線程的串行化來訪問公共資源或者一段代碼，速度快，適合控制數據訪問
• 互斥量：採用互斥對象機制，只有擁有互斥對象的線程纔有訪問公共資源的權限，由於互斥對象只有一個，因此能夠保證公共資源不會同時被多個線程訪問
• 信號量：它容許多個線程同一時刻訪問同一資源，可是須要限制同一時刻訪問此資源的最大線程數目。信號量對象對線程的同步方式與前面幾種方法不一樣，信號容許多個線程同時使用共享資源，這與操做系統中PV操做類似。
• 事件（信號）：經過通知操做的方式來保持多線程的同步，還能夠方便的實現多線程的優先級比較的操做

總結比較：　

• 互斥量與臨界區的做用很是類似，但互斥量是能夠命名的，也就是說它能夠跨越進程使用。因此建立互斥量須要的資源更多，因此若是隻爲了在進程內部是用的話使用臨界區會帶來速度上的優點並可以減小資源佔用量。由於互斥量是跨進程的互斥量一旦被建立，就能夠經過名字打開它。
• 互斥量（Mutex），信號燈（Semaphore），事件（Event）均可以被跨越進程使用來進行同步數據操做，而其餘的對象與數據同步操做無關，但對於進程和線程來說，若是進程和線程在運行狀態則爲無信號狀態，在退出後爲有信號狀態。因此可使用WaitForSingleObject來等待進程和線程退出。
• 經過互斥量能夠指定資源被獨佔的方式使用，但若是有下面一種狀況經過互斥量就沒法處理，好比如今一位用戶購買了一份三個併發訪問許可的數據庫系統，能夠根據用戶購買的訪問許可數量來決定有多少個線程/進程能同時進行數據庫操做，這時候若是利用互斥量就沒有辦法完成這個要求，信號燈對象能夠說是一種資源計數器

 

說出你所知道的保持進程同步的方法？

　　進程間同步的主要方法有原子操做、信號量機制、自旋鎖、管程、會合、分佈式系統等。

 

線程安全

若是你的代碼所在的進程中有多個線程在同時運行，而這些線程可能會同時運行這段代碼。若是每次運行結果和單線程運行的結果是同樣的，並且其餘的變量的值也和預期的是同樣的，就是線程安全的。或者說:一個類或者程序所提供的接口對於線程來講是原子操做或者多個線程之間的切換不會致使該接口的執行結果存在二義性,也就是說咱們不用考慮同步的問題。

 

什麼是死鎖？其條件是什麼？怎樣避免死鎖？

首先回答死鎖的定義，所謂死鎖就是一個進程集合中的多個進程由於競爭資源，而形成的互相等待現象。

死鎖的緣由：系統資源不足；多個進程的推動順序不合理

死鎖的必要條件：

• 互斥條件（Mutual exclusion）：資源不能被共享，只能由一個進程使用。
• 請求與保持條件（Hold and wait）：已經獲得資源的進程能夠再次申請新的資源。
• 非剝奪條件（No pre-emption）：已經分配的資源不能從相應的進程中被強制地剝奪。
• 循環等待條件（Circular wait）：系統中若干進程組成環路，改環路中每一個進程都在等待相鄰進程正佔用的資源。

處理死鎖的策略：

• 鴕鳥策略。忽略該問題。例如鴕鳥算法，該算法能夠應用在極少發生死鎖的狀況下。傳說中，鴕鳥看到危險就把頭深埋地下，這是顯然是一種很消極的策略。
• 檢測與恢復策略。檢測死鎖而且恢復。
• 避免策略。仔細地對資源進行動態分配，以免死鎖。
• 預防策略。經過破壞死鎖的必要條件，來防止死鎖的產生。

 

解除死鎖，銀行家算法：http://blog.csdn.net/abigale1011/article/details/6450845/

 

銀行家算法

銀行家算法（ banker's algorithm ）由 Dijkstra(1065)提出。他將死鎖的問題演示爲一個銀行家貸款的模型。
一個銀行家向一羣客戶發放信用卡，每一個客戶有不一樣的信用額度。每一個客戶能夠提出信用額度內的任意額度的請求，直到額度用完後再一次性還款。銀行家承諾每一個客戶最終都能得到本身須要的額度。
所謂「最終」，是說銀行家能夠先掛起某個額度請求較大的客戶的請求，優先知足小額度的請求，等小額度的請求還款後，再處理掛起的請求。這樣，資金可以永遠流通。

銀行家算法其核心是：保證本身的限額至少不小於一個客戶的限額。
咱們能夠用填表法來快速解決銀行家算法。

創建一個二維表格：每列數據表示每次交易各個參與者的限額。這個表格第一列數據是銀行家是客戶的交易限額，每發生一次交易，增長一列，同時將銀行家和發生交易的客戶的限額減少。直到銀行家的限額小於某個客戶的限額時，交易不能繼續進行。不然便發生死鎖。

例題：
一、操做系統分配資源時的一個重要考慮是避免死鎖的發生．若系統中有同類資源 16 個，由四個進程 P一、P二、P3 和 P4 共享該資源。已知 P一、P二、P三、P4 所需的資源總數分別爲 八、五、九、6。各進程請求資源的次序以下表，若系統採用銀行家算法爲它們分配資源，那麼_(1)__依次申請分配會使系統進入不安全狀態。 
進程申請資源的狀況

序號 進程 申請量 
1 P1 6 
2 P2 4 
3 P3 5 
4 P4 1 
5 P1 1 
6 P2 1 
A．三、4 B．三、5 C．四、5 D．五、6

答案是c
咱們初始化一個二維表格

到完成第三個請求到達的時候，資源只有一個了。此時只能知足p2的請求。因此，第四個和第五個請求會被系統掛起。第六個請求p2到達後會被處理。等p2事務結束釋放資源後，系統會再處理掛起的請求，這樣就不會發生死鎖。一旦在第三步後將剩下的惟一的一個資源分配給其它的進程，（如請求4或請求5），則請求4和5可能會因須要不止一個資源而繼續等待，則發生了死鎖。(經過表格能夠看出，依次申請到C組時，銀行家的剩餘額度已經不能知足全部的客戶的需求了)

 

描述實時系統的基本特性

　　在特定時間內完成特定的任務，實時性與可靠性。

　　所謂「實時操做系統」，其實是指操做系統工做時，其各類資源能夠根據須要隨時進行動態分配。因爲各類資源能夠進行動態分配，所以，其處理事務的能力較強、速度較快。

 

中斷和輪詢的特色

　　對I/O設備的程序輪詢的方式，是早期的計算機系統對I/O設備的一種管理方式。它定時對各類設備輪流詢問一遍有無處理要求。輪流詢問以後，有要求的，則加以處理。在處理I/O設備的要求以後，處理機返回繼續工做。儘管輪詢須要時間，但輪詢要比I/O設備的速度要快得多，因此通常不會發生不能及時處理的問題。固然，再快的處理機，能處理的輸入輸出設備的數量也是有必定限度的。並且，程序輪詢畢竟佔據了CPU至關一部分處理時間，所以，程序輪詢是一種效率較低的方式，在現代計算機系統中已不多應用。

　　中斷是指在計算機執行期間，系統內發生任何非尋常的或非預期的急需處理事件，使得CPU暫時中斷當前正在執行的程序而轉去執行相應的事件處理程序。待處理完畢後又返回原來被中斷處繼續執行或調度新的進程執行的過程。

　　輪詢——效率低，等待時間很長，CPU利用率不高。

　　中斷——容易遺漏一些問題，CPU利用率高。

 

什麼是臨界區？如何解決衝突？

　　每一個進程中訪問臨界資源的那段程序稱爲臨界區，每次只准許一個進程進入臨界區，進入後不容許其餘進程進入。

　　（1）若是有若干進程要求進入空閒的臨界區，一次僅容許一個進程進入；

　　（2）任什麼時候候，處於臨界區內的進程不可多於一個。如已有進程進入本身的臨界區，則其它全部試圖進入臨界區的進程必須等待；

　　（3）進入臨界區的進程要在有限時間內退出，以便其它進程能及時進入本身的臨界區；

　　（4）若是進程不能進入本身的臨界區，則應讓出CPU，避免進程出現「忙等」現象。

 

你知道操做系統的內容分爲幾塊嗎？什麼叫作虛擬內存？他和主存的關係如何？內存管理屬於操做系統的內容嗎？

　　操做系統的主要組成部分：進程和線程的管理，存儲管理，設備管理，文件管理。虛擬內存是一些系統頁文件，存放在磁盤上，每一個系統頁文件大小爲4K，物理內存也被分頁，每一個頁大小也爲4K，這樣虛擬頁文件和物理內存頁就能夠對應，實際上虛擬內存就是用於物理內存的臨時存放的磁盤空間。頁文件就是內存頁，物理內存中每頁叫物理頁，磁盤上的頁文件叫虛擬頁，物理頁+虛擬頁就是系統全部使用的頁文件的總和。

 

說說分段和分頁

　　頁是信息的物理單位，分頁是爲實現離散分配方式，以消減內存的外零頭，提升內存的利用率；或者說，分頁僅僅是因爲系統管理的須要，而不是用戶的須要。

　　段是信息的邏輯單位，它含有一組其意義相對完整的信息。分段的目的是爲了能更好的知足用戶的須要。

　　頁的大小固定且由系統肯定，把邏輯地址劃分爲頁號和頁內地址兩部分，是由機器硬件實現的，於是一個系統只能有一種大小的頁面。段的長度卻不固定，決定於用戶所編寫的程序，一般由編輯程序在對源程序進行編輯時，根據信息的性質來劃分。

　　分頁的做業地址空間是一維的，即單一的線性空間，程序員只須利用一個記憶符，便可表示一地址。分段的做業地址空間是二維的，程序員在標識一個地址時，既需給出段名，又需給出段內地址。

 

Linux中經常使用到的命令

　　顯示文件目錄命令ls        如ls

　　改變當前目錄命令cd        如cd /home

　　創建子目錄mkdir           如mkdir xiong

　　刪除子目錄命令rmdir       如rmdir /mnt/cdrom

　　刪除文件命令rm            如rm /ucdos.bat

　　文件複製命令cp            如cp /ucdos /fox

　　獲取幫助信息命令man      如man ls

　　顯示文件的內容less        如less mwm.lx

　　重定向與管道type          如type readme>>direct，將文件readme的內容追加到文direct中

 

Linux文件屬性有哪些？（共十位）

　　-rw-r--r--那個是權限符號，總共是- --- --- ---這幾個位。

　　第一個短橫處是文件類型識別符：-表示普通文件；c表示字符設備（character）；b表示塊設備（block）；d表示目錄（directory）；l表示連接文件（link）；後面第一個三個連續的短橫是用戶權限位（User），第二個三個連續短橫是組權限位（Group），第三個三個連續短橫是其餘權限位（Other）。每一個權限位有三個權限，r（讀權限），w（寫權限），x（執行權限）。若是每一個權限位都有權限存在，那麼滿權限的狀況就是：-rwxrwxrwx；權限爲空的狀況就是- --- --- ---。

　　權限的設定能夠用chmod命令，其格式位：chmod ugoa+/-/=rwx filename/directory。例如：

　　一個文件aaa具備徹底空的權限- --- --- ---。

　　chmod u+rw aaa（給用戶權限位設置讀寫權限，其權限表示爲：- rw- --- ---）

　　chmod g+r aaa（給組設置權限爲可讀，其權限表示爲：- --- r-- ---）

　　chmod ugo+rw aaa（給用戶，組，其它用戶或組設置權限爲讀寫，權限表示爲：- rw- rw- rw-）

　　若是aaa具備滿權限- rwx rwx rwx。

　　chmod u-x aaa（去掉用戶可執行權限，權限表示爲：- rw- rwx rwx）

　　若是要給aaa賦予制定權限- rwx r-x r-x，命令爲：

　　chmod u=rwx，go=rx aaa

 

makefile文件的做用是什麼？

　　一個工程中的源文件不可勝數，其按類型、功能、模塊分別放在若干個目錄中。makefile定義了一系列的規則來指定哪些文件須要先編譯，哪些文件須要後編譯，哪些文件須要從新編譯，甚至於進行更復雜的功能操做。由於makefile就像一個Shell腳本同樣，其中也能夠執行操做系統的命令。makefile帶來的好處就是——「自動化編譯」。一旦寫好，只須要一個make命令，整個工程徹底自動編譯，極大地提升了軟件開發的效率。make是一個命令工具，是一個解釋makefile中指令的命令工具。通常來講，大多數的IDE都有這個命令，好比：Delphi的make，Visual C++的nmake，Linux下GNU的make。可見，makefile都成爲了一種在工程方面的編譯方法。

 

什麼是緩衝區溢出？有什麼危害？其緣由是什麼？

　　緩衝區溢出是指當計算機向緩衝區內填充數據時超過了緩衝區自己的容量，溢出的數據覆蓋在合法數據上。

　　危害：在當前網絡與分佈式系統安全中，被普遍利用的50%以上都是緩衝區溢出，其中最著名的例子是1988年利用fingerd漏洞的蠕蟲。而緩衝區溢出中，最爲危險的是堆棧溢出，由於入侵者能夠利用堆棧溢出，在函數返回時改變返回程序的地址，讓其跳轉到任意地址，帶來的危害一種是程序崩潰致使拒絕服務，另一種就是跳轉而且執行一段惡意代碼，好比獲得shell，而後隨心所欲。經過往程序的緩衝區寫超出其長度的內容，形成緩衝區的溢出，從而破壞程序的堆棧，使程序轉而執行其它指令，以達到攻擊的目的。

　　形成緩衝區溢出的主緣由是程序中沒有仔細檢查用戶輸入的參數。

 

操做系統進程調度算法

http://blog.csdn.net/luyafei_89430/article/details/12971171

1、先來先服務和短做業(進程)優先調度算法
1.先來先服務調度算法
2.短做業(進程)優先調度算法

2、高優先權優先調度算法
1.優先權調度算法，包括非搶佔式優先權算法、搶佔式優先權調度算法(強調系統的實時性，實時比較優先級)
2.高響應比優先調度算法，優先權=（等待時間+要求服務時間）/要求服務時間
(1) 若是做業的等待時間相同，則要求服務的時間愈短，其優先權愈高，於是該算法有利於短做業。
(2) 當要求服務的時間相同時，做業的優先權決定於其等待時間，等待時間愈長，其優先權愈高，於是它實現的是先來先服務。
(3) 對於長做業，做業的優先級能夠隨等待時間的增長而提升，當其等待時間足夠長時，其優先級即可升到很高，從而也可得到處理機。簡言之，該算法既照顧了短做業，又考慮了做業到達的前後次序，不會使長做業長期得不到服務。所以，該算法實現了一種較好的折衷。固然，在利用該算法時，每要進行調度以前，都須先作響應比的計算，這會增長系統開銷。

3、基於時間片的輪轉調度算法
1．時間片輪轉法
2．多級反饋隊列調度算法，
多級反饋隊列調度算法則沒必要事先知道各類進程所需的執行時間，並且還能夠知足各類類型進程的須要，於是它是目前被公認的一種較好的進程調度算法。
(1) 應設置多個就緒隊列，併爲各個隊列賦予不一樣的優先級。第一個隊列的優先級最高，第二個隊列次之，其他各隊列的優先權逐個下降。該算法賦予各個隊列中進程執行時間片的大小也各不相同，在優先權愈高的隊列中，爲每一個進程所規定的執行時間片就愈小。例如，第二個隊列的時間片要比第一個隊列的時間片長一倍，……，第i+1個隊列的時間片要比第i個隊列的時間片長一倍。
(2) 當一個新進程進入內存後，首先將它放入第一隊列的末尾，按FCFS原則排隊等待調度。當輪到該進程執行時，如它能在該時間片內完成，即可準備撤離系統；若是它在一個時間片結束時還沒有完成，調度程序便將該進程轉入第二隊列的末尾，再一樣地按FCFS原則等待調度執行；若是它在第二隊列中運行一個時間片後仍未完成，再依次將它放入第三隊列，……，如此下去，當一個長做業(進程)從第一隊列依次降到第n隊列後，在第n 隊列便採起按時間片輪轉的方式運行。
(3) 僅當第一隊列空閒時，調度程序才調度第二隊列中的進程運行；僅當第1～(i-1)隊列均空時，纔會調度第i隊列中的進程運行。若是處理機正在第i隊列中爲某進程服務時，又有新進程進入優先權較高的隊列(第1～(i-1)中的任何一個隊列)，則此時新進程將搶佔正在運行進程的處理機，即由調度程序把正在運行的進程放回到第i隊列的末尾，把處理機分配給新到的高優先權進程。

 

服務器線程優化問題？

線程是輕量級的，它本身不擁有系統資源，可是咱們知道線程執行時候是能夠操做硬盤的文件，也能夠操做內存的數據，那麼這些被線程操做的資源從哪裏來的呢？

答案：線程用的進程的資源

 

線程的特色：

• 特色一：線程是進程的一個實體，也就是說線程的母體是進程，這是線程的範疇問題。
• 特色二：線程是輕量級的，它本身不擁有系統資源，可是咱們知道線程執行時候是能夠操做硬盤的文件，也能夠操做內存的數據，那麼這些被線程操做的資源從哪裏來的呢？上面的解釋裏回答了這個問題，那就是線程能夠共享進程的資源，換句話說線程操做的資源是進程的資源。
• 特色三：線程本身也有寄存器和堆棧，這些東西自己也是能夠存儲數據的，數據也是要佔用系統的部分資源，那麼這個解釋也就說明，線程自己也是能夠佔必定系統資源了，只不過這個資源比較少而已，因此這個解釋就補充了特色二的場景：線程操做的資源除了它所在進程的資源外還有它自身能控制的資源，這一點比較重要，我會在後面講線程安全問題裏提到線程自有資源的使用問題的。

 

線程的運做流程： 線程建立 線程執行 線程銷燬

 

咱們就會發現線程的建立過程和線程的銷燬過程實際上是和處理請求的邏輯無關，可是一個線程又必須經歷這三個階段，所以線程建立的時間和線程銷燬的時間也會被統計到請求處理時間裏，那麼咱們就會想有沒有辦法能夠消除線程建立和銷燬所花的時間對請求處理的影響呢？目標就是減小線程建立和銷燬的時間

 

咱們但願請求處理流程只是做用在線程執行這塊，那麼在實際的生產實踐裏咱們又是如何來解決這個問題了？解決方案就是使用線程池技術，線程池技術就是基於線程建立和銷燬操做影響性能的角度來設計的，不過線程池技術並不是簡單的事先建立好一批線程，而後統一銷燬一批線程那麼簡單.  

 舉例分析JDK的線程池

JDK的線程池對線程池的大小設定了兩個參數，一個是核心線程個數，一個是最大線程個數

1. 1.    系統啓動時，核心線程就會被建立
2. 2.    當用戶請求沒有超過核心線程的處理能力時，新的線程再也不建立
3. 3.    當用戶請求超過核心線程的處理能力時，新的線程建立，使用完畢後不是當即被銷燬，也會被收到線程池裏面，當線程池裏的總數超過最大線程個數時，線程再也不被建立

（線程數量根據實際請求狀況，這樣充分利用了計算機資源， 又避免了資源浪費）

1. 4.    超時機制。當超出核心線程的線程在必定時間內未被使用，那麼這些線程將會被銷燬，資源會被釋放。

（使得線程池裏線程的數量在一個合理的範圍內）

5    隊列機制。對處理不過來的請求排隊等待，當某個線程處理完畢時，該線程會從這個隊列裏面取出一個請求進行處理

      （避免請求的丟失）

6    拒絕策略。若是隊列容量超出了計算機的處理能力，隊列會拋棄沒法處理的請求。

7….JDK還有不少隊列策略

 

由上面對JDK自帶線程池的介紹，咱們發現使用線程池咱們要考慮以下的問題，具體以下：

• 問題一：線程池初始化的時候咱們到底要事先建立多少個線程放在池子裏比較合適。
• 問題二：線程池初始化時候若是建立的線程過多會有什麼問題。
• 問題三：一臺服務器因爲受限於自身能力的限制例如CPU的能力，內存的能力等等，那麼一臺服務器能夠建立多少個有效線程的數量實際上是有個臨界值的，那麼當業務方要求建立超出臨界值的線程時候咱們的處理策略是怎樣的呢。

問題三的我在介紹JDK裏線程池的設計方案時候已經提到了，解決方法就是當業務方要求超出臨界值時候，具體就是超出線程池最大線程數的時候，咱們用一個隊列先緩存這些請求，等線程池裏的線程空閒出來後，再去從隊列裏取出業務請求交付給線程進行處理。

至於問題一和問題二，這個就和多線程的技術相關了，爲了更好的解答它，我這裏先來介紹下多線程技術。

計算機多線程的時間片問題：

有一個線程被分配到的時間片長度是10毫秒，若是這個線程沒有其餘干擾，它執行完畢須要花費50毫秒，那就等於要執行5次時間片，假如咱們再新增了一個線程，該線程時間片也是10毫秒，也要執行50毫秒才能執行完畢，那麼其中一個線程執行完一次時間片，按照輪詢機制另一個線程也要被執行，最後咱們就會發現第一個線程執行時間就變成了100毫秒，若是咱們再加上CPU的調度所花的時間，該線程的執行時間就會遠遠大於100毫秒，雖然100多毫秒人的感官是很難覺察到，可是這個作法畢竟讓單個線程的執行效率大幅度下降了，若是咱們線程開啓的更多，那麼單個線程執行效率也就會變得更低。

有了這個結論咱們再去看看線程池問題一和問題二，若是咱們一開始建立了太多線程，並且這些線程大部分都會被閒置，那麼這些閒置的線程就會讓有效線程的執行效率大大下降，同時閒置的線程還會消耗系統資源，而這些被消耗的系統資源都沒有用到業務處理上，因此成熟的線程池方案就會設計核心線程和最大線程的概念，它們可讓線程池根據實際業務需求和系統負載能力作到動態調節，這樣就能夠減小開啓更多線程影響線程執行效率的問題，也可讓計算機的系統資源獲得更加有效的利用。

C10K的目標

業界有一個C10K的目標，所謂c10k問題,指的是服務器同時支持成千上萬個客戶端的問題,也就是concurrent 10 000 connection（這也是c10k這個名字的由來）。

通常Apache最多支持5000個客戶端的併發請求，並且不會隨着服務器硬件配置的提高有質的改變，並且單個請求的處理能力會降低

而ngnix能夠作到3萬個併發，並且能夠隨服務器配置提高而提高

ngnix的設計

Nginx開發從入門到精通http://tengine.taobao.org/book/#nginx

nginx源碼分析--master和worker進程模型

http://blog.csdn.net/yusiguyuan/article/details/40924415?utm_source=tuicool

《深刻理解Nginx》-陶輝

阿里集團數據平臺博客

阿里集團數據平臺博客2

http://blog.csdn.net/lengzijian/article/details/7349673

 

nginx模塊的開發門檻還挺高，須要開發者對於服務器的非阻塞調用、事件模型有較深的理解，而若是請求處理時須要有全局化視角時，麻煩的多進程通訊又來了，開發者不能使用簡單的堆分配對象，而要使用nginx_slab管理內存。