昨天發現線上試跑期的一個程序掛了,平時都跑的好好的,查了下日誌是由於昨天運營跑了一家美妝top級淘品牌店,會員量近千萬,一會兒就把128G的內存給爆了,當時並行跑了二個任務,沒轍先速寫一段代碼限流,後面再作進一步優化。html
由於是本身寫的代碼,因此我知道問題出如今哪裏,若是你們看過我以前寫的文章應該知道我用全內存跑了不少模型對用戶打標籤,一個模型就是一組定向的篩選條件,而爲了加速處理,我會原子化篩選條件,而後一邊查詢一邊緩存原子化條件獲取的人數,後面的模型若是命中了前面模型的原子化條件,那麼能夠直接從緩存中讀取它的人數便可,這也是動態規劃的思想~ ,若是不明白我來畫張圖。算法
從上面圖能夠看到,在計算模型2的時候,條件1的人數能夠直接從模型1下的條件1處獲取,模型三下的2,5的人數也能夠直接從模型1和2處獲取,這樣就大大加速的處理速度。數組
剛纔提到了緩存人數,我也不知道爲何用了這麼一個類型,以下代碼:緩存
/// <summary> /// 緩存原子人羣 /// key: 原子化條件 /// value: 人數集合 /// </summary> public ConcurrentDictionary<string, List<long>> CachedCrowds { get; set; } = new ConcurrentDictionary<string, List<long>>();
我說的是裏面的List<long>,我竟然用了long類型存儲customerID,多是看了這個項目先祖原先定義的long纔跟風成long,😄😄😄,誰家店有數不盡的客戶,國家才14億人呢,而一個long佔用8個字節,明顯是一種浪費。數據結構
人都是懶的,能少改點代碼就少改點,省的背鍋,好事不出門,壞事傳千里,因此這裏用int表示就足夠了,應該能省一半的空間對不對,接下來爲了演示,在List<long> 和 List<int> 中分別灌入 500w 客戶ID,代碼以下:dom
public static void Main(string[] args) { var rand = new Random(); List<int> intCustomerIDList = Enumerable.Range(1, 5000000).OrderBy(m => rand.Next(0, 100000)) .Take(5000000).ToList(); List<long> longCustomerIDList = Enumerable.Range(1, 5000000).OrderBy(m => rand.Next(0, 100000)) .Take(5000000).Select(m => (long)m).ToList(); Console.WriteLine("處理完畢..."); Console.Read(); }
接下來用windbg看一下他們在堆中各佔多少內存。學習
~0s -> !clrstack -l -> !dumpobj 從主線程找到List<int>和List<long> 的局部變量,而後查看size。優化
0:000> ~0s ntdll!ZwReadFile+0x14: 00007ff8`fea4aa64 c3 ret 0:000> !clrstack -l OS Thread Id: 0x5b70 (0) Child SP IP Call Site 00000015c37feed0 00007ff889e60b9c ConsoleApp2.Program.Main(System.String[]) [C:\dream\Csharp\ConsoleApp1\ConsoleApp2\Program.cs @ 35] LOCALS: 0x00000015c37fef90 = 0x0000014ad7c12d88 0x00000015c37fef88 = 0x0000014ad7c13060 0x00000015c37fef80 = 0x0000014ad7c33438 00000015c37ff1a8 00007ff8e9396c93 [GCFrame: 00000015c37ff1a8] 0:000> !do 0x0000014ad7c13060 Name: System.Collections.Generic.List`1[[System.Int32, mscorlib]] MethodTable: 00007ff8e7aaa068 EEClass: 00007ff8e7c0b008 Size: 40(0x28) bytes File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll Fields: MT Field Offset Type VT Attr Value Name 00007ff8e7a98538 400189e 8 System.Int32[] 0 instance 0000014af02d1020 _items 00007ff8e7a985a0 400189f 18 System.Int32 1 instance 5000000 _size 00007ff8e7a985a0 40018a0 1c System.Int32 1 instance 5000000 _version 00007ff8e7a95dd8 40018a1 10 System.Object 0 instance 0000000000000000 _syncRoot 00007ff8e7a98538 40018a2 0 System.Int32[] 0 shared static _emptyArray >> Domain:Value dynamic statics NYI 0000014ad61166c0:NotInit << 0:000> !do 0000014af02d1020 Name: System.Int32[] MethodTable: 00007ff8e7a98538 EEClass: 00007ff8e7c05918 Size: 33554456(0x2000018) bytes Array: Rank 1, Number of elements 8388608, Type Int32 (Print Array) Fields: None 0:000> !do 0x0000014ad7c33438 Name: System.Collections.Generic.List`1[[System.Int64, mscorlib]] MethodTable: 00007ff8e7aad2a0 EEClass: 00007ff8e7c0bd70 Size: 40(0x28) bytes File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll Fields: MT Field Offset Type VT Attr Value Name 00007ff8e7aa6c08 400189e 8 System.Int64[] 0 instance 0000014a80001020 _items 00007ff8e7a985a0 400189f 18 System.Int32 1 instance 5000000 _size 00007ff8e7a985a0 40018a0 1c System.Int32 1 instance 5000000 _version 00007ff8e7a95dd8 40018a1 10 System.Object 0 instance 0000000000000000 _syncRoot 00007ff8e7aa6c08 40018a2 0 System.Int64[] 0 shared static _emptyArray >> Domain:Value dynamic statics NYI 0000014ad61166c0:NotInit << 0:000> !do 0000014a80001020 Name: System.Int64[] MethodTable: 00007ff8e7aa6c08 EEClass: 00007ff8e7c09e50 Size: 67108888(0x4000018) bytes Array: Rank 1, Number of elements 8388608, Type Int64 (Print Array) Fields: None
仔細看上圖,在主線程的堆棧中找到了三個變量,後兩個變量就是咱們的List<int> 和 List<long>,分別是線程
Size: 33554456(0x2000018) bytes
=> 33554456/1024/1024 = 32M
日誌
Size:67108888(0x4000018) bytes
=> 67108888/1024/1024 = 64M
之後能夠跟別人吹牛了,我知道500w個int佔用是32M內存,雖然內存空間優化了一半,但沒有本質性的優化,還得繼續往上挖,不然同時跑4個任務又要把內存給爆掉了。。。
咱們在學習數據結構的時候,相信不少人都學習過bitmap,恰好原子化的篩選條件獲取的人數衆多,使用bitmap恰好知足個人業務需求,若是不知道bitmap我簡單解釋一下。
咱們都知道一個int是4個字節。也就是4byte,也就是32bit,畫成圖就是32個格子,以下所示:
默認狀況下32個格子表示一個int是否是有點浪費,其實32個格子能夠放置32個數字(1-32)。好比1放在第一個格子裏,3放在第三個格子裏。。。32放在第32個格子裏,那麼兩個int就能夠存放1-64個數字,也就是說理想狀況下能夠優化空間32倍,思惟必定要反轉一下,把數字做爲數組的下標,由於是bit,因此0,1兩種狀態恰好能夠表示當前格子是否已經被設置了,1表示已設置,0表示未設置,好好品味一下,若是仍是不明白,能夠參考我八年前的文章:
在C#中已經幫咱們設置好了一個BitArray類,結合我剛纔講得,你們好好品味一下bitarray如何向各自格子中設置值的,底層仍是用m_array承載,它實際上是一個int[]。
public void Set(int index, bool value) { if (value) { m_array[index / 32] |= 1 << index % 32; } else { m_array[index / 32] &= ~(1 << index % 32); } _version++; } public bool Get(int index) { return (m_array[index / 32] & (1 << index % 32)) != 0; }
接下來把List<int> 中的數據灌入到bitArray中看看,先上一下代碼:
public static void Main(string[] args) { var rand = new Random(); List<int> intCustomerIDList = Enumerable.Range(1, 5000000).OrderBy(m => rand.Next(0, 100000)) .Take(5000000).ToList(); BitArray bitArray = new BitArray(intCustomerIDList.Max() + 1); foreach (var customerID in intCustomerIDList) { bitArray[customerID] = true; } Console.WriteLine("處理完畢..."); Console.Read(); }
而後抓一下dump文件,用windbg看一下內存佔用。
0:000> !do 0x0000026e4d0332b8 Name: System.Collections.BitArray MethodTable: 00007ff8e7a89220 EEClass: 00007ff8e7c01bc0 Size: 40(0x28) bytes File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll Fields: MT Field Offset Type VT Attr Value Name 00007ff8e7a98538 4001810 8 System.Int32[] 0 instance 0000026e5dfd9bd8 m_array 00007ff8e7a985a0 4001811 18 System.Int32 1 instance 5000001 m_length 00007ff8e7a985a0 4001812 1c System.Int32 1 instance 5000000 _version 00007ff8e7a95dd8 4001813 10 System.Object 0 instance 0000000000000000 _syncRoot 0:000> !DumpObj /d 0000026e5dfd9bd8 Name: System.Int32[] MethodTable: 00007ff8e7a98538 EEClass: 00007ff8e7c05918 Size: 625028(0x98984) bytes Array: Rank 1, Number of elements 156251, Type Int32 (Print Array) Fields: None
從圖中能夠看到,沒錯,就是bitArray類型,從Size中能夠看到:
Size: 625028(0x98984) bytes
=> 625028/1024/1024 = 0.59M
看到沒有,這個就🐮👃了,由最初的64M優化到了0.6M,簡直不要太爽,看到這麼小的佔用量,我感到枯燥而乏味,哈哈,這下並行跑幾十家不怕了,這裏要提醒一下,若是客戶數少而且數字還大,就不要用bitArray啦,反而浪費空間,固然數據量小怎麼用也無所謂。
跑小店鋪的時候代碼怎麼寫都行,數據量大了處處都是坑,你的場景也總有優化的辦法~