c++ 在遍歷map的時(shí)候死循環(huán)？

Club * ClubMgr::GetClub(clubid_t nClubId) const
{
    for (std::map<userid_t, std::map<clubid_t, Club* > >::const_iterator it1 = m_hashClubs.begin(); it1 != m_hashClubs.end(); ++it1)
    {
        std::map<clubid_t, Club* >::const_iterator it2 = it1->second.find(nClubId);
        
        if (it2 != it1->second.end())
        {
            return it2->second;
        }
    }
    return NULL;
}

死循環(huán)的代碼如上，每次都是上線跑了一天多之后死循環(huán)的，cpu100%，死活找不到原因，恕不方便貼上全部代碼。只想請(qǐng)問各位牛人，在map處死循環(huán)一般都會(huì)有哪些情況？

ps:哦對(duì)，忘了補(bǔ)充，業(yè)務(wù)部分是單線程處理的。

回答

編輯回答

解夏

cpu在做密集的計(jì)算才會(huì)導(dǎo)致100%，最常見的例子就執(zhí)行的循環(huán)次數(shù)過多，要不就是那種死循環(huán)。
回到你的代碼上來(lái)，你這個(gè)函數(shù)沒有邏輯問題，但是存在性能問題，你的外層map元素個(gè)數(shù)到達(dá)10萬(wàn)乃至百萬(wàn)時(shí)，循環(huán)需要執(zhí)行很多次才能退出。
優(yōu)化的方式：要嘛增加修改查詢條件，加一個(gè)userid，查詢只需要做兩次map的find操作；要嘛修改存數(shù)據(jù)結(jié)構(gòu)提高查詢效率。

2017年1月19日 17:46

編輯回答

咕嚕嚕

linux會(huì)有死掉的原因，看message重有沒有oom killer的相關(guān)打印。如果是死循環(huán)，只能通過對(duì)比svn等排查可能死循環(huán)的地方。

如果是段錯(cuò)誤或者其他問題死機(jī)，linux內(nèi)核會(huì)有相應(yīng)的捕獲 coredump或者crash（vmcore信息等），單純的這么看代碼我覺得很難找到原因，必須借助相應(yīng)的工具。

有死循環(huán)的話linux在/var/log/message中會(huì)有記錄，你看下message，oom kiiler會(huì)在內(nèi)存緊張的時(shí)候，會(huì)依次kill內(nèi)存占用較高的進(jìn)程，里面會(huì)記錄一些如pid，process name，cpu mask，trace等信息，通過監(jiān)控可以發(fā)現(xiàn)類似問題。

2017年4月12日 17:29

編輯回答

終相守

userid_t 和 clubid_t operator<是如何定義的?

另外你的算法復(fù)雜度可能有問題

2018年2月24日 02:00

編輯回答

初心

代碼，沒啥問題，一般像這種問題，不要自己手動(dòng)寫循環(huán)遍歷，盡量使用 #include <algorithm> 里面的算法方法，比如 find_if()。
還有進(jìn)入這個(gè)函數(shù)之前，打印下 m_hashClubs.size(), 確認(rèn)下是否size過大，然后查看size過大的原因。
還有很少有人會(huì)遍歷map吧，map就是為了快速索引啊，如果還要遍歷，那要map干啥？修改設(shè)計(jì)吧。

2017年4月11日 15:46

編輯回答