為什么多線程編程這么難呢？你有沒有想過這個問題。

一邊又一邊。

周末了，美美地睡個懶覺起來做早飯，做飯其實很簡單，照著菜譜一步步來就行，沒什么難度。

在你做飯時突然手機鈴聲大作，原來是線上出現了故障，其他同事正在排查，需要你協助一下，一邊做飯一邊打電話應該也不算太難，你可以的。

正當你一邊排查問題一邊做飯時本來約好明天來維修空調的師傅因為協調不開提前一天來了，你不得不一邊做飯一邊排查問題一邊告訴維修師傅哪個空調壞了、問題是啥。怎么樣，是不是開始應付不過來了？

這還不算啥，就在這時你約好的同學也到了，一邊接待同學一邊指揮著維修師傅一邊排查問題一邊做早飯，你是不是已經開始瘋了。

當多線程遇到共享。

看到了吧，"多線程"絕不是在編程這個層面很難，多線程本身就很難。

尤其是當多線程遇上共享數據時更是難上加難，對人類來說，同時做兩件互不干擾的事情還是有可能的，一邊寫代碼一邊聽歌就是，但你可以試試讓兩個任務共享聽的能力，同時聽兩首歌；或者讓兩個任務共享大腦的思考能力，一邊解bug一邊刷算法，你還能輕松加愉快嗎？

如果你試圖推演多線程訪問共享數據那么你的腦海很可能就像剛才提到的“一邊接待同學一邊指揮著維修師傅一邊排查問題一邊做早飯”，一團糟。。人類的大腦似乎天生就不是很擅長(天才不在此討論范圍)，更不用說因解決共享數據而帶來的死鎖等問題。

遇事不決量子力學。

你的多線程代碼可能在99.99%的情況下工作正常，但在小概率下就是會有問題，這都不算啥，問題是你該怎么debug呢？

你該怎么調試一個可能只有萬分之一出錯的程序呢？而且更棒的是，就像測不準原理一樣，測量這操作本身竟然不可避免的攪擾了被測量粒子的運動狀態，因此產生不確定性。

當你試圖用調試器attach上去又或者加一些log時這本身也會改變多線程程序的行為，或者問題就此不再產生，又或者概率變為了十萬分之一，從這個角度看多線程和量子力學有異曲同工之妙。

這里的根源在于“可能性的組合爆炸”問題。

由于操作系統的調度、系統中斷再加上程序員添加的鎖等原因，我們的程序(線程)總是走走停停，這就導致在程序的“執行空間”上有太多可能，試圖去測試每一種可能幾乎是不可能的事情，而我們添加一些log等本身就給本來已經爆炸的組合新增一個維度，導致有的問題非常難復現。

盡管我們的調試工具IDE等越來越高級，但依然解決不了多線程本身的問題。

性能是個問題。

如果你不關心程序性能的話，大可以加上一個很豪邁的鎖，但鎖也不應該加的過分放飛自我，你能想象為了讓北京的某個同學買一本書電商要把整個華北地區的庫存鎖住嗎？

如果你關心性能的話那么鎖的粒度會是個問題，同時在硬件級別你可能需要了解多核cache一致性以及memory ordering等，這些都不是那么容易理解，更不用提無鎖編程，lock-free等等。