如果理解的不好，歡迎評論指出錯誤
cpu的單核一次可執行一個程式，多個程式切換執行，多核則可同時執行多個程式
cpu的核就像一個工廠，程式就像工廠中的車間（提供工人的工作條件，環境+庫+依賴，即執行時的環境），執行緒就像車間中的工人，負責工作具體的任務；
即執行緒是具體做事的基本單位，程式是能呼叫各種資源的基本單位；
或者再舉個例子說明程式和執行緒：
程式就像技術部負責人，他平時只負責管理下面的技術員，分配任務，管理進度，提供額外技術支援； 技術員是幹活的人，但是負責人也是可以幹活的，即程式也是可以做幹活的人；
比如一個單程式，就像一個單人獨立工作室，他什麼都得幹；和其它的單人獨立工作室是沒有關係的，不能做資源共享；（可以依託中間人資源轉交，如redis可以使多個程式資源共享）
單程式多執行緒，就像一個獨立團隊，帶頭人就是這個主程式，其他工作人員就是多個的執行緒，這個團隊裡面，每個人都可以共享團隊的資源（即單程式裡面的多執行緒是可以共享記憶體資料的）
程式，執行緒？
單執行緒和多執行緒並沒有高低，各有優劣，適應的場景不同，或者說實現的機制不同
單程式：
比如我們有一個餐廳（程式），準備好了吃飯，做飯等的環境（執行時環境）；這個餐廳中的資源，該餐廳中的每個服務員（執行緒）都是可以共享的（記憶體資料可共享）
多程式：
我們有多個連鎖的餐廳；但是彼此之間並無資源往來（程式之間不共享記憶體資料）；只是最終同屬於一個老闆（程式檔案或者說主程式，父程式），老闆不負責各個餐廳具體的事情，只負責
管理每個餐廳的狀態；
多執行緒，單執行緒：
我們其中有一家餐廳（一個程式），配了10個服務員（多執行緒），每來一個客人，就讓一個服務員單獨去服務這個客人，直到客人吃完
離開後，這個服務員才空閒下來，因此我們的餐廳最高的併發就是10個客人同時進來吃飯；多餘的客人則需要排隊等待服務員空閒下來（執行緒阻塞）
此時我們發現，進來一個客人（連線請求），就讓一個服務員單獨服務的開銷太大，入不敷出，我們想假如只請一個服務員，一個客人進來，去服務客人點菜；
點完菜後，繼續服務下一個客人的點菜，燒菜交給廚師（另一個服務程式，如連線mysql，redis，IO操作）；等待燒菜完畢（如果不是非同步，這裡同樣需要等待），我們的服務員再去把菜端給客人；完成這次服務後，繼續服務下一個；
此時的好處是，服務員一直處於工作狀態，也不會阻塞了，同時開銷也小了； 越來越賺錢了，很開心；
但是缺點是，假如這個服務員奔潰了，撂挑子不幹了，則導致整個餐廳也無法營業了（程式也奔潰了，即所有的請求都無法響應了）；
高併發的衝擊：
某一天，我們想搞個促銷打折活動，回饋客人，同時拉收一波；發了很多傳單，吸引了大量客人，規定明天早上8點活動開啟；
此時到了第二天8點，同時100人進店點菜，但是此時我們只有一個服務員，儘管他只負責點菜，但是無賴客人太多，實在服務不過來，結果不過時，服務員奔潰了，不幹了；
此時大量的客人由於多長時間的等待和服務員無法回應，很多客人都罵罵咧咧的離開了餐廳；
之後，老闆想，這樣不行啊，舉辦一次活動，本來應該是皆大歡喜，咋還讓我餐廳名譽變差了；營業額也差了；得想辦法解決啊；
於是老闆又想，不就是一次活動客人突然增多嗎，我如果加服務員應該能解決；於是老闆又加到了之前得10個服務員；
但是下一次活動，依然有問題，一次接納的客人雖然變多了，但是同時100人進來，我們的餐廳座位只有20個啊（系統限制），
於是老闆動力動腦筋，改了改餐廳佈局（修改了系統的某些限制引數），多塞了8個座位，但此時依舊無法應付一次幾百人的湧入；怎麼辦?
於是老闆痛定思痛，下決定，再多開一個4~5個餐廳（多程式）， 此時每個配10個服務員，即此時，我們搞一次活動，最高併發能達到100~150，過了幾天，
老闆發現，雖然這樣能解決問題，但是開銷很大啊，5個餐廳總共得配50個服務員，這也是一筆大開銷，而且關鍵是高併發的時間並不多啊，
於是老闆再次改善思路，每個餐廳，只配一個服務員（多程式，單執行緒）；
後面，生意越來越好了，活動越來越多，越大，一次活動人數越來越多了，但是新的問題又來了，每個店子的一個服務員依舊忙不過來，經常撂挑子不幹了，於是又加了服務員（多程式，多執行緒）；
但是此時，依然有新的問題（併發帶來的資料問題），後續。。。。。。本作品採用《CC 協議》，轉載必須註明作者和本文連結