多線程的優(yōu)點和代價
盡管面臨很多挑戰(zhàn)，多線程有一些優(yōu)點使得它一直被使用。這些優(yōu)點是：
-
資源利用率更好
-
程序設(shè)計在某些情況下更簡單
-
程序響應(yīng)更快
資源利用率更好
想象一下，一個應(yīng)用程序需要從本地文件系統(tǒng)中讀取和處理文件的情景。比方說，從磁盤讀取一個文件需要5秒，處理一個文件需要2秒。處理兩個文件則需要：
5秒讀取文件A 2秒處理文件A 5秒讀取文件B 2秒處理文件B --------------------- 總共需要14秒
從磁盤中讀取文件的時候，大部分的CPU時間用于等待磁盤去讀取數(shù)據(jù)。在這段時間里，CPU非常的空閑。它可以做一些別的事情。通過改變操作的順序，就能夠更好的使用CPU資源。看下面的順序：
5秒讀取文件A 5秒讀取文件B + 2秒處理文件A 2秒處理文件B --------------------- 總共需要12秒
CPU等待***個文件被讀取完。然后開始讀取第二個文件。當(dāng)?shù)诙募诒蛔x取的時候，CPU會去處理***個文件。記住，在等待磁盤讀取文件的時候，CPU大部分時間是空閑的。
總的說來，CPU能夠在等待IO的時候做一些其他的事情。這個不一定就是磁盤IO。它也可以是網(wǎng)絡(luò)的IO，或者用戶輸入。通常情況下，網(wǎng)絡(luò)和磁盤的IO比CPU和內(nèi)存的IO慢的多。
程序設(shè)計更簡單
在單線程應(yīng)用程序中，如果你想編寫程序手動處理上面所提到的讀取和處理的順序，你必須記錄每個文件讀取和處理的狀態(tài)。相反，你可以啟動兩個線程，每 個線程處理一個文件的讀取和操作。線程會在等待磁盤讀取文件的過程中被阻塞。在等待的時候，其他的線程能夠使用CPU去處理已經(jīng)讀取完的文件。其結(jié)果就 是，磁盤總是在繁忙地讀取不同的文件到內(nèi)存中。這會帶來磁盤和CPU利用率的提升。而且每個線程只需要記錄一個文件，因此這種方式也很容易編程實現(xiàn)。
程序響應(yīng)更快
將一個單線程應(yīng)用程序變成多線程應(yīng)用程序的另一個常見的目的是實現(xiàn)一個響應(yīng)更快的應(yīng)用程序。設(shè)想一個服務(wù)器應(yīng)用，它在某一個端口監(jiān)聽進(jìn)來的請求。當(dāng)一個請求到來時，它去處理這個請求，然后再返回去監(jiān)聽。
服務(wù)器的流程如下所述：
- while(server is active){
- listen for request
- process request
- }
如果一個請求需要占用大量的時間來處理，在這段時間內(nèi)新的客戶端就無法發(fā)送請求給服務(wù)端。只有服務(wù)器在監(jiān)聽的時候，請求才能被接收。另一種設(shè)計是，監(jiān)聽線 程把請求傳遞給工作者線程(worker thread)，然后立刻返回去監(jiān)聽。而工作者線程則能夠處理這個請求并發(fā)送一個回復(fù)給客戶端。這種設(shè)計如下所述：
- while(server is active){
- listen for request
- hand request to worker thread
- }
這種方式，服務(wù)端線程迅速地返回去監(jiān)聽。因此，更多的客戶端能夠發(fā)送請求給服務(wù)端。這個服務(wù)也變得響應(yīng)更快。
桌面應(yīng)用也是同樣如此。如果你點擊一個按鈕開始運行一個耗時的任務(wù)，這個線程既要執(zhí)行任務(wù)又要更新窗口和按鈕，那么在任務(wù)執(zhí)行的過程中，這個應(yīng)用程 序看起來好像沒有反應(yīng)一樣。相反，任務(wù)可以傳遞給工作者線程（word thread)。當(dāng)工作者線程在繁忙地處理任務(wù)的時候，窗口線程可以自由地響應(yīng)其他用戶的請求。當(dāng)工作者線程完成任務(wù)的時候，它發(fā)送信號給窗口線程。窗口 線程便可以更新應(yīng)用程序窗口，并顯示任務(wù)的結(jié)果。對用戶而言，這種具有工作者線程設(shè)計的程序顯得響應(yīng)速度更快。
從一個單線程的應(yīng)用到一個多線程的應(yīng)用并不僅僅帶來好處，它也會有一些代價。不要僅僅為了使用多線程而使用多線程。而應(yīng)該明確在使用多線程時能多來的好處比所付出的代價大的時候，才使用多線程。如果存在疑問，應(yīng)該嘗試測量一下應(yīng)用程序的性能和響應(yīng)能力，而不只是猜測。
設(shè)計更復(fù)雜
雖然有一些多線程應(yīng)用程序比單線程的應(yīng)用程序要簡單，但其他的一般都更復(fù)雜。在多線程訪問共享數(shù)據(jù)的時候，這部分代碼需要特別的注意。線程之間的交互往往非常復(fù)雜。不正確的線程同步產(chǎn)生的錯誤非常難以被發(fā)現(xiàn)，并且重現(xiàn)以修復(fù)。
上下文切換的開銷
當(dāng)CPU從執(zhí)行一個線程切換到執(zhí)行另外一個線程的時候，它需要先存儲當(dāng)前線程的本地的數(shù)據(jù)，程序指針等，然后載入另一個線程的本地數(shù)據(jù)，程序指針 等，***才開始執(zhí)行。這種切換稱為“上下文切換”(“context switch”)。CPU會在一個上下文中執(zhí)行一個線程，然后切換到另外一個上下文中執(zhí)行另外一個線程。
上下文切換并不廉價。如果沒有必要，應(yīng)該減少上下文切換的發(fā)生。
增加資源消耗
線程在運行的時候需要從計算機(jī)里面得到一些資源。除了CPU，線程還需要一些內(nèi)存來維持它本地的堆棧。它也需要占用操作系統(tǒng)中一些資源來管理線程。 我們可以嘗試編寫一個程序，讓它創(chuàng)建100個線程，這些線程什么事情都不做，只是在等待，然后看看這個程序在運行的時候占用了多少內(nèi)存。
原文鏈接：http://tutorials.jenkov.com/java-concurrency/benefits.html
