???先讓我們來看個例子：

????這段代碼看似沒問題，其實(shí)犯了一個很嚴(yán)重的錯誤，也是今天開發(fā)過程中出現(xiàn)的問題。

????首先，thread創(chuàng)建了一個線程，線程在獲得到鎖后，調(diào)用條件變量的wait方法對線程進(jìn)行阻塞，同時釋放鎖。于是乎，系統(tǒng)調(diào)度進(jìn)行上下文切換至main函數(shù)的主線程，這可能是我們所想的“理想調(diào)度順序”。

????但是，換個思維去想，操作系統(tǒng)也可能先調(diào)度main函數(shù)的主線程，等到t.join()被阻塞后，再調(diào)度t線程，這樣就會出現(xiàn)一個問題：沒有任何一個線程被阻塞在條件變量上時，就發(fā)送喚醒線程的通知了。這樣會導(dǎo)致咱們的t線程會一直阻塞，永遠(yuǎn)無法被喚醒（因?yàn)閱拘淹ㄖ缭绲木捅话l(fā)送出去了........）。

????我們需要改進(jìn)以下代碼：

????通過while避免被notify_one提前喚醒后，程序被阻塞在一個永遠(yuǎn)不可能被喚醒的線程上，為什么不用if來作判斷？就不多說了，就是用來應(yīng)付類似多個消費(fèi)者的情況。