用long型別讓我出了次生產事故，寫程式碼還是要小心點
阿新 • • 發佈：2020-04-27
昨天發現線上試跑期的一個程式掛了，平時都跑的好好的，查了下日誌是因為昨天運營跑了一家美妝top級淘品牌店，會員量近千萬，一下子就把128G的記憶體給爆了，當時並行跑了二個任務，沒轍先速寫一段程式碼限流，後面再做進一步優化。
# 一： 背景
## 1. 背景介紹
因為是自己寫的程式碼，所以我知道問題出現在哪裡，如果大家看過我之前寫的文章應該知道我用全記憶體跑了很多模型對使用者打標籤，一個模型就是一組定向的篩選條件，而為了加速處理，我會原子化篩選條件，然後一邊查詢一邊快取原子化條件獲取的人數，後面的模型如果命中了前面模型的原子化條件，那麼可以直接從快取中讀取它的人數即可，這也是動態規劃的思想~ ,如果不明白我來畫張圖。
從上面圖可以看到，在計算模型2的時候，條件1的人數可以直接從模型1下的條件1處獲取，模型三下的2，5的人數也可以直接從模型1和2處獲取，這樣就大大加速的處理速度。
## 2. 找原因
剛才提到了快取人數，我也不知道為什麼用了這麼一個型別,如下程式碼：
``` C#
///
/// 快取原子人群
/// key: 原子化條件
/// value: 人數集合
///
public ConcurrentDictionary> CachedCrowds { get; set; } = new ConcurrentDictionary>();
```
我說的是裡面的List\,我居然用了long型別儲存customerID，可能是看了這個專案先祖原先定義的long才跟風成long，