近日加利福尼亞大學同學來訪問，寫的程式core了，幫忙除錯好半天。。紀錄一下奇葩的bug。
起始bug的原因挺容易想到的，而且也是寫**的時候應該注意的地方。應為vector記憶體動態增長的原因，vector中的元素的指標和引用都是不可靠的。當然這一點在單執行緒時基本沒有問題。但是多執行緒就跪了。
多執行緒傳給執行緒函式乙個vector中元素的指標，而主線程會改這個vector，導致執行緒函式需要用vector中元素時，這塊記憶體已經不是vector的了，動態增長使得vector開了新空間，複製資料，釋放舊空間。然後就報了錯。。
下面是簡化版的**，原始**很大，導致沒能一眼看出來這個問題。
g++ -std=c++11 a.cpp -lpthread
#include #include #include using namespace std;
struct node
node(int a = -1): a(a)
node(const node &t): a(t.a)
int a = 0;
};void dosomething(node *n)
int main(int argc, char* argv)
for(thread &x: thrs)
return 0;
}
python 多執行緒和協程配合使用
有一批key已經寫入到3個txt檔案中，每乙個txt檔案有30萬行記錄。現在需要讀取這些txt檔案，判斷key是否在資料倉儲中。redis或者mysql 為空的記錄，需要寫入到日誌檔案中！1.使用多執行緒技術，每乙個執行緒讀取乙個txt檔案 2.使用協程技術，批量讀取txt檔案記錄。比如一次性讀取 ...
如何尋找多執行緒程式的bug
3.縮小錯誤範圍 4.總結 確保程式以單執行緒方式執行時沒有錯誤。這是找bug的基礎。可能原因1 對mutex使用lock後忘記解鎖 例如 沒有對每一種可能的情況進行unlock。mutex m1 thread1 m1.unlock return 可能原因2 發生死鎖 例如 使用普通鎖對遞迴程式加鎖...
pagehelper 4 x 多執行緒 bug
當查詢同一sql，在高併發情況下 或出現 4.1.x nullpointerexception或者 無法處理該型別 class com.github.pagehelper.sqlsource.pagedynamicsqlsource 的sqlsource 分析 sqlutils 處private p...