這兩天在測試乙個程式的時候發現，一旦壓力達到一定程度，程式立即就會崩潰，報的錯誤幾乎都在new的時候沒有記憶體了，一開始以為確實是因為記憶體分配的問題，後來在程式執行過程中用top觀察，發現記憶體使用很低，因此可以確認不應該是瞬間記憶體使用完造成的。因此認真看了一下core dump的地方，發現幾乎都是在自己寫的乙個智慧型指標分配記憶體那裡出的問題。於是仔細思考了一下，發現是因為智慧型指標的引用計數沒有加鎖導致的。
一開始以為我所使用的智慧型指標即使是在非同步情況下使用的，但是基本上只能同一時間在乙個執行緒持有，但是事實情況卻並非如此
如下**
void func()
shared_ptr a;
async_call(a);
首先有乙個智慧型指標，接下來，這個智慧型指標被丟給了非同步程式，因此這個時候其實已經有兩個執行緒同時持有這個智慧型指標了，因為這個函式還未退出，當前執行緒還擁有臨時變數a。一般低壓情況下，這兩句很快就執行完了，不會出問題，但是高壓情況下，這個函式先執行完，還是非同步程式先執行完就不一定了（或者說是因為高壓情況樣本變多了）
結論：多執行緒非同步程式的衝突問題比一般性多執行緒程式更隱蔽，很難查詢，要仔細思考。
synchronized在多執行緒情況下的使用
不同業務場景，有時會碰到大量資料的情況，在請求完資料後會通過model對映到對應的陣列或者字典中，從而對陣列進行操作，而多個執行緒同時對同一陣列進行取捨時內容就會出錯，為了避免這種情況可以使用 synchronized關鍵字來宣告來建立乙個互斥鎖，保證此時沒有其它執行緒對鎖定物件進行修改 synch...
多執行緒的利器 C 智慧型指標
c 給程式人員提供很多的權力，自然也就要完成很多的任務。最典型的就是c 的記憶體沒有自動 機制，所以要求程式設計師每次new delete，不匹配則容易造成記憶體洩漏。因此c 引入智慧型指標，是raii 利用的就是c 構造的物件最終會被銷毀的原則。raii的做法是使用乙個物件，在其構造時獲取對應的資...
java swing多執行緒處理情況下UI假死的解決
背景 問題 解決方案 swingapi是非執行緒安全的，也就是說不能在任意地方呼叫，它應該只在edt中呼叫。swing的執行緒安全靠事件佇列和edt來保障。eventqueue的派發機制由單獨的乙個執行緒管理，這個執行緒稱為事件派發執行緒 edt 和其他很多桌面api一樣，swing將gui請求放入...