1.应用背景
在物联网应用场景中，需要维护很多个设备的连接，比如基于TCP socket通信的长连接，目的是为了获取设备采集的信息，反向控制设备的数字开关或者模拟量。我们把这些TCP长连接都放入了基于线程安全的ConcurrentDictionary激活字典表中，IP地址作为key，设备箱领域模型作为value。我们需要把激活设备箱的字典表维护好，需要将超时没有心跳的设备，我们可以称之为脱网设备，给清理出激活字典表，写入到脱网告警字典表中去。当脱网设备下次再有心跳时，可以再次移入到激活字典表中，从而再产生恢复告警，进行一系列其他动作。
2.整体框架
2.1.心跳注册框架
2.1.1.海量设备
因为要模拟海量设备的TCP场景，我们利用模拟器生成了12000台模拟设备。8台真实设备。
2.1.2.心跳上报Handler流程
详细心跳上报流程详见上述框架图
- 第一次建立TCP长连接，并且上报心跳报文；
- socket缓存会先处理TCP中存在的粘包，具体方法可参见此篇博文 TCP粘包处理现象及其解决方案——基于NewLife.Net网络库的管道式帧长粘包处理方法
- 然后会触发OnReceive中的e事件，从而传入粘包处理后的message；
- 判断包有效性，因为这方面比较简单，根据不同协议写一个类来处理即可，这里不再展开；
- 包有效载荷的CRC判断，具体实现可参见此篇博文 基于Modbus三种CRC16校验方法的性能对比；
- 包类型解析（这里特指解析出心跳包）；
- 心跳包解析，具体可参见这两篇博文。深入浅出C#结构体——封装以太网心跳包的结构为例, 类与结构体性能对比测试——以封装网络心跳包为例
- 最终将设备新增激活字典表（第一次心跳）或者在激活字典表刷新心跳时间（非第一次心跳）。
突然发现我可以写一个物联网的采集系统的系列了，组织一个目录。希望自己坚持下去吧。
2.2.脱网清理框架
2.2.1.激活字典表清理脱网设备方法
原理很简单，遍历字典表中超过设置的检测周期，筛选到一个字典的IEnumerable中去，然后在激活字典表中删除对应超时key（这里就是指IP地址）即可。当然这里的_internal周期可以*N，多个周期，自行在配置文件中设置即可，配置文件如下：
"ipboxNumStaticInternal": 12
public static void DeleteDeadBoxFromActiveBox(in _internal) { { var outTime = DateTime.Now.AddSeconds(-_internal); var iboxTimeOutList = iboxActiveDictionary.Where(q => (outTime > q.Value.UpdateTime));//.Select(x=> iboxActiveDictionary[x.Key]) ; foreach (var item in iboxTimeOutList) { iboxActiveDictionary.Remove(item.Key); } } } 2.2.2.脱网清理流程图
这里主要开启了一个系统定时器，主动会去调用清理脱网设备方法，调用时间间隔即ipboxNumStaticInternal。代码如下：
public void systemTimerStart() { var interval = ReadTheInternalFromSetting(); _systemTimer = new Timer(state => { IBoxActiveDicManager.DeleteDeadBoxFromActiveBo(_internal); Console.WriteLine("{1},激活设备数量：{0}\n",IBoxActiveDicManager.iboxActiveDictionary.Count,DateTime.Now); }, null, interval, interval); Console.WriteLine("PemsCom采集系统时钟已经开启"); LoggerHelper.Info("PemsCom采集系统时钟已经开启"); } /// <summary> /// 配置文件读入时间间隔方法 /// </summary> /// <returns></returns> private int ReadTheInternalFromSetting() { _internal = int.Parse(Appsettings.app(new string[] {"ipboxNumStaticInternal" })); Console.WriteLine("PemsCom采集系统时钟配置参数已经读"); LoggerHelper.Info("PemsCom采集系统时钟配置参数已经读"); return Convert.ToInt32(TimeSpan.FromSecond(_internal).TotalMilliseconds); } 3.多线程与高并发说明
3.1.多线程说明
这里会有很多的线程让CPU来轮片执行，比如：
- 12008个Receive事件触发线程；
- 定时清除脱网设备线程；
- 主线程，监控命令行输入，并执行对应的命令；
举个实际的例子，以图为证
12008台设备，每秒处理接受网络包的峰峰值是9218个包，就是在某一秒，CPU共轮片执行了9218个线程。比如是双核4线程的，则9218/4=2304.5。即CPU在1秒轮片执行了2305次。即0.43毫秒就轮片执行一次。
3.2.高并发说明
其实3.1已经解释了高并发。在某一秒，需要处理的接收事件有接近1万件。而这一时刻的执行顺序是无序的，9218里的这么多线程，我们不知道哪个先执行，哪个后执行。如果不认为地加一些逻辑控制，比如我们今天要介绍的互斥锁，就会出现一些异常现象。
4.多线程高并发造成的异常现象
这里只描述现象，原因会在下面5.分析异常原因 做具体描述。
4.1.空引用
异常所在的位置：心跳处理类如下。
public class HeartHandler
{
static string _deviceIndex = Appsettings.app(new string[] { "DeviceIndex" }); private static IBoxActive iboxActive; public static void Register(TcpHeartPacket heartPacket,int sessId) { UInt32 IP; UInt64 mac; if (_deviceIndex == "IP") { IP =(UInt32)BitConverter.ToUInt32(heartPacket.IP, 0); if (IBoxActiveDicManager.GetBoxActive(IP, out iboxActive) != true) { IBoxActiveDicManager.iboxActiveDictionary.TryAdd(IP, iboxActive); iboxActive.SessID = sessId; } } else { mac = (UInt64)BitConverter.ToUInt64(heartPacket.Mac, 0); if (IBoxActiveDicManager.GetBoxActive(mac, out iboxActive) != true) { IBoxActiveDicManager.iboxActiveDictionary.TryAdd(mac, iboxActive); iboxActive.SessID = sessId; } } //引用类型，智能指针，使用方便 iboxActive.UpdateTime = DateTime.Now; } } 4.2.字典表里元素赋值不成功
/// <summary>
/// 查询激活设备箱字典中是否有存在上报的设备箱, /// 存在返回true，不存在返回false，并且新建好设备箱模型 /// </summary> /// <param name="mac"></param> /// <param name="iboxActive"></param> /// <returns></returns> public static bool GetBoxActive(UInt32 IP, out IBoxActive iboxActive) { if (iboxActiveDictionary.TryGetValue(IP, outiboxActive)) { return true; } iboxActive = new IBoxActive(); iboxActive.IP = IP; if (iboxActive.IP != IP) { LoggerHelper.Error(string.Format("实例化赋值不成功.iboxActive.IP:{0};IP{1}", iboxActive.IP, IP)); } return false; } 有没有感觉很奇怪，上一句都赋值了，下一句对比就不相等。但是在多线程大并发里就是有这种可能，下面会详细分析。
4.3.统计设备总数不正确
因为12008台大并发时很容易出错，所以改成了1000台。如下统计数据会有出错情况，这同样也是因为多线程高并发引起的错误。
5.分析异常原因
5.1.造成空引用的原因
其实第4的三点原因都是同一个原因造成，所以在5.1会详细阐述，5.2，,5.3只做简单阐述。这里敲下黑板，分析多线程高并发的异常问题，程序运行的特点就是见缝就插，就像个老司机一样，概括起来就是线程与线程之间的无序性。比如我们设备心跳线程正在更新设备心跳时间的时候。脱网清理线程就把该设备给清理掉了。如此一来，时间没法赋值给空对象（已被脱网线程给清理）。因此只能报空引用异常，对没错，就是这么简单，耗费了我很长时间去debug跟思考这个异常。
5.2.设备IP赋值不成功原因
同样，在创建了设备实例之后，IP赋值完成，刚好脱网清除设备线程运行清除了设备，当对比的时候，引用原来的地址，字典的原来地址已经存了其他设备箱的IP，所以IP地址不相等。
5.3.统计设备总数不正确原因
原因其实是5.2造成的，没法成功注册，当然数量就不对啦。
6.解决思路
就是当我在创建激活设备实例（第一次心跳注册）或者更新心跳时间的时候（非第一次注册），不要让无序的脱网清除线程运行。敲黑板:就是保证心跳处理注册过程的原子性。对，其实这里很像关系型数据库的事务，原子性。原子性就是对抗程序无序造成异常的有力武器。我们可以在注册心跳处理方法上加个互斥锁，让编译器跟运行时去安排更加合理的执行顺序。
7.代码实现
代码很简单。
//定义一把锁
public static Mutex activeIpboxDicMutex = new Mutex();
//设备箱注册加锁。异常全部消除 IBoxActiveDicManager.activeIpboxDicMWaitOne(); HeartHandler.Register(tcpHeartPacsessionId); IBoxActiveDicManager.activeIpboxDicMReleaseMutex(); 这里插入一下事务的使用，也是很类似的，把我们的主业务加中中间，类比方便大家理解记忆。就像夹心饼干（瞎扯）。
unitOfWork.BeginTransaction();
// Adds new device
unitOfWork.DeviceRepository.Add(device); // Commit transaction unitOfWork.Commit(); 当然也可以给设备箱脱网清除线程加锁。
IBoxActiveDicManager.activeIpboxDicMutex.WaitOne();
IBoxActiveDicManager.DeleteDeadBoxFromActiveBox(_internal); IBoxActiveDicManager.activeIpboxDicMutex.ReleaseMutex(); 考虑到脱网清除线程会损耗部分性能，我也测试了去掉该锁的情况，也不会有第4的3个异常，至此问题全部解决。
8.小结
-
模拟设备数量小测不出这个问题，如此看出海量设备的重要性，因为现实情况肯定会出现以上三个问题，而且都是很严重很致命的问题。好的测试方法可以把问题扼杀在摇篮中；
-
多线程高并发时容易出现这样那样的异常，要怀着敬畏之心去思考，去解决问题；