用long类型让我出了次生产事故，写代码还是要小心点

昨天发现线上试跑期的一个程序挂了，平时都跑的好好的，查了下日志是因为昨天运营跑了一家美妆top级淘品牌店，会员量近千万，一下子就把128G的内存给爆了，当时并行跑了二个任务，没辙先速写一段代码限流，后面再做进一步优化。

一： 背景

1. 背景介绍

因为是自己写的代码，所以我知道问题出现在哪里，如果大家看过我之前写的文章应该知道我用全内存跑了很多模型对用户打标签，一个模型就是一组定向的筛选条件，而为了加速处理，我会原子化筛选条件，然后一边查询一边缓存原子化条件获取的人数，后面的模型如果命中了前面模型的原子化条件，那么可以直接从缓存中读取它的人数即可，这也是动态规划的思想~ ,如果不明白我来画张图。

从上面图可以看到，在计算模型2的时候，条件1的人数可以直接从模型1下的条件1处获取，模型三下的2，5的人数也可以直接从模型1和2处获取，这样就大大加速的处理速度。

2. 找原因

刚才提到了缓存人数，我也不知道为什么用了这么一个类型,如下代码：

///

/// 缓存原子人群

/// key: 原子化条件

/// value: 人数集合

///

public ConcurrentDictionary> CachedCrowds { get; set; } = new ConcurrentDictionary>();

我说的是里面的List,我居然用了long类型存储customerID，可能是看了这个项目先祖原先定义的long才跟风成long，

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。