名詞解釋
輪詢：polling， 效率低，等待時間很長，CPU利用率不高。
中斷：interrupts，容易遺漏一些問題，分屏蔽中斷和非屏蔽中斷。
中斷方式和輪詢方式的區別
中斷的漢語解釋是半中間發生阻隔、停頓或故障而斷開。那麼，在計算機系統中，我們爲什麼需要“阻隔、停頓和斷開”呢？
舉個日常生活中的例子，比如說我正在廚房用煤氣燒一壺水，這樣就只能守在廚房裏，苦苦等着水開——如果水溢出來澆滅了煤氣，有可能就要發生一場災難了。等啊等啊，外邊突然傳來了驚奇的叫聲“怎麼不關水龍頭？”於是我慚愧的發現，剛纔接水之後只顧着抱怨這份無聊的差事，居然忘了這事，於是慌慌張張的衝向水管，三下兩下關了龍頭，聲音又傳到耳邊，“怎麼幹什麼都是這麼馬虎？”。伸伸舌頭，這件小事就這麼過去了，我落寞的眼神又落在了水壺上。
門外忽然又傳來了鏗鏘有力的歌聲，我最喜歡的古裝劇要開演了，真想奪門而出，然而，聽着水壺發出“咕嘟咕嘟”的聲音，我清楚：除非等到水開，否則沒有我享受人生的時候。
這個場景跟中斷有什麼關係呢？
如果說我專心致志等待水開是一個過程的話，那麼叫聲、電視裏傳出的音樂不都讓這個過程“半中間發生阻隔、停頓或故障而斷開”了嗎？這不就是活生生的“中斷”嗎？
在這個場景中，我是唯一具有處理能力的主體，不管是燒水、關水龍頭還是看電視，同一個時間點上我只能幹一件事情。但是，在我專心致志幹一件事情時，總有許多或緊迫或不緊迫的事情突然出現在面前，都需要去關注，有些還需要我停下手頭的工作馬上去處理。只有在處理完之後，方能回頭完成先前的任務，“把一壺水徹底燒開！”
中斷機制不僅賦予了我處理意外情況的能力，如果我能充分發揮這個機制的妙用，就可以“同時”完成多個任務了。回到燒水的例子，實際上，無論我在不在廚房，煤氣竈總是會把水燒開的，我要做的，只不過是及時關掉煤氣竈而已，爲了這麼一個一秒鐘就能完成的動作，卻讓我死死地守候在廚房裏，在10分鐘的時間裏不停地看壺嘴是不是冒蒸氣，怎麼說都不划算。我決定安下心來看電視。當然，在有生之年，我都不希望讓廚房成爲火海，於是我上了鬧鐘，10分鐘以後它會發出“尖叫”，提醒我爐子上的水燒開了，那時我再去關煤氣也完全來得及。我用一箇中斷信號——鬧鈴——換來了10分鐘的歡樂時光，心裏不禁由衷地感嘆：中斷機制真是個好東西。
正是由於中斷機制，我纔能有條不紊地“同時”完成多個任務，中斷機制實質上幫助我提高了併發“處理”能力。它也能給計算機系統帶來同樣的好處：如果在鍵盤按下的時候會得到一箇中斷信號，CPU就不必死守着等待鍵盤輸入了；如果硬盤讀寫完成後發送一箇中斷信號，CPU就可以騰出手來集中精力“服務大衆”了——無論是人類敲打鍵盤的指尖還是來回讀寫介質的磁頭，跟CPU的處理速度相比，都太慢了。沒有中斷機制，就像我們苦守廚房一樣，計算機談不上有什麼並行處理能力。
跟人相似，CPU也一樣要面對紛繁蕪雜的局面——現實中的意外是無處不在的——有可能是用戶等得不耐煩，猛敲鍵盤；有可能是運算中碰到了0除數；還有可能網卡突然接收到了一個新的數據包。這些都需要CPU具體情況具體分析，要麼馬上處理，要麼暫緩響應，要麼置之不理。無論如何應對，都需要CPU暫停“手頭”的工作，拿出一種對策，只有在響應之後，方能回頭完成先前的使命，“把一壺水徹底燒開！”
然後說下 輪詢模式
剛纔中斷已經解釋了,硬件跟 CPU 通信的大致原理,
但是如果 中斷信號過於頻繁,而且中斷後處理的數據過於小.比如 一個網卡遭到 小IP 包的攻擊,每秒10萬個包,都是64字節的小包,
這個時候再強的 CPU 也會累死的,
因爲 CPU 的發展一直在提升 處理數據的能力上,中斷機制 從來沒有改變過.
所以 早期的時候,UNIX 系統提出了軟中斷的概念,類似與 硬件的信號緩存,
在 內存爲每一個 使用中斷的硬件都 開闢一個緩存,
當需要中斷處理的時候,信號是被放在緩存裏,而不是直接交給CPU ,當緩存差不多快滿的時候,讓CPU 一次來處理完,而不用一箇中斷 處理一次,大大減少了 CPU 的壓力.
所以 FREEBSD 4.11的時候,有人做過攻擊試驗.100M 流量的攻擊包,在 BSD 系統沒開 輪詢的時候,CPU 佔用 85%,開了輪詢後,CPU 佔用 3%--5%
