如何解读FastMM4的MemoryManager_EventLog.txt？TList内存泄漏疑问

嘿，针对你遇到的这个问题——明明调用了TList.Free，但FastMM还是检测到TList对象本身的内存泄漏，咱们结合你的调用栈和Delphi的内存管理逻辑，来梳理几个最可能的原因：

• 创建后的TList没被正确执行Free操作
  从你的调用栈来看，这个泄漏的TList是在TPrint.CreateCollection方法中创建的。你需要重点检查：

  1. Free语句是否覆盖了所有代码路径？比如如果创建TList后，某个if...else分支没有走到Free逻辑，或者中间代码抛出异常导致Free被跳过。
  2. 是否用try...finally包裹了TList的创建与使用？如果没有，一旦中间代码触发未捕获的异常，Free语句就不会执行，直接造成泄漏。正确的写法应该是：

     var
       MyList: TList;
     begin
       MyList := TList.Create;
       try
         // 对MyList的业务操作
       finally
         MyList.Free; // 无论是否异常，都会执行释放
       end;
     end;
     

• TList的指针被意外覆盖，原实例丢失
  如果在创建TList后，你的代码把持有该TList的指针重新赋值给了其他对象（比如MyList := AnotherList;），那原来的TList实例就没有指针指向它了，自然无法调用Free，最终造成泄漏。你可以检查CreateCollection方法中，TList的赋值逻辑是否存在这类覆盖情况。

• 多线程环境下的竞态问题
  如果这个TList涉及多线程操作，要注意：

  1. 释放TList的线程是否和使用它的线程做好同步？如果释放时还有线程在访问这个TList，可能会导致内存管理异常，甚至泄漏检测的误报（不过FastMM的检测通常是准确的）。
  2. 确保TList的创建和释放都在正确的线程生命周期内，比如线程退出时要保证所有创建的对象都被释放。

• TList被其他长生命周期对象持有引用
  检查这个TList是否被赋值给了全局对象、窗体成员变量，或者其他生命周期更长的对象属性。如果这些持有引用的对象本身没被释放（比如全局对象直到程序退出才释放，但FastMM在窗体关闭时就检测泄漏），也会被判定为泄漏。比如如果你的TList被赋值给了全局TNetwork实例的成员，而TNetwork直到程序结束才释放，那窗体关闭时FastMM就会检测到这个TList的泄漏。

排查小技巧 #

你可以自定义一个继承自TList的类，在构造和析构函数中添加日志输出（或者设置断点），替换原来的TList使用：

type
  TTrackedList = class(TList)
  public
    constructor Create; override;
    destructor Destroy; override;
  end;

constructor TTrackedList.Create;
begin
  inherited;
  // 输出创建日志，比如记录当前线程、调用栈等
  Writeln('TTrackedList created at: ', BackTraceStrFunc(ReturnAddress));
end;

destructor TTrackedList.Destroy;
begin
  Writeln('TTrackedList destroyed');
  inherited;
end;

这样就能明确看到这个泄漏的TList实例是否被正确执行了析构函数，进而定位问题所在。

内容的提问来源于stack exchange，提问作者ar099968