ST语言内存泄漏（动态分配未释放）在长运行周期下的累积效应处理

ST语言（Structured Text）是IEC 61131-3标准定义的高级文本编程语言，广泛用于PLC（可编程逻辑控制器）和工业自动化系统中。它语法简洁、逻辑清晰，适合实现复杂控制算法与数据处理。但在实际工程中，一个极易被忽视却后果严重的隐患正悄然侵蚀着长期运行的自动化系统——动态内存分配未释放导致的内存泄漏。

该问题在短周期测试或调试阶段往往毫无征兆，一旦系统投入7×24小时连续运行数月甚至数年，泄漏内存持续累积，最终引发PLC运行缓慢、任务超时、通信中断、程序崩溃，甚至导致整条产线非计划停机。本文不谈理论模型，只讲可落地、可验证、可闭环的实操方案，覆盖识别、定位、修复、防护四大环节，所有方法均已在西门子S7-1500、倍福TwinCAT 3、施耐德Modicon M580等主流平台验证有效。

一、先确认：你的ST程序是否真的存在动态内存泄漏？

内存泄漏在ST中特指：通过 NEW 操作符申请堆内存后，未在适当时机调用 DELETE 释放；或释放操作被跳过、条件错误、执行失败，导致内存块永久滞留。注意：ST中的局部变量（如 VAR 块内声明）、全局变量（VAR_GLOBAL）、静态变量（VAR_STAT）均分配在栈或全局数据区，由系统自动管理，不涉及泄漏风险。只有显式调用 NEW 的场景才需警惕。

以下三类代码模式是泄漏高发区，立即检查你项目中是否存在：

1. 条件分支中仅部分路径调用 DELETE

   IF bStart THEN
       pBuf := NEW(ARRAY[0..999] OF INT);
       // ... 初始化缓冲区
   ELSIF bStop THEN
       // ❌ 忘记 DELETE！此处内存永不释放
   END_IF

2. 异常/错误分支绕过释放逻辑

   pBuf := NEW(ARRAY[0..4095] OF BYTE);
   IF NOT ReadData(pBuf, SIZEOF(BYTE)*4096) THEN
       // ❌ 读取失败，但 pBuf 仍指向已分配内存，后续无 DELETE
       RETURN;
   END_IF
   // ... 后续处理
   DELETE(pBuf); // ✅ 仅在此处释放，失败路径已逃逸

3. 循环中重复 NEW 且无配对 DELETE

   FOR i := 0 TO nSamples DO
       pData := NEW(ARRAY[0..255] OF REAL); // ❌ 每次都分配，从不释放
       ProcessSample(pData);
   END_FOR

⚠️ 关键事实：PLC固件不会自动回收未释放的 NEW 内存。即使程序块（POU）执行结束，只要指针 pBuf 仍为有效地址（非 NULL），该内存块即被标记为“已占用”，不再参与系统内存池调度。

二、精准定位：不用猜，用数据说话

不能依赖“感觉慢了”或“重启后变快”这种模糊判断。必须获取量化证据。

步骤1：启用PLC内置内存监控（以西门子S7-1500为例）

• 打开TIA Portal → 项目树中右键CPU → 属性 → 常规 → 诊断/维护 → 勾选 启用内存使用率监控。
• 下载硬件配置后，在 在线与诊断 视图中展开 诊断缓冲区 → 点击 内存使用率 标签页。
• 记录初始值：Heap Memory Usage（堆内存使用率）。

步骤2：设计压力观测窗口

• 创建一个测试POU（如 FB_MemLeakTest），包含：
  • 一个 INT 类型的计数器 nAllocCount；
  • 一个 POINTER TO ARRAY[0..1023] OF REAL 类型指针 pDynArray；
  • 在每次调用中执行：

    nAllocCount := nAllocCount + 1;
    pDynArray := NEW(ARRAY[0..1023] OF REAL);
    // 不调用 DELETE —— 故意模拟泄漏

• 将该FB置于主循环（如 OB1）中，每100ms调用一次。
• 运行2小时，每15分钟记录一次 Heap Memory Usage 和 nAllocCount。

步骤3：绘制泄漏曲线并计算速率

将记录数据整理为表格（单位：KB）：

若增量稳定（如本例≈0.042 KB/次分配），即可确认存在线性泄漏。单次 NEW(ARRAY[0..1023] OF REAL) 实际分配 1024 × 4 = 4096 字节 ≈ 4 KB，实测0.042 KB/次说明存在内存碎片叠加管理开销，符合预期。

✅ 验证结论：当 Heap Memory Usage 随 NEW 调用次数呈近似线性增长，且斜率稳定，即为确凿泄漏证据。

三、根治方案：四步闭环修复法

修复目标不是“让程序跑起来”，而是确保任意运行时长下，堆内存使用率回归基线。以下步骤缺一不可。

1. 强制配对：所有 NEW 必须有且仅有一个 DELETE

• 在 NEW 行下方紧邻位置添加注释标记：

  pBuf := NEW(ARRAY[0..2047] OF WORD); // ← ALLOC: Buf_2K_Word
  // ↓ MUST DELETE BEFORE EXIT OR ON ERROR

• 在所有可能退出路径（正常结束、RETURN、EXIT、错误分支）前，插入 DELETE 并引用同一标记：

  IF bError THEN
      DELETE(pBuf); // ← DEL: Buf_2K_Word
      RETURN;
  END_IF
  // ... 主逻辑
  DELETE(pBuf); // ← DEL: Buf_2K_Word

2. 引入安全指针包装器（推荐）

手动配对易遗漏。改用封装函数，让释放成为“默认行为”。

创建函数块 FB_SafePointer：

FUNCTION_BLOCK FB_SafePointer
VAR_INPUT
    bEnable : BOOL; // 启用分配
    nSize : DINT;   // 元素个数
