昨天发现线上试跑期的一个程序挂了,平时都跑的好好的,查了下日志是由于昨天运营跑了一家美妆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啦,反而浪费空间,固然数据量小怎么用也无所谓。
跑小店铺的时候代码怎么写都行,数据量大了处处都是坑,你的场景也总有优化的办法~