首先說(shuō)明需求點(diǎn)：依次發(fā)起請(qǐng)求op1泛粹、op2、op3肮疗，要求op1成功后再發(fā)起op2晶姊，若失敗，則后續(xù)op2伪货、op3不執(zhí)行们衙，回調(diào)失敗結(jié)果；同理碱呼，若op1成功后蒙挑，發(fā)起op2請(qǐng)求失敗，則op3不執(zhí)行愚臀，回調(diào)失敗結(jié)果忆蚀。
最終參考代碼：Demo
先看一段網(wǎng)絡(luò)常見(jiàn)示例：
從結(jié)果上看，滿足請(qǐng)求的順序執(zhí)行姑裂，但是實(shí)際使用后蜓谋，情況變得不一樣了：
從結(jié)果日志上看，op2并未等待op1請(qǐng)求結(jié)束后再發(fā)起炭分，這就導(dǎo)致了無(wú)法根據(jù)op1的請(qǐng)求結(jié)果來(lái)判斷op2是否能夠發(fā)起桃焕，這就無(wú)法實(shí)現(xiàn)文章開(kāi)始提到的效果。
修改方案：使用信號(hào)量來(lái)控制線程的執(zhí)行：
從請(qǐng)求結(jié)果看捧毛，這個(gè)已經(jīng)滿足了使用需求观堂，但是這并沒(méi)有結(jié)束，出現(xiàn)的主線程死鎖呀忧。
從結(jié)果可以看到师痕，因?yàn)閞equestAction的回調(diào)是在主線程中執(zhí)行的，而此時(shí)主線程又在等待回調(diào)后的信號(hào)量以繼續(xù)執(zhí)行而账，從而形成了死鎖胰坟，更有甚者，如果UI上存在動(dòng)畫(huà)或者loading的泞辐，此時(shí)也會(huì)卡死笔横。
那么這種情況下改如何處理竞滓？
解決方法：
避免將dispatch_semaphore_wait() 放置于主線程中，而是放置到對(duì)應(yīng)的子線程中進(jìn)行吹缔，最終修改后的代碼：
總結(jié)：原本不是復(fù)雜的場(chǎng)景商佑，但是因?yàn)榧尤肓司€程的操作而容易出現(xiàn)錯(cuò)誤，這個(gè)方案只是在遇到這個(gè)小問(wèn)題的記錄厢塘，如果您有更好的辦法能夠?qū)崿F(xiàn)這個(gè)場(chǎng)景茶没，歡迎您留言！