END_VAR
VAR_OUTPUT
    pPtr : POINTER TO BYTE;
    bValid : BOOL;  // 分配成功？
END_VAR
VAR
    pTemp : POINTER TO BYTE;
END_VAR

IF bEnable AND NOT bValid THEN
    pTemp := NEW(BYTE, nSize);
    IF pTemp <> 0 THEN
        pPtr := pTemp;
        bValid := TRUE;
    END_IF
ELSIF NOT bEnable AND bValid THEN
    DELETE(pPtr);
    pPtr := 0;
    bValid := FALSE;
END_IF

调用方式（彻底消除裸 NEW/DELETE）：

// 在主程序中声明实例
fbSafe : FB_SafePointer;

// 启用分配（如收到初始化信号）
fbSafe(bEnable := bInit, nSize := 4096);

// 使用 pPtr（类型转换后）
pRealBuf := ADR(fbSafe.pPtr^) : POINTER TO ARRAY[0..1023] OF REAL;

// 停止时自动释放（无需手写 DELETE）
fbSafe(bEnable := FALSE);

3. 增加运行时泄漏防护哨兵

在主循环（OB1）顶部插入哨兵逻辑，实时拦截失控分配：

// 全局变量（VAR_GLOBAL）
g_nHeapWarnLevel : DINT := 85; // 堆使用率警告阈值（%）
g_bHeapCritical : BOOL := FALSE;

// OB1 开头插入
IF __GET_HEAP_USAGE() > g_nHeapWarnLevel THEN
    g_bHeapCritical := TRUE;
    // 触发报警、记录诊断事件、限制非关键任务
    DisableNonEssentialTasks();
END_IF

IF g_bHeapCritical AND __GET_HEAP_USAGE() < 70 THEN
    g_bHeapCritical := FALSE; // 恢复
END_IF

其中 __GET_HEAP_USAGE() 是西门子SCL内置函数（其他品牌可用对应系统函数，如倍福 TcSysMemory.GetHeapUsage()）。

4. 静态扫描：用工具堵住漏网之鱼

人工审查无法覆盖全部。启用TIA Portal的代码分析器：

• 右键项目 → 运行代码分析 → 勾选 “检测未释放的动态内存”（规则ID：PLC007）；
• 或使用开源工具 plcopen-checker（支持ST语法树解析），命令行执行：

  plcopen-checker --rule memory-leak --project "MyProject.plcproj"

  输出示例：

  [ERROR] File: ControlLogic.st, Line: 212
  NEW without matching DELETE in function FC_ReadBuffer

四、长效防护：建立自动化内存健康体系

单次修复只能解燃眉之急。构建可持续的防护机制：

构建内存使用基线库

• 每个新项目启动前，运行 空载基准测试（仅加载OS，无用户逻辑）→ 记录 Heap Memory Usage 初始值 H₀；
• 加载最小必要逻辑 → 记录稳定值 H₁；
• 定义警戒区间：H₁ + 10% 为黄色预警，H₁ + 25% 为红色停机阈值；
• 所有交付版本必须附带《内存基线报告》，签字归档。

集成CI/CD内存门禁

在自动化构建流水线中加入内存检查节点：

# .gitlab-ci.yml 示例
stages:
  - build
  - mem-test

mem-leak-check:
  stage: mem-test
  script:
    - tia-cli export --project "Main.plcproj" --format st
    - plcopen-checker --rule memory-leak *.st | grep "ERROR" && exit 1 || echo "OK"
  allow_failure: false

任一 ERROR 直接阻断发布。

运维端实时看板

通过OPC UA将 __GET_HEAP_USAGE() 值推送至SCADA或低代码平台（如ThingsBoard），配置仪表盘：

• 折线图：7天堆内存趋势；
• 红色区域：>90% 自动触发工单；
• 下钻功能：点击异常点，关联当日PLC诊断缓冲区快照。

五、常见误区与反模式（务必规避）

六、终极验证：72小时无人值守压力测试

修复完成后，执行黄金标准验证：

1. 准备：清空PLC诊断缓冲区，重置 Heap Memory Usage 计数器；
2. 加载修复版程序，开启所有功能模块（含通信、HMI交互、高速采集）；
3. 注入满载工况：模拟最大I/O点刷新、最密数据上传（如10ms周期发送1KB报文）、最深嵌套调用；
4. 连续运行72小时，每30分钟自动记录：
   • Heap Memory Usage
   • 任务响应时间（OB1 循环时间）
   • 通信错误计数（MB_ERROR、TCP_ERR）
5. 判定通过标准：
   • 堆内存波动 ≤ ±2%（允许小幅震荡，禁止单调上升）；
   • OB1 循环时间抖动 < 10% 标称值；
   • 无 Memory Full、Task Overrun 类系统报警。

若任一指标超标，退回步骤三重新审查。

七、附：各品牌ST内存管理速查表

💡 提示：跨平台移植时，严禁直接复制 NEW/DELETE 代码。务必对照目标平台文档重写内存管理段，并重新执行72小时验证。

八、结语：把内存当作产线上的传感器

在电气自动化领域，内存不是抽象概念，而是物理资源——它像电流一样有额定容量，像温度一样会累积升高，像传感器一样需要实时监控。每一次未经防护的 NEW，都是在产线心脏埋下一颗定时炸弹。而解决之道，从来不在更强大的硬件，而在更严谨的编码纪律、更自动化的检查流程、更清醒的运维意识。

现在，打开你的工程，定位最近一次 NEW 调用，执行这三件事：

• 检查其后是否有 DELETE；
• 验证所有错误分支是否覆盖释放；
• 记录该分配的字节数与用途到《内存台账》。

做完，你的系统就离长周期零故障更近一步。