標籤:java 案頭 佔用 記錄 處理 帶來 lis code 發送
以下內容轉自http://ifeve.com/benefits/:
儘管面臨很多挑戰,多線程有一些優點使得它一直被使用。這些優點是:
- 資源使用率更好
- 程式設計在某些情況下更簡單
- 程式響應更快
資源使用率更好
想象一下,一個應用程式需要從本地檔案系統中讀取和處理檔案的情景。比方說,從磁碟讀取一個檔案需要5秒,處理一個檔案需要2秒。處理兩個檔案則需要:
5秒讀取檔案A2秒處理檔案A5秒讀取檔案B2秒處理檔案B---------------------總共需要14秒
從磁碟中讀取檔案的時候,大部分的CPU時間用於等待磁碟去讀取資料。在這段時間裡,CPU非常的空閑。它可以做一些別的事情。通過改變操作的順序,就能夠更好的使用CPU資源。看下面的順序:
5秒讀取檔案A5秒讀取檔案B + 2秒處理檔案A2秒處理檔案B---------------------總共需要12秒
CPU等待第一個檔案被讀取完。然後開始讀取第二個檔案。當第二檔案在被讀取的時候,CPU會去處理第一個檔案。記住,在等待磁碟讀取檔案的時候,CPU大部分時間是閒置。
總的說來,CPU能夠在等待IO的時候做一些其他的事情。這個不一定就是磁碟IO。它也可以是網路的IO,或者使用者輸入。通常情況下,網路和磁碟的IO比CPU和記憶體的IO慢的多。
程式設計更簡單
在單線程應用程式中,如果你想編寫程式手動處理上面所提到的讀取和處理的順序,你必須記錄每個檔案讀取和處理的狀態。相反,你可以啟動兩個線程,每個線程處理一個檔案的讀取和操作。線程會在等待磁碟讀取檔案的過程中被阻塞。在等待的時候,其他的線程能夠使用CPU去處理已經讀取完的檔案。其結果就是,磁碟總是在繁忙地讀取不同的檔案到記憶體中。這會帶來磁碟和CPU利用率的提升。而且每個線程只需要記錄一個檔案,因此這種方式也很容易編程實現。
程式響應更快
將一個單線程應用程式變成多線程應用程式的另一個常見的目的是實現一個響應更快的應用程式。設想一個伺服器應用,它在某一個連接埠監聽進來的請求。當一個請求到來時,它去處理這個請求,然後再返回去監聽。
伺服器的流程如下所述:
while(server is active){ listen for request process request}
如果一個請求需要佔用大量的時間來處理,在這段時間內新的用戶端就無法發送請求給服務端。只有伺服器在監聽的時候,請求才能被接收。另一種設計是,監聽線程把請求傳遞給工作者線程(worker thread),然後立刻返回去監聽。而工作者線程則能夠處理這個請求並發送一個回複給用戶端。這種設計如下所述:
while(server is active){ listen for request hand request to worker thread}
這種方式,服務端線程迅速地返回去監聽。因此,更多的用戶端能夠發送請求給服務端。這個服務也變得響應更快。
案頭應用也是同樣如此。如果你點擊一個按鈕開始運行一個耗時的任務,這個線程既要執行任務又要更新視窗和按鈕,那麼在任務執行的過程中,這個應用程式看起來好像沒有反應一樣。相反,任務可以傳遞給工作者線程(word thread)。當工作者線程在繁忙地處理任務的時候,視窗線程可以自由地響應其他使用者的請求。當工作者線程完成任務的時候,它發送訊號給視窗線程。視窗線程便可以更新應用程式視窗,並顯示任務的結果。對使用者而言,這種具有工作者線程設計的程式顯得響應速度更快。
Java多線程的優點