同事有段**執行時間過長，需要進行優化,
hashmultimapmap = ...;for (400w*96)
剛開始以為是計算過程docompute效率低造成的，所以想各種方法優化計算，提前計算、多執行緒、。。。。等等等等，最終如下
// 多執行緒計算....
// 計算結果放入佇列
concurrentlinkedqueue queue = ...;
queue.offer(docompute());
.....
// 佇列資料放入快取
hashmultimapmap = ...;
map.put(int,queue.poll());
但還是不行，跑跑就cpu 100%，找不到什麼原因，直到快下班時突然想到是不是記憶體引起的，然後放到伺服器上一執行，-xms20g -xmx20g，沒有任何問題。
分析了下，找到了原因（純分析，下週列印下jvm日誌驗證下）：
對於hashmultimap和concurrentlinkedqueue來說，因為是迴圈單個放入快取，所以jvm是逐漸到達最大堆疊的，而一旦jvm發現記憶體不夠用，就啟動gc過程，但gc結束發現還是不夠用（因為沒有例項需要**）就又啟動gc，。。。，迴圈往復，業務**不能跑，cpu全被gc佔滿，而且也不拋記憶體溢位的異常。
問題定位過程曲折：先入為主容易鑽死胡同、好為人師的人真nm多、要相信jvm的計算生產水平。。。。
jvm初始分配的記憶體預設是物理記憶體的1/64,預設(minheapfreeratio引數可以調整)空餘堆記憶體小於40%時，jvm就會增大堆直到-xmx的最大限制,-xx:minheapfreeratio=40.
jvm最大分配的記憶體預設是物理記憶體的1/4,預設(maxheapfreeratio引數可以調整)空餘堆記憶體大於70%時，jvm會減少堆直到 -xms的最小限制,-xx:maxheapfreeratio=70.
通過free檢視到的空閒記憶體不能完全分配到jvm，能分配的比例應該和jvm廠商、os有關。
一次Mycat聚合排序問題定位
mycat mysql實現分庫分表 功能需要遍歷表，資料量有點大，於是通過id排序分頁查詢。在實現過程中發現有部分id查不出來，功能排期只能被迫延後。在確認了 和sql語句沒有問題後，目光轉至mycat與mysql排序邏輯上來。確認了mycat與mysql排序邏輯有問題，至少mycat與mysql排...
沒有pdb也要定位問題 一次注入崩潰的定位過程
最近遇到乙個注入過程中崩潰的問題，花了比較長的時間定位，寫下來記錄一下 一 背景 我寫了乙個程序s，s程序會執行時會監控程序中是否有i程序在執行，如果i程序運動的話，s程序就注入乙個my.dll到i程序中，並在i程序中執行乙個myfunc的函式 如下圖 我寫完程式後，執行測試，功能是沒有錯誤的，一切...
記一次mysql不走索引的問題定位
問題 sql為三表關聯，關聯的字段上都加上了唯一索引，查詢時卻不走索引導致sql執行超時。檢視explain都走的all全表掃瞄。基於上述定位 為什麼沒走索引呢？進行多表關聯查詢時，要滿足 1 表關聯使用的條件欄位中字段的長度是否是一致的 2 兩表關聯使用的條件欄位中字段的編碼是否是一致的 以上兩個...