工控机C#程序避免死机的10条铁则，我用了20年没出过生产事故

做工业控制20年见过太多因为一行代码、一个疏忽导致的生产线停摆事故。少则损失几万多则几十万甚至上百万。我见过刚毕业的大学生写的程序功能看起来完美一上线三天两头死机也见过工作五六年的老工程师因为一个没处理的空指针导致整条汽车生产线停了8个小时。工控程序和互联网程序最大的区别是什么互联网程序崩了重启一下就好最多影响几个用户。工控程序崩了可能会导致设备损坏、人员受伤甚至整个工厂停产。工控程序的第一优先级永远是可靠性而不是性能、不是代码优雅、不是新特性。这10条铁则是我从无数次事故和踩坑中总结出来的。我自己用了20年带过的团队也一直在用至今没有出过一起因为程序问题导致的生产事故。分享给所有奋战在工业一线的开发者们。一、永远不要相信任何外部输入这是所有铁则中最基础、也是最重要的一条。在工控领域所有外部输入都是不可信的。包括但不限于硬件IO信号、串口/网口数据、用户输入、配置文件、数据库数据。我见过最多的死机原因就是程序员想当然地认为硬件不会发错数据、“用户不会输入非法字符”、“配置文件不会被修改”。常见错误// 错误示例直接解析串口数据不做任何校验byte[]dataserialPort.ReadExisting();intvalueBitConverter.ToInt32(data,0);// 如果data长度小于4直接抛出数组越界异常正确做法所有外部输入必须经过三层校验长度校验确保数据长度符合预期格式校验确保数据格式正确如校验和、帧头帧尾范围校验确保数据值在合理范围内// 正确示例三层校验byte[]dataReadSerialDataWithTimeout(1000);if(datanull||data.Length!8){logger.Warn($无效数据长度{data?.Length??0});returnnull;}if(data[0]!0xAA||data[7]!0x55){logger.Warn($无效帧头帧尾{BitConverter.ToString(data)});returnnull;}if(CalculateChecksum(data,1,5)!data[6]){logger.Warn($校验和错误{BitConverter.ToString(data)});returnnull;}intvalueBitConverter.ToInt32(data,1);if(value0||value1000){logger.Warn($数据值超出范围{value});returnnull;}returnvalue;踩坑经历2008年我负责一个啤酒灌装线项目。上线后每周都会随机死机一次查了一个月都没找到原因。最后发现是因为某个传感器偶尔会发送一个长度为0的数据包。程序直接解析这个空数组导致数组越界异常。就这么一个小小的问题导致每周损失几万块。二、异常处理要兜底但不吞掉C#的异常机制非常强大但很多人用错了。异常处理的目的不是让程序不崩溃而是让程序在崩溃前记录足够的信息并且尽可能优雅地恢复。常见错误最致命的错误就是空catch块这会把所有异常都吞掉导致问题被隐藏。等到程序最终崩溃的时候你连一点线索都没有。// 致命错误空catch块try{// 可能抛出异常的代码}catch{// 什么都不做}另一个常见错误是只捕获Exception然后只记录一句发生错误没有任何详细信息。正确做法分层异常处理底层抛出具体异常中层根据异常类型处理顶层做全局兜底记录完整异常信息包括异常类型、消息、堆栈跟踪、相关数据不要捕获你无法处理的异常如果异常无法恢复就让程序崩溃然后由看门狗重启// 全局异常兜底WinFormApplication.ThreadException(sender,e){logger.Fatal($未处理的UI线程异常{e.Exception},e.Exception);// 尝试保存关键数据SaveCriticalData();// 显示友好提示然后退出程序MessageBox.Show(程序发生严重错误即将重启。,错误,MessageBoxButtons.OK,MessageBoxIcon.Error);Process.Start(Application.ExecutablePath);Application.Exit();};AppDomain.CurrentDomain.UnhandledException(sender,e){logger.Fatal($未处理的非UI线程异常{e.ExceptionObject},e.ExceptionObjectasException);SaveCriticalData();// 非UI线程异常无法恢复直接退出Environment.Exit(1);};异常处理流程图三、线程管理要可控禁止无限创建线程线程滥用是工控程序死机的头号杀手。我见过太多程序每次收到一个数据就创建一个新线程结果线程数越来越多系统资源耗尽最后整个系统卡死。常见错误// 错误示例每次收到数据就创建新线程serialPort.DataReceived(sender,e){newThread((){ProcessData();}).Start();};如果每秒收到10个数据一分钟就会创建600个线程。每个线程至少占用1MB栈空间600个线程就是600MB再加上上下文切换的开销系统很快就会卡死。正确做法使用线程池控制最大线程数给每个线程设置超时时间确保线程能正常退出避免线程死锁按照固定顺序获取锁使用超时锁// 正确示例使用有限线程池privatereadonlyLimitedConcurrencyLevelTaskScheduler_taskSchedulernewLimitedConcurrencyLevelTaskScheduler(Environment.ProcessorCount);privatereadonlyCancellationTokenSource_cancellationTokenSourcenewCancellationTokenSource();serialPort.DataReceived(sender,e){Task.Factory.StartNew((){try{ProcessDataWithTimeout(1000,_cancellationTokenSource.Token);}catch(OperationCanceledException){logger.Info(数据处理任务被取消);}catch(Exceptionex){logger.Error($数据处理异常{ex.Message},ex);}},_cancellationTokenSource.Token,TaskCreationOptions.None,_taskScheduler);};四、内存管理要精细化避免内存泄漏很多人认为C#有垃圾回收就不会有内存泄漏。这是大错特错的。在工控程序中内存泄漏非常常见而且往往是慢性的程序运行几周甚至几个月后才会崩溃。常见内存泄漏原因事件不注销这是最常见的原因静态集合无限增长非托管资源不释放长生命周期对象持有短生命周期对象的引用正确做法所有注册的事件在对象销毁时必须注销使用弱引用WeakReference避免不必要的对象持有定期清理静态集合使用内存分析工具如dotMemory定期检测内存泄漏// 正确示例事件注销publicclassDataProcessor:IDisposable{privateISerialPort_serialPort;privatebool_disposedfalse;publicDataProcessor(ISerialPortserialPort){_serialPortserialPort;_serialPort.DataReceivedOnDataReceived;}privatevoidOnDataReceived(objectsender,DataReceivedEventArgse){// 处理数据}publicvoidDispose(){Dispose(true);GC.SuppressFinalize(this);}protectedvirtualvoidDispose(booldisposing){if(_disposed)return;if(disposing){// 注销事件if(_serialPort!null){_serialPort.DataReceived-OnDataReceived;_serialPort.Dispose();_serialPortnull;}}_disposedtrue;}~DataProcessor(){Dispose(false);}}五、硬件交互要异步超时绝对不能同步阻塞这是工控程序最容易犯的错误之一。与硬件交互时如果使用同步调用且没有设置超时一旦硬件无响应程序就会永远卡死在那里。常见错误// 错误示例同步读取无超时serialPort.ReadTimeoutTimeout.Infinite;byte[]datanewbyte[1024];intbytesReadserialPort.Read(data,0,1024);// 如果硬件无响应这里会永远阻塞正确做法所有硬件交互都使用异步IO所有调用都必须设置超时时间超时后主动断开连接然后重试// 正确示例异步读取带超时publicasyncTaskbyte[]ReadDataWithTimeoutAsync(inttimeoutMs,CancellationTokencancellationToken){vartcsnewTaskCompletionSourcebyte[]();using(varctsCancellationTokenSource.CreateLinkedTokenSource(cancellationToken)){cts.CancelAfter(timeoutMs);using(cts.Token.Register(()tcs.TrySetCanceled())){try{byte[]buffernewbyte[1024];intbytesReadawaitserialPort.BaseStream.ReadAsync(buffer,0,buffer.Length,cts.Token);byte[]resultnewbyte[bytesRead];Array.Copy(buffer,result,bytesRead);returnresult;}catch(OperationCanceledException){logger.Warn($读取数据超时超时时间{timeoutMs}ms);// 超时后断开连接准备重连Disconnect();throw;}}}}六、日志系统要可追溯但不能影响性能日志是排查工控程序问题的唯一依据。没有日志当程序出问题时你就像瞎子一样。但如果日志写得太多太频繁又会严重影响程序性能甚至导致程序卡死。正确做法使用异步日志框架如NLog、Serilog分级日志Trace、Debug、Info、Warn、Error、Fatal只记录必要的信息生产环境只记录Warn及以上级别日志文件按大小和日期滚动自动清理旧日志关键操作必须记录日志设备启停、参数修改、异常发生// NLog配置示例异步滚动文件targetnameasyncFilexsi:typeAsyncWrappertargetnamefilexsi:typeFilefileName${basedir}/logs/${shortdate}.logarchiveFileName${basedir}/logs/archive/${shortdate}.{#}.logarchiveAboveSize10485760!--10MB--archiveNumberingRollingmaxArchiveFiles30layout${longdate}|${level:uppercasetrue}|${logger}|${message}|${exception:formattostring}//target七、资源释放要显式不要依赖GC非托管资源文件句柄、串口、网口、数据库连接必须显式释放绝对不能依赖垃圾回收器。GC什么时候回收是不确定的可能会导致资源长时间被占用甚至无法再次打开。正确做法使用using语句自动释放资源在finally块中释放资源实现IDisposable接口程序退出时确保所有资源都被释放// 正确示例using语句using(varserialPortnewSerialPort(COM1,9600)){serialPort.Open();// 使用串口}// 离开using块后串口自动关闭并释放资源八、核心业务与非核心业务进程隔离这是我从一次惨痛的事故中总结出来的经验。2012年我负责一个钢铁厂的项目所有功能都在一个进程中UI、数据采集、逻辑控制、报表生成、数据上传。有一次报表生成功能因为数据量太大导致UI卡死整个程序失去响应生产线停了4个小时。从那以后我所有的项目都采用进程隔离架构。核心控制逻辑单独一个进程UI、报表、数据上传等非核心功能放在其他进程中。这样即使非核心功能崩溃也不会影响核心业务。工控程序分层架构图进程间通信可以使用命名管道、WCF、gRPC等方式进行进程间通信。我个人推荐使用命名管道简单、高效、稳定。九、双看门狗机制软件看门狗硬件看门狗再完美的程序也可能会死机。所以必须要有看门狗机制确保程序死机后能自动重启。只使用软件看门狗是不够的。如果整个系统卡死软件看门狗也会失效。必须同时使用硬件看门狗。双看门狗机制流程图软件看门狗软件看门狗用于监控程序内部状态。它会定期检查各个线程的运行状态如果某个线程长时间没有响应就会主动重启程序。硬件看门狗硬件看门狗是一个独立的硬件模块它会定期检查程序是否在运行。如果程序在规定时间内没有喂狗硬件看门狗就会强制重启整个工控机。注意喂狗操作一定要放在最低优先级的线程中。如果放在高优先级线程中即使其他线程都卡死了高优先级线程仍然能喂狗导致看门狗失效。十、上线前必须做压力测试异常测试很多人上线前只做功能测试测试正常流程没问题就上线了。结果一到生产环境遇到各种异常情况就崩溃。工控程序的测试重点不是测试正常流程而是测试异常流程。你要模拟所有可能发生的异常情况看看程序能不能正确处理。必须做的测试压力测试连续运行72小时以上监控内存、CPU、线程数异常测试模拟网络中断、硬件故障、数据异常、电源波动边界测试测试参数的最大值、最小值、边界值故障恢复测试故意让程序崩溃看看看门狗能不能正常重启最后想说的话做工业控制真的不容易。我们写的每一行代码都可能关系到工厂的安全生产关系到工人的生命安全。很多年轻的工程师喜欢追求新技术喜欢用各种花哨的语法和框架。但在工控领域稳定大于一切。能用简单的方法实现就不要用复杂的方法能用成熟的技术就不要用新的技术。这10条铁则看起来都很简单甚至有些老生常谈。但真正能做到每一条的人少之又少。很多人都是出了事故才想起这些简单的道理。希望这篇文章能帮助到所有工控开发者。愿我们写的程序都能7x24小时稳定运行永不死机。