配置热重载机制改配置不用重启程序这是「从零搭建工业控制系统」系列第15篇。上一篇讲了配置系统基础——INI管全局参数JSON管命令定义。这篇讲热加载怎么在程序运行时改配置不用重启就生效。为什么要热加载工业软件跟普通软件不一样——停机就是亏钱。生产中经常需要调配置改个命令参数、加个IO点位、调个报警阈值。如果每次改配置都要停程序、改文件、重新启动那每次都要中断生产。热加载的目标很简单改了配置文件程序自动重新加载不用重启。但实现起来有几个坑要处理。FileSystemWatcher监听文件变化.NET 自带的FileSystemWatcher可以监听文件系统变化privatevoidSetupFileWatcher(){varwatchernewFileSystemWatcher(_configDirectory,*.jsonc){IncludeSubdirectoriestrue,EnableRaisingEventstrue};watcher.ChangedOnConfigFileChanged;watcher.CreatedOnConfigFileChanged;}监听Changed和Created两个事件——改文件触发 Changed新建文件触发 Created。删除配置文件不需要处理你不能加载一个不存在的文件。看起来很简单但实际用起来有几个坑。坑1事件触发多次这是 FileSystemWatcher 最经典的坑。用记事本保存文件时记事本的写入方式是写临时文件→替换原文件这会触发多次 Changed 事件。用 VS Code 保存时行为又不一样。有时候同一次保存触发2-3次事件。如果每次事件都重新加载配置那一次保存会触发2-3次全量加载。配置文件多的时候全量加载可能需要几百毫秒卡住UI线程。解决办法防抖。privateTimer_debounceTimer;privatevoidOnConfigFileChanged(objectsender,FileSystemEventArgse){// 500ms内多次事件只执行最后一次_debounceTimer?.Change(500,Timeout.Infinite);}privatevoidOnDebounceTick(objectstate){ReloadAllConfigs();_logger.Info(命令配置已热加载);}Timer.Change(500, Timeout.Infinite)的意思是500ms 后触发一次如果在这500ms内又调了 Change重新计时。最终效果是——事件停止触发后500ms才真正执行加载。500ms 是经验值。太短比如50ms可能防不住记事本的多次写入太长比如2000ms操作员会觉得改了配置半天没反应。坑2文件被占用FileSystemWatcher 的 Changed 事件触发时文件可能还没被记事本释放。如果这时候去读会报 IOException “文件正在被另一进程使用”。解决办法是重试privatestringReadFileWithRetry(stringpath,intmaxRetries3){for(inti0;imaxRetries;i){try{returnFile.ReadAllText(path);}catch(IOException){Thread.Sleep(100);// 等100ms再试}}thrownewIOException($读取配置文件失败重试{maxRetries}次:{path});}3次重试每次间隔100ms。正常情况下第一次重试就能成功。坑3部分写入的文件这是最危险的坑。如果配置文件很大编辑器写入需要时间。FileSystemWatcher 可能在文件写了一半时就触发事件。这时候去读读到的是不完整的JSON——解析直接报错。更糟的情况JSON刚好写到一半语法没错但内容不完整。比如一个数组有5个元素只写了2个就触发了事件。加载后注册表里只有2个命令另外3个丢了。解决办法有两个办法A文件锁标记写入前先创建一个.lock文件写完再删除。监听器看到.lock文件存在就跳过加载。编辑器保存流程: 创建 config.jsonc.lock 写入 config.jsonc 删除 config.jsonc.lock 监听器: 收到Changed事件 如果 .lock 文件存在 → 跳过 否则 → 加载问题记事本/VS Code 不会自动创建 .lock 文件。需要自定义编辑器或脚本。办法BJSON完整性校验加载前先校验JSON是否完整privateboolTryParseJson(stringcontent,outJObjectresult){try{resultJObject.Parse(content);returntrue;}catch{resultnull;returnfalse;}}privatevoidOnDebounceTick(objectstate){varcontentReadFileWithRetry(path);if(!TryParseJson(content,outvarjson)){_logger.Warn($配置文件不完整跳过加载:{path});return;// 下次保存时再加载}// 正常加载...}实际项目用的是办法B——简单不依赖编辑器配合。代价是偶尔会跳过一次加载但下次保存时会成功。注册表热更新加载了新配置后要更新注册表。但不能直接替换注册表引用——可能有其他线程正在用旧注册表。热更新流程: 1. 加载新配置文件 → 生成新注册表 2. 验证新注册表完整性 3. 原子替换旧注册表引用 → 新注册表引用 4. 通知相关服务配置已变更第3步用Interlocked.Exchange保证原子性privateCommandRegistry_registry;publicCommandRegistryRegistry{get_registry;}publicvoidUpdateRegistry(CommandRegistrynewRegistry){Interlocked.Exchange(ref_registry,newRegistry);}正在用旧注册表的线程不受影响——它们持有的是旧引用会继续用完。新请求会拿到新注册表。这就是无锁更新的思路。配置变更通知注册表更新后需要通知相关服务。用消息机制WeakReferenceMessenger.Default.Send(newConfigChangedMessage());订阅了ConfigChangedMessage的服务会收到通知然后各自处理服务收到通知后做什么命令面板刷新命令列表安全服务重新读取安全参数灯塔服务重新读取灯塔配置追踪监控重新加载追踪通道为什么不用接口回调而用消息因为配置变更影响的服务很多而且不是所有服务都在编译时确定。消息机制是松耦合的——服务自己决定要不要订阅配置中心不需要知道谁订阅了。哪些配置适合热加载哪些不适合不是所有配置都适合热加载。配置类型热加载原因命令定义✅改命令参数不影响已建立的连接报警阈值✅下一次轮询就用新阈值IO点位配置⚠️ 谨慎新增IO可以删除IO可能导致引用失效IP地址/端口❌改了需要重新建立Modbus连接数据库配置❌改了需要重新连接数据库IP地址不能热加载——改了IP后旧的Modbus连接还连着旧IP。要断开重连才能用新IP。这种配置需要重启程序或者提供专门的重连按钮。配置保存的完整流程操作员在设置界面修改参数后点保存// 1. ViewModel收集UI值config.AutoAllowControlAutoAllowControl;config.ManualAllowControlManualAllowControl;config.TowerLightServiceEnableTowerLightServiceEnable;// 2. 调用ConfigReader写入文件ConfigReader.Instance.WriteConfig(config);// 3. 触发配置变更通知WeakReferenceMessenger.Default.Send(newConfigChangedMessage());// 4. 安全服务收到消息后响应写文件和发消息是两步。写完文件不发消息其他服务不知道配置变了。发消息但不写文件重启后配置丢失。两步缺一不可。踩坑记录坑1防抖时间太短一开始防抖设了100ms结果记事本保存触发了2次事件100ms内第二次事件来了又重新计时。但记事本两次写入间隔可能正好100ms左右偶尔会漏。改成500ms后稳定了。坑2热加载后UI没刷新注册表更新了但命令面板的列表还是旧的。原因是命令面板用的是 ObservableCollection注册表更新后没有清空重新填充。后来加了消息通知命令面板收到消息后重新从注册表拉取数据。坑3热加载时正在执行命令操作员改配置时正好有个命令在执行。热加载后注册表里那个命令可能被删了或改了。解决办法执行中的命令用快照——开始执行时拷贝一份命令配置执行过程中用快照不受热加载影响。本篇小结概念关键做法FileSystemWatcher监听文件变化不用轮询防抖500ms Timer避免多次触发文件占用重试3次间隔100ms部分写入JSON完整性校验不完整则跳过注册表热更新原子替换引用无锁更新变更通知消息机制松耦合不适合热加载IP地址、数据库配置需重启热加载的核心让操作员改配置不用停机但要处理好多次触发、文件占用、部分写入这三个坑。下期预告第16篇界面布局 — Dock面板与多窗口配置系统讲完了下篇回到UI——Dock面板怎么布局多窗口怎么管理区域导航怎么搞。
配置热重载机制改配置不用重启程序这是「从零搭建工业控制系统」系列第15篇。上一篇讲了配置系统基础——INI管全局参数JSON管命令定义。这篇讲热加载怎么在程序运行时改配置不用重启就生效。为什么要热加载工业软件跟普通软件不一样——停机就是亏钱。生产中经常需要调配置改个命令参数、加个IO点位、调个报警阈值。如果每次改配置都要停程序、改文件、重新启动那每次都要中断生产。热加载的目标很简单改了配置文件程序自动重新加载不用重启。但实现起来有几个坑要处理。FileSystemWatcher监听文件变化.NET 自带的FileSystemWatcher可以监听文件系统变化privatevoidSetupFileWatcher(){varwatchernewFileSystemWatcher(_configDirectory,*.jsonc){IncludeSubdirectoriestrue,EnableRaisingEventstrue};watcher.ChangedOnConfigFileChanged;watcher.CreatedOnConfigFileChanged;}监听Changed和Created两个事件——改文件触发 Changed新建文件触发 Created。删除配置文件不需要处理你不能加载一个不存在的文件。看起来很简单但实际用起来有几个坑。坑1事件触发多次这是 FileSystemWatcher 最经典的坑。用记事本保存文件时记事本的写入方式是写临时文件→替换原文件这会触发多次 Changed 事件。用 VS Code 保存时行为又不一样。有时候同一次保存触发2-3次事件。如果每次事件都重新加载配置那一次保存会触发2-3次全量加载。配置文件多的时候全量加载可能需要几百毫秒卡住UI线程。解决办法防抖。privateTimer_debounceTimer;privatevoidOnConfigFileChanged(objectsender,FileSystemEventArgse){// 500ms内多次事件只执行最后一次_debounceTimer?.Change(500,Timeout.Infinite);}privatevoidOnDebounceTick(objectstate){ReloadAllConfigs();_logger.Info(命令配置已热加载);}Timer.Change(500, Timeout.Infinite)的意思是500ms 后触发一次如果在这500ms内又调了 Change重新计时。最终效果是——事件停止触发后500ms才真正执行加载。500ms 是经验值。太短比如50ms可能防不住记事本的多次写入太长比如2000ms操作员会觉得改了配置半天没反应。坑2文件被占用FileSystemWatcher 的 Changed 事件触发时文件可能还没被记事本释放。如果这时候去读会报 IOException “文件正在被另一进程使用”。解决办法是重试privatestringReadFileWithRetry(stringpath,intmaxRetries3){for(inti0;imaxRetries;i){try{returnFile.ReadAllText(path);}catch(IOException){Thread.Sleep(100);// 等100ms再试}}thrownewIOException($读取配置文件失败重试{maxRetries}次:{path});}3次重试每次间隔100ms。正常情况下第一次重试就能成功。坑3部分写入的文件这是最危险的坑。如果配置文件很大编辑器写入需要时间。FileSystemWatcher 可能在文件写了一半时就触发事件。这时候去读读到的是不完整的JSON——解析直接报错。更糟的情况JSON刚好写到一半语法没错但内容不完整。比如一个数组有5个元素只写了2个就触发了事件。加载后注册表里只有2个命令另外3个丢了。解决办法有两个办法A文件锁标记写入前先创建一个.lock文件写完再删除。监听器看到.lock文件存在就跳过加载。编辑器保存流程: 创建 config.jsonc.lock 写入 config.jsonc 删除 config.jsonc.lock 监听器: 收到Changed事件 如果 .lock 文件存在 → 跳过 否则 → 加载问题记事本/VS Code 不会自动创建 .lock 文件。需要自定义编辑器或脚本。办法BJSON完整性校验加载前先校验JSON是否完整privateboolTryParseJson(stringcontent,outJObjectresult){try{resultJObject.Parse(content);returntrue;}catch{resultnull;returnfalse;}}privatevoidOnDebounceTick(objectstate){varcontentReadFileWithRetry(path);if(!TryParseJson(content,outvarjson)){_logger.Warn($配置文件不完整跳过加载:{path});return;// 下次保存时再加载}// 正常加载...}实际项目用的是办法B——简单不依赖编辑器配合。代价是偶尔会跳过一次加载但下次保存时会成功。注册表热更新加载了新配置后要更新注册表。但不能直接替换注册表引用——可能有其他线程正在用旧注册表。热更新流程: 1. 加载新配置文件 → 生成新注册表 2. 验证新注册表完整性 3. 原子替换旧注册表引用 → 新注册表引用 4. 通知相关服务配置已变更第3步用Interlocked.Exchange保证原子性privateCommandRegistry_registry;publicCommandRegistryRegistry{get_registry;}publicvoidUpdateRegistry(CommandRegistrynewRegistry){Interlocked.Exchange(ref_registry,newRegistry);}正在用旧注册表的线程不受影响——它们持有的是旧引用会继续用完。新请求会拿到新注册表。这就是无锁更新的思路。配置变更通知注册表更新后需要通知相关服务。用消息机制WeakReferenceMessenger.Default.Send(newConfigChangedMessage());订阅了ConfigChangedMessage的服务会收到通知然后各自处理服务收到通知后做什么命令面板刷新命令列表安全服务重新读取安全参数灯塔服务重新读取灯塔配置追踪监控重新加载追踪通道为什么不用接口回调而用消息因为配置变更影响的服务很多而且不是所有服务都在编译时确定。消息机制是松耦合的——服务自己决定要不要订阅配置中心不需要知道谁订阅了。哪些配置适合热加载哪些不适合不是所有配置都适合热加载。配置类型热加载原因命令定义✅改命令参数不影响已建立的连接报警阈值✅下一次轮询就用新阈值IO点位配置⚠️ 谨慎新增IO可以删除IO可能导致引用失效IP地址/端口❌改了需要重新建立Modbus连接数据库配置❌改了需要重新连接数据库IP地址不能热加载——改了IP后旧的Modbus连接还连着旧IP。要断开重连才能用新IP。这种配置需要重启程序或者提供专门的重连按钮。配置保存的完整流程操作员在设置界面修改参数后点保存// 1. ViewModel收集UI值config.AutoAllowControlAutoAllowControl;config.ManualAllowControlManualAllowControl;config.TowerLightServiceEnableTowerLightServiceEnable;// 2. 调用ConfigReader写入文件ConfigReader.Instance.WriteConfig(config);// 3. 触发配置变更通知WeakReferenceMessenger.Default.Send(newConfigChangedMessage());// 4. 安全服务收到消息后响应写文件和发消息是两步。写完文件不发消息其他服务不知道配置变了。发消息但不写文件重启后配置丢失。两步缺一不可。踩坑记录坑1防抖时间太短一开始防抖设了100ms结果记事本保存触发了2次事件100ms内第二次事件来了又重新计时。但记事本两次写入间隔可能正好100ms左右偶尔会漏。改成500ms后稳定了。坑2热加载后UI没刷新注册表更新了但命令面板的列表还是旧的。原因是命令面板用的是 ObservableCollection注册表更新后没有清空重新填充。后来加了消息通知命令面板收到消息后重新从注册表拉取数据。坑3热加载时正在执行命令操作员改配置时正好有个命令在执行。热加载后注册表里那个命令可能被删了或改了。解决办法执行中的命令用快照——开始执行时拷贝一份命令配置执行过程中用快照不受热加载影响。本篇小结概念关键做法FileSystemWatcher监听文件变化不用轮询防抖500ms Timer避免多次触发文件占用重试3次间隔100ms部分写入JSON完整性校验不完整则跳过注册表热更新原子替换引用无锁更新变更通知消息机制松耦合不适合热加载IP地址、数据库配置需重启热加载的核心让操作员改配置不用停机但要处理好多次触发、文件占用、部分写入这三个坑。下期预告第16篇界面布局 — Dock面板与多窗口配置系统讲完了下篇回到UI——Dock面板怎么布局多窗口怎么管理区域导航怎么搞。
