在嵌入式系统开发中，系统的稳定性是重中之重。RT-Thread 提供的 syswatch（系统监控）模块，专为解决线程异常阻塞、保障系统持续运行设计。本文将从模块设计理念、核心功能、配置项、工作流程到实际测试，全方位解析 syswatch 模块的实现逻辑与使用方式。
一、模块核心定位
syswatch 是 RT-Thread 下的系统监控组件，核心目标是检测线程异常阻塞，并根据预设策略自动处理异常，避免因单个线程卡死导致整个系统瘫痪。其核心能力包括：
- 实时监控系统线程调度状态，识别长时间阻塞的异常线程；
- 支持三种异常处理策略（系统复位、杀死异常线程、重启异常线程）；
- 集成看门狗（WDT），保障监控模块自身异常时系统仍能复位；
- 提供事件回调机制，便于用户自定义异常处理逻辑。
二、模块核心配置项
syswatch 的行为由syswatch_config.h中的宏定义配置，核心配置项如下：
| 配置项 | 默认值 | 说明 |
|---|---|---|
SYSWATCH_EXCEPT_RESOLVE_MODE | 2 | 异常处理模式：0 = 系统复位；1 = 杀死异常线程；2 = 先杀死再重启异常线程 |
SYSWATCH_EXCEPT_TIMEOUT | 60s | 线程异常判定超时（线程阻塞超过该时间即判定为异常） |
SYSWATCH_EXCEPT_CONFIRM_TMO | 15s | 异常线程确认超时（二次确认避免误判） |
SYSWATCH_EXCEPT_RESUME_DLY | 15s | 模式 2 下重启异常线程的延迟时间 |
SYSWATCH_THREAD_PRIO | 0 | 监控线程优先级（建议设为系统最高） |
SYSWATCH_THREAD_STK_SIZE | 512 | 监控线程栈大小 |
SYSWATCH_WDT_TIMEOUT | 5s | 看门狗超时时间（监控模块喂狗周期小于该值） |
配置项通过PKG_USING_SYSWATCH宏开启，可根据实际场景调整（例如资源紧张的系统可减小栈大小，高可靠性场景可缩短看门狗超时）。
三、核心数据结构与接口
1. 核心数据结构
syswatch 模块的核心状态由syswatch_data_t管理：
typedef struct{ rt_bool_t init_ok; // 初始化完成标志 rt_uint16_t sec_cnt; // 秒级计数器（用于超时判定） rt_uint16_t op_step; // 操作步骤：0=等待异常；1=确认异常；2=重启线程（仅模式2） syswatch_event_hook_t event_hook; // 异常事件回调函数 rt_device_t wdt; // 看门狗设备句柄 rt_thread_t lowest_thread; // 检测到的最低优先级异常线程 rt_slist_t wait_resume_slist; // 待重启线程链表（仅模式2） struct rt_event event; // 事件对象（处理重启/停止指令） syswatch_reboot_callback_t reboot_callback; // 系统重启前回调 }syswatch_data_t;2. 对外核心接口
模块对外暴露的接口定义在syswatch.h，核心接口如下：
| 接口 | 功能 |
|---|---|
syswatch_init() | 初始化监控模块（创建监控线程、初始化看门狗 / 事件） |
syswatch_set_event_hook() | 设置异常事件回调（例如记录异常日志、上报告警） |
syswatch_setrecallback() | 设置系统重启前的自定义回调 |
syswatch_reboot() | 主动触发系统重启（支持 MSH 命令：reboot） |
syswatch_stop() | 停止看门狗（支持 MSH 命令：wdtstop） |
四、核心工作流程
syswatch 模块的核心逻辑分为线程异常检测、异常处理、看门狗守护三部分，以下拆解关键流程：
1. 初始化流程
syswatch_init()是模块入口，执行以下操作：
- 初始化事件对象（用于处理重启 / 停止指令）；
- 创建并启动监控线程（优先级最高，栈大小可配置）；
- 初始化看门狗设备，设置超时并启动喂狗；
- 注册线程调度钩子函数（
syswatch_thread_switch_hook），用于监控线程调度状态。
2. 异常线程检测
异常检测的核心是线程调度钩子 + 超时计数器：
- 调度钩子
syswatch_thread_switch_hook：监控线程切换行为，记录系统当前运行的最低优先级线程（排除 idle 线程）； - 超时计数器
sec_cnt：每秒递增，若系统长时间未切换到 idle 线程（即某线程持续占用 CPU），且超时超过SYSWATCH_EXCEPT_TIMEOUT，则判定为线程异常； - 二次确认：异常判定后，进入 15 秒确认期（
SYSWATCH_EXCEPT_CONFIRM_TMO），避免瞬时调度波动导致误判。
3. 异常处理策略
根据SYSWATCH_EXCEPT_RESOLVE_MODE配置，支持三种策略：
策略 0：系统复位（SYSWATCH_EXCEPT_RESOLVE_MODE=0）
- 触发条件：检测到异常线程且确认超时；
- 处理逻辑：调用事件回调 → 延迟 100ms → 执行 CPU 硬复位；
- 适用场景：关键线程异常，需快速恢复系统整体可用性。
策略 1：杀死异常线程（SYSWATCH_EXCEPT_RESOLVE_MODE=1）
- 触发条件：检测到异常线程且确认超时；
- 处理逻辑：调用事件回调 → 区分系统线程 / 用户线程，分别执行 detach/delete 操作；
- 适用场景：非核心线程异常，杀死后不影响系统核心功能。
策略 2：杀死并重启异常线程（SYSWATCH_EXCEPT_RESOLVE_MODE=2）
- 触发条件：检测到异常线程且确认超时；
- 处理逻辑：
- 保存异常线程的关键信息（入口函数、栈大小、优先级等）到链表；
- 执行策略 1 的 “杀死线程” 逻辑；
- 延迟
SYSWATCH_EXCEPT_RESUME_DLY后，从链表恢复并重启所有异常线程；
- 适用场景：需要自动恢复的业务线程（如数据采集、通信线程）。
4. 看门狗守护机制
为避免监控模块自身异常（如监控线程卡死），模块集成看门狗：
- 监控线程每秒执行
syswatch_wdt_feed()喂狗； - 若监控线程卡死，看门狗超时（
SYSWATCH_WDT_TIMEOUT）触发系统复位； - 支持
syswatch_stop()手动停止看门狗（调试场景）。
五、测试模块解析
syswatch 提供syswatch_test.c测试用例，用于验证异常处理逻辑：
- 测试命令：
syswatch_test <优先级> [延迟秒数]，创建指定优先级的测试线程； - 测试逻辑：
- 测试线程启动后，延迟指定时间进入死循环（模拟异常）；
- 模式 2 下，线程重启后会清除标记，10 秒后正常退出；
- 模式 0/1 下，线程死循环后触发对应异常处理策略。
示例测试流程：
# 创建优先级10、延迟30秒异常的测试线程 msh > syswatch_test 10 30 # 日志输出：30秒后线程进入死循环 → 60秒异常判定 → 模式2下杀死并重启线程 → 重启后10秒线程退出六、使用建议与注意事项
1. 配置优化建议
- 优先级：监控线程优先级（
SYSWATCH_THREAD_PRIO）建议设为 0（最高），确保监控不被其他线程抢占； - 超时时间：
SYSWATCH_EXCEPT_TIMEOUT建议根据业务调整（如非实时场景设为 30s，实时场景设为 10s）； - 看门狗：务必确保看门狗设备驱动已适配，避免监控模块 “失效”。
2. 自定义扩展
- 事件回调：通过
syswatch_set_event_hook()注册回调，记录异常线程的名称、优先级、时间等日志，便于问题定位； - 重启回调：通过
syswatch_setrecallback()实现重启前的资源清理（如保存关键数据、关闭外设）。
3. 注意事项
- 模式 2 下，重启线程依赖堆内存（
rt_malloc），需确保系统开启堆且内存充足； - 避免监控线程自身异常：监控线程栈大小需足够（默认 512），禁止在回调函数中执行长时间阻塞操作；
- 系统线程（如 idle、timer 线程）异常时，模式 1/2 可能导致系统不稳定，建议模式 0 直接复位。
七、总结
syswatch 模块是 RT-Thread 保障系统稳定性的重要组件，其设计兼顾了 “检测精准性” 与 “处理灵活性”：通过线程调度钩子实现无侵入式异常检测，支持三种差异化的处理策略，集成看门狗保障自身可靠性。在实际项目中，合理配置参数并结合自定义回调，可大幅提升嵌入式系统的容错能力，降低因线程异常导致的系统宕机风险。
无论是工业控制、物联网终端还是消费电子，syswatch 都能作为系统的 “安全卫士”，为嵌入式应用的稳定运行保驾护航。
