其實在平時的開發中，很多程序員都不會去寫線程，為啥？因為麻煩，其次是用到的地方并不多，除非逼不得已，大家都不會去寫，畢竟寫一天代碼，拿一天工資，是吧？

麻煩歸麻煩，但是多線程的優點不得不說：

1. 資源利用率提升，程序處理效率提高

　　打個比方：我們做上傳圖片的時候，在上傳成功后往往會進行圖片的處理，原圖保存后，會再生成一張小圖以作為一些應用的預覽圖，那么原圖的處理就需要程序去讀取再處理，假設讀取需要花費1秒，處理需要2秒，現在有3張大圖，所需要耗費的時間就是（1+2）X3=9秒，根據圖片的不同，那么單位時間會更多，總計時間就會更久。

那么如果把程序設計更好的話，那就是在讀取文件的時候同時處理上一個文件，這樣就可以盡可能的縮短時間，減少客戶端的響應，同時也提升了CPU的使用率。

如果還不能理解的話那就再舉個例子，我朋友公司是專為某銀行處理數據同步的問題，每天凌晨銀行那邊會有幾十萬條數據發送過來進行處理，項目本身就是個坑，幾百萬條數據接收后直接去處理了，每次運行大多都要耗費2.5個小時，時間實在太久，如果哪天有幾億數據是不是要跑幾十個小時了？那么就可以用多線程，切割這個數據，利用不同的線程來處理，最后把時間縮短到了半小時左右

?

2. 代碼會相對簡單

　　如果利用單線程去處理文件，那么我們就得標記每次處理的各個節點的狀態；而如果使用多線程的話處理完一個扔一個，可以簡便不少

?

3.?軟件運行速度提升

　　就像之前所說的魔獸爭霸那樣，如果采礦伐木打獵都是由一個農民工來做的話，那他會累死，而如果分配3個農民工來做的話，那么時間大大縮短；同理，軟件程序在處理文件的時候也是一個道理。

也就是說，往常我們監聽的是用戶請求，現在我們把用戶請求塞給線程，我們去監聽線程就可以了。

舉一個不恰當的例子，我們在用eclipse的時候經常會出現這樣的情況，一個progress被另一個卡住，下一個必須等待上一個執行完畢后再執行，完畢后我們方可編寫代碼，這種情況尤其出現在maven編譯或者下載jar包的時候。

假如說，eclipse是同時進行任務處理的，那么每個任務處理完后響應一個狀態，然后再提示給用戶，可以彈出顯示，或者在底部狀態來加個有顏色的提醒，都可以。（如果理解成消息隊列的處理方式也可以，在云計算業務中利用消息隊列處理各種服務器請求也是類似道理）

那么，這樣的程序設計對于軟件自身來說響應速度就更快了，用戶的體驗也就更高了~

?

?