MT5 EA内存溢出排查实战：日志分析与资源监控优化指南
MT5 EA内存溢出排查实战：日志分析与资源监控优化指南
上周三凌晨两点，微信弹出一条消息，是老陈。他跑了一个多月的MT5黄金EA突然开始作妖——订单执行延迟从80毫秒飙到1.2秒，有两笔加仓单直接没发出去。他重启了VPS，恢复正常，第二天下午又犯。他把日志发给我，我扫了一眼就问他：你这EA是不是用了全局数组缓存Tick数据，还忘了清理？他愣了三秒，回了个「卧槽」。
这就是典型的MT5 EA内存泄漏。跟MT4不一样，MT5是64位架构，理论上单进程能吃下海量内存，但正因为这个「宽容度」，很多写MQL5的人对内存管理极其随意。MQL4时代养成的坏习惯移植过来，跑回测没事，一上实盘连续运行几十个小时，问题就炸了。
先搞清楚：MT5里到底什么在吃内存
很多人一说内存溢出就去看VPS的物理内存占用，方向偏了。MT5 EA的内存消耗分三层：终端进程本身、EA实例、以及指标和图形对象。你需要先定位是哪一层出的问题。
最直接的判断方法：打开MT5的「导航器」→右键EA→「修改」，在「日志」标签里观察。更精确的做法是在EA的OnTimer里加一段资源自检代码：
- TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) —— 终端可用物理内存
- TerminalInfoInteger(TERMINAL_MEMORY_USED) —— 终端已用物理内存
- TerminalInfoInteger(TERMINAL_MEMORY_TOTAL) —— 系统总物理内存
我通常让EA每60秒把这三个值连同GetTickCount()写进自定义日志文件。跑一个交易日下来，把日志导进Excel画个曲线，内存是平稳、阶梯上升还是锯齿波动，一目了然。阶梯上升基本就是泄漏，锯齿波动多半是数组或对象没释放。
日志分析：别只看Print，要看时间戳密度
MT5的Experts日志默认只记录EA的Print输出和交易操作，但内存溢出的前兆往往藏在时间戳的间隔变化里。我的习惯是：把日志按秒聚合，统计每秒的日志条数。正常运行时，一个中等频率的EA每秒也就几条；当内存开始吃紧，MT5的日志写入线程会被拖慢，出现「日志堆积」——某一秒突然冒出几十条，然后空白几秒。
具体操作：日志文件在 MQL5/Logs/ 目录下，用Python或Excel按时间列做透视。如果你发现日志条目在某个时间点后密度骤增，同时伴随订单发送延迟（用OrderSend的返回值时间戳减去调用时间戳），那基本可以锁定是EA内部数据结构膨胀导致的。
常见错误：很多人只盯着「内存不足」的报错，但MT5在真正OOM之前，会先出现「数组越界」或「无效指针」的警告。这些警告在日志里一闪而过，不刻意搜根本注意不到。建议在EA里加一个OnTradeTransaction回调，把每笔交易的执行耗时写进日志，超过500毫秒就标红。
三种最常见的泄漏源，以及我踩过的坑
第一种：动态数组只增不减。MQL5的ArrayResize很方便，但很多人忘了ArrayFree。我见过一个EA用数组缓存最近1000根K线的Tick数据，每来一个新Tick就Resize加1，结果跑了两天数组长度到了几十万，内存直接吃掉2个G。修复方法很简单：用环形缓冲区，固定长度，覆盖写入。
第二种：图形对象和指标句柄没释放。每次OnTick都Create一个水平线或箭头，却从不ObjectsDeleteAll。一个黄金EA在M1图表上跑，一天能创建上万条线，MT5的图形层直接卡死。正确做法是在OnDeinit里统一清理，或者用对象池复用。
第三种：递归调用或循环里的字符串拼接。MQL5的字符串操作是隐式分配内存的，在循环里做StringConcatenate，每次都会产生临时对象。我测试过一个网格EA，把订单注释拼接放在OnTick里，回测时盈利因子从1.5掉到0.8，改成预分配字符数组后恢复正常。
这里给一个环形缓冲区的核心片段：
int idx = 0;
double tickBuffer[1000];
void OnTick() {
tickBuffer[idx] = SymbolInfoDouble(_Symbol, SYMBOL_BID);
idx = (idx + 1) % 1000;
}
注意：ArrayResize在循环里频繁调用会触发内存碎片，MQL5的堆管理不如C++精细，碎片多了照样OOM。
资源监控：VPS上该盯哪几个数
VPS选型不是本文重点，但内存排查绕不开它。Windows Server 2016/2019下，MT5终端进程（terminal64.exe）的私有工作集（Private Working Set）是核心指标。用性能监视器加三个计数器：Process\Private Bytes、Process\Handle Count、Memory\Available MBytes。
我的经验阈值：一个单品种EA，私有工作集稳定在200-400MB算正常；超过800MB就要警惕；Handle Count持续增长不回落，说明有句柄泄漏。XM的MT5服务器在伦敦和纽约都有节点，延迟低，但如果你EA的内存占用高，VPS的CPU反而会成为瓶颈——因为MT5的垃圾回收是单线程的。
Exness的品种命名有个细节：他们的黄金是XAUUSDm（美分账户）和XAUUSD（标准账户），合约大小不同。如果你在美分账户上跑EA，手数计算要除以100，但内存占用不会因为手数变小而降低。我见过有人在美分账户上跑高频EA，以为手数小就安全，结果内存照样爆。
优化手段：从代码到部署的四个动作
第一，把OnTick里的重型计算挪到OnTimer。MQL5的OnTimer独立线程，不阻塞报价处理。把指标计算、数组整理、日志写入都放进去，OnTick只做下单判断。
第二，用ArraySetAsSeries和ArrayFree配对。每次处理完历史数据数组，立刻释放。不要指望MT5自动回收，它的GC很懒。
第三，限制图形对象数量。在EA参数里加一个MaxObjects，超过就删最旧的。我一般设500。
第四，回测时开启「可视化模式」观察内存曲线。MT5的回测报告里有「内存使用」图表，很多人不看。我测试过一个EA，默认参数下内存峰值1.2GB，把数组长度从5000降到1000后，峰值降到380MB，盈利因子从0.9提升到1.4。这不是策略逻辑变了，是执行效率上来了。
最后提醒一个新手最容易忽略的环节：EA的OnDeinit里没写清理代码。你以为EA停止时MT5会帮你收尾，但图形对象、全局变量、文件句柄都不会自动释放。下次加载同一个EA，旧对象还在，内存越积越多。养成习惯，OnDeinit里把ObjectsDeleteAll、FileClose、ArrayFree全写一遍。就这一条，能省掉你80%的诡异问题。
你在部署EA时遇到过内存持续增长但日志无报错的情况吗？留言说说你的排查路径。
免责声明：本文仅代表作者观点，不构成任何投资建议。市场有风险，交易需谨慎。