для выполнения итерации с for ... do, класс должен иметь GetEnumerator метод. Это, очевидно, возвращает себя (т. е. TObjectList<>) в качестве IEnumerator<TGeometricFigure> интерфейс. После итерации IEnumerator<> освобождается, его счетчик ссылок достигает 0, и objectlist освобождается.

это шаблон, который вы часто видите, скажем, в C#, но там он не имеет этого эффекта, потому что экземпляр класса все еще ссылается, и сборщик мусора не будет прыгать.

в Delphi, однако, это проблема, как вы можете видеть. Я думаю, решение было бы для TObjectList<> иметь отдельный (возможно, вложенный) класс или запись, которая выполняет перечисление, и не возвращать Self (as IEnumerator<>). Но это зависит от автора Spring4D. Вы могли бы довести эту проблему до сведения Стефана Гленке.

обновление

ваши дополнения показывает, что это не совсем то, что происходит. The TObjectList<> (точнее, его предок!--9-->) возвращает отдельный перечислитель, но это делает (IMO совершенно ненужным, даже если список используется в качестве интерфейса с самого начала)_AddRef/_Release и последний является виновником.

Примечание

я вижу несколько утверждений, что в Spring4D класс не должен использоваться как класс. Тогда такие классы не должны выставляться в , но в implementation секция блока вместо этого. Если такие классы открыты, автор должен ожидать пользователя использовать их. И если они могут использоваться как класс, то a for-in loop не должен освобождать контейнер. Одна из них-проблема дизайна: либо экспозиция как класс, либо автоматическое освобождение. Итак, есть ошибка, ИМО.

вы используете for in loop выполнить итерации через коллекцию, что цикл ищет метод в классе под названием GetEnumerator. В Spring4D, для TObjectList<T>, вы в конечном итоге вызывая унаследовал TList<T>.GetEnumerator, который реализуется как:

function TList<T>.GetEnumerator: IEnumerator<T>;
begin
  Result := TEnumerator.Create(Self);
end;

и конструктор для TEnumerator реализуется как:

constructor TList<T>.TEnumerator.Create(const list: TList<T>);
begin
  inherited Create;
  fList := list;
  fList._AddRef;
  fVersion := fList.fVersion;
end;

обратите внимание, что он будет называть _AddRef в списке. В этот момент, ваш TObjetList RefCount идет в 1

С GetEnumerator вызов возвращает интерфейс, когда вы закончите цикл, он освободится. The Destructor реализован следующим образом:

destructor TList<T>.TEnumerator.Destroy;
begin
  fList._Release;
  inherited Destroy;
end;

обратите внимание, что он называет _Release в списке. Если вы используете отладчик, вы заметите, что он уменьшает RefCount из списка до 0, а затем он вызывает _Release, так вот почему ваш список освободившись

если вы удалите цикл for in в исходном коде, вы получите утечку памяти:

Неожиданный Памяти Утечка

произошла неожиданная утечка памяти. Неожиданные небольшие утечки блока:

1 - 12 байт: TGeometricFigure x 6, TMoveArrayManager x 1, неизвестный x 1

21 - 28 байт: TList x 1

29 - 36 байт: TCriticalSection x 1

53 - 60 байт: TCollectionChangedEventImpl x 1, неизвестно x 1

77 - 84 байт: TObjectList x 1

редактировать: только что видел Руди Velthuis ответа. Это не Spring4D жук. Вы должны не используйте коллекции на основе классов Framework. Вы должны использовать интерфейс коллекций. Кроме того, не связано с Spring4D, но в Delphi, вам рекомендуется не смешивать ссылки на интерфейс с ссылками на объекты

классы коллекции Spring4D предназначены для использования с интерфейсами, tobjectlist реализует IList, поэтому, если вы ссылаетесь на него с помощью интерфейса, он будет работать так, как ожидалось.

procedure TForm1.FormCreate(Sender: TObject);
var
  geometricFigures: IList<TGeometricFigure>;
  geometricFigure: TGeometricFigure;
begin
  ReportMemoryLeaksOnShutdown := true;

  geometricFigures := TCollections.CreateObjectList<TGeometricFigure>(true);
  geometricFigures.Add(TCircle.Create(4,2));
  geometricFigures.Add(TCircle.Create(0,4));
  geometricFigures.Add(TRectangle.Create(3,10,4));
  geometricFigures.Add(TSquare.Create(1,5));
  geometricFigures.Add(TTriangle.Create(5,7,4));
  geometricFigures.Add(TTriangle.Create(2,6,3));

  for geometricFigure in geometricFigures do 
  begin
    geometricFigure.ToString();
  end;
end;

создайте свой собственный список TGemoetricFigures, который переопределяет деструктор. Тогда вы можете довольно быстро сказать, кто вызывает деструктор.

type
  TGeometricFigures = class(TObjectList<TGeometricFigure>)
  public
    destructor Destroy; override;
  end;

implementation

{ TGeometricFigures }

destructor TGeometricFigures.Destroy;
begin
  ShowMessage('TGeometricFigures.Destroy was called');
  inherited;
end;

procedure FormCreate(Sender: TObject);
var
  geometricFigures: TGeometricFigures;
  geometricFigure: TGeometricFigure;
begin
  ReportMemoryLeaksOnShutdown := true;

  geometricFigures := TGeometricFigures.Create;
  try
    geometricFigures.Add(TCircle.Create(4,2));
    geometricFigures.Add(TCircle.Create(0,4));
    geometricFigures.Add(TRectangle.Create(3,10,4));
    geometricFigures.Add(TSquare.Create(1,5));
    geometricFigures.Add(TTriangle.Create(5,7,4));
    geometricFigures.Add(TTriangle.Create(2,6,3));

    for geometricFigure in geometricFigures do begin
      geometricFigure.ToString();
    end;
  finally
    //geometricFigures.Free(); -> this line is not required (?)
  end;
end;

Я предполагаю, что что-то внутри geometricFigure.ToString () делает что-то, что не должно происходить, что в качестве побочного эффекта разрушает geometricFigues. Используйте Fastmm4 FullDebugMode, и, вероятно, вы получите больше информации.