1）首先我們了解當執行垃圾**的時候，會導致程序暫停，從而使我們的程式卡死；程序長時間暫停，又會導致大量的請求積壓等待處理，垃圾**剛剛結束，更多的請求立刻湧進來，迅速佔滿記憶體，再次被迫執行垃圾**，進入了乙個惡性迴圈。如果垃圾**的速度跟不上建立物件的速度，還可能會產生記憶體溢位的現象。
所以說往往在高併發的情況下更容易發生oom。
2)除此之外垃圾**演算法產生記憶體碎片也會產生影響。記憶體碎片在gc執行標記-清除演算法時產生，當完成物件的**後，會需要再整理記憶體碎片，將不連續的空閒記憶體移動到一起，以便空出足夠的連續記憶體空間供後續使用。和垃圾**演算法一樣，記憶體碎片整理也有很多非常複雜的實現方法，但由於整理過程中需要移動記憶體中的資料，也都不可避免地需要暫停程序。
記憶體碎片舉例來說：記憶體中有10個位元組，初始化了5個short型別的物件，每個short佔2位元組，程式執行一段時間後，有兩個short使用後被**了，此時有想新建乙個int，這時可能是不成功的，
因為**掉的兩個short可能不是連續的，但是建立int必須是連續的4個位元組，所以就產生了占用空間的記憶體碎片。
1）盡量少的建立物件，優化業務處理邏輯，特別是占用記憶體大的物件。例如：我們可以把收到請求的 request 物件在業務流程中一直傳遞下去，而不是每執行乙個步驟，就建立乙個內容和 request 物件差不多的新物件。
2）考慮自行**並重用物件。建立乙個物件池。收到請求後，在物件池內申請乙個物件，使用完後再放回到物件池中，這樣就可以反覆地重用這些物件，非常有效地避免頻繁觸發垃圾**。
3）盡可能使用記憶體大的伺服器
高併發下搶購
了解高併發以及怎麼處理後，測試一下專案中下單的 邏輯很簡單，goods表中stock設定為unsigned。剛開始你可能會覺得這樣會出現超單的情況，但是測試後，沒有出現超單的情況。看似沒有問題，但是看過日誌發現問題還挺多的。這之前請看下這篇文章裡面有處理高併發下單的情況。goods id num g...
高併發下的HashMap
1.hashmap在插入元素過多的時候需要進行resize，resize的條件是 hashmap.size capacity loadfactor。2.hashmap的resize包含擴容和rehash兩個步驟，rehash在併發的情況下可能會形成鍊錶環 hashmap進行儲存時，假設size超過當...
高併發下的MySQL
對於遊戲來說，db存在大量的insert update 可謂玩家的很多動作都會與db溝通。本文暫時忽略os 中的 io利用率，網絡卡流量，cpu變化情況，介紹如何檢視mysql部分引數 檢視每秒事務數 show global status like com commit show global st...