盡管面臨很多挑戰，多線程有一些優點使得它一直被使用。這些優點是：
資源使用率更好
程式設計在某些情況下更簡單
程式響應更快
想象一下，一個應用程式需要從本地檔案系統中讀取和處理檔案的情景。比方說，從磁盤讀取一個檔案需要5秒，處理一個檔案需要2秒。處理兩個檔案則需要：
從磁盤中讀取檔案的時候，大部分的cpu時間用于等待磁盤去讀取資料。在這段時間裡，cpu非常的空閑。它可以做一些别的事情。通過改變操作的順序，就能夠更好的使用cpu資源。看下面的順序：
cpu等待第一個檔案被讀取完。然後開始讀取第二個檔案。當第二檔案在被讀取的時候，cpu會去處理第一個檔案。記住，在等待磁盤讀取檔案的時候，cpu大部分時間是空閑的。
總的說來，cpu能夠在等待io的時候做一些其他的事情。這個不一定就是磁盤io。它也可以是網絡的io，或者使用者輸入。通常情況下，網絡和磁盤的io比cpu和記憶體的io慢的多。
在單線程應用程式中，如果你想編寫程式手動處理上面所提到的讀取和處理的順序，你必須記錄每個檔案讀取和處理的狀态。相反，你可以啟動兩個線程，每
個線程處理一個檔案的讀取和操作。線程會在等待磁盤讀取檔案的過程中被阻塞。在等待的時候，其他的線程能夠使用cpu去處理已經讀取完的檔案。其結果就
是，磁盤總是在繁忙地讀取不同的檔案到記憶體中。這會帶來磁盤和cpu使用率的提升。而且每個線程隻需要記錄一個檔案，是以這種方式也很容易程式設計實作。
伺服器的流程如下所述：
如果一個請求需要占用大量的時間來處理，在這段時間内新的用戶端就無法發送請求給服務端。隻有伺服器在監聽的時候，請求才能被接收。另一種設計是，
監聽線程把請求傳遞給工作者線程(worker
thread)，然後立刻傳回去監聽。而工作者線程則能夠處理這個請求并發送一個回複給用戶端。這種設計如下所述：
這種方式，服務端線程迅速地傳回去監聽。是以，更多的用戶端能夠發送請求給服務端。這個服務也變得響應更快。
桌面應用也是同樣如此。如果你點選一個按鈕開始運作一個耗時的任務，這個線程既要執行任務又要更新視窗和按鈕，那麼在任務執行的過程中，這個應用程
序看起來好像沒有反應一樣。相反，任務可以傳遞給工作者線程（word
thread)。當工作者線程在繁忙地處理任務的時候，視窗線程可以自由地響應其他使用者的請求。當工作者線程完成任務的時候，它發送信号給視窗線程。視窗
線程便可以更新應用程式視窗，并顯示任務的結果。對使用者而言，這種具有工作者線程設計的程式顯得響應速度更快。