Исправление утечек памяти в Delphi: правильное управление объектами и потоками

Delphi , Синтаксис , Память и Указатели

Утечки памяти в программировании на Delphi могут возникать по разным причинам, одной из которых является неправильное управление объектами и потоками. В статье мы рассмотрим конкретный пример, который приводит к утечке памяти, и предложим способы его решения.

Проблема утечки памяти

В коде, представленном ниже, используется класс TMyClass, который создает два объекта o1 и o2 в конструкторе. Однако в деструкторе TMyClass происходит попытка освобождения этих объектов, даже если один из них уже был освобожден внутри потока через функцию FreeMyObject, вызываемую по сообщению.

unit Unit7;

interface

uses Classes;

type
  TListener = class(TThread)
    procedure Execute; override;
  end;

  TMyClass = class
    o1, o2: TObject;
    procedure FreeMyObject(var obj: TObject);
    constructor Create;
    destructor Destroy; override;
  end;

implementation

uses Windows, SysUtils;

type
  PObject = ^TObject;

var
  l: TListener;
  my: TMyClass;

procedure TListener.Execute;
var
  msg: TMsg;
begin
  while GetMessage(msg, Cardinal(-1), 0, 0) do
    if (msg.Message = 6) then begin
      TMyClass(msg.WParam).FreeMyObject(PObject(msg.LParam)^);
      Exit;
    end;
end;

constructor TMyClass.Create;
begin
  inherited;
  o1 := TObject.Create;
  o2 := TObject.Create; // Создание объектов
end;

destructor TMyClass.Destroy;
begin
  if Assigned(o1) then o1.Free;
  if Assigned(o2) then o2.Free; // Попытка освобождения уже освобожденного объекта
  inherited;
end;

procedure TMyClass.FreeMyObject(var obj: TObject);
begin
  FreeAndNil(obj);
end;

initialization
  l := TListener.Create;
  my := TMyClass.Create;

  Sleep(1000); // Убедиться, что сообщение потока запущено
  PostThreadMessage(l.ThreadID, 6, Integer(my), LPARAM(@my.o2));
finalization
  l.Free;
  my.Free;
end.

Описание проблемы и контекст

Автор кода столкнулся с проблемой утечки памяти, вызванной попыткой освобождения уже освобожденного объекта o2. Это происходит из-за того, что в методе Execute потока TListener получает указатель на объект, который затем освобождается, но в деструкторе TMyClass происходит дополнительное освобождение объектов o1 и o2, что приводит к двойному освобождению и, как следствие, к исключению недопустимой операции с указателем.

Подтвержденный ответ

Проблема заключается в том, что в методе Execute потока TListener объект o2 освобождается через FreeAndNil, но в деструкторе TMyClass он также пытается освободиться, так как ссылка на него не была обнулена. Чтобы решить эту проблему, необходимо передать потоку указатель на указатель объекта o2, чтобы можно было изменить его значение на nil и избежать двойного освобождения.

// В методе Execute
if (msg.Message = 6) then begin
  TMyClass(msg.WParam).FreeMyObject(PObject(msg.LParam)^);
  Exit;
end;

// В конструкторе класса
type
  PObject = ^TObject;

// В методе FreeMyObject класса TMyClass
procedure TMyClass.FreeMyObject(var obj: PObject);
begin
  if Assigned(obj^) then
    FreeAndNil(obj^);
end;

// Изменение вызова PostThreadMessage
PostThreadMessage(l.ThreadID, 6, Integer(my), LPARAM(@my.o2));

Теперь, когда FreeMyObject получает указатель на указатель, он может обнулить его, и в деструкторе TMyClass освобождение объектов не будет производиться, если указатель уже равен nil.

Альтернативный ответ

Другой способ решения проблемы - использование идентификаторов объектов вместо передачи ссылок. Это позволяет избежать проблемы с передачей по значению и двойным освобождением:

type
  TObjectIdentifier = record
    FInstance: TObject;
    FField: Integer;
    constructor Create(const AInstance: TObject; const AField: Integer);
    procedure Free;
  end;

constructor TObjectIdentifier.Create(const AInstance: TObject; const AField: Integer);
begin
  FInstance := AInstance;
  FField := AField;
end;

procedure TObjectIdentifier.Free;
begin
  case FField of
    1: FInstance.o1.Free;
    2: FInstance.o2.Free;
  end;
end;

procedure TMyClass.FreeObject(const Identifier: TObjectIdentifier);
begin
  Identifier.Free;
end;

// В методе Execute
PostThreadMessage(l.ThreadID, 6, Integer(my), LPARAM(TObjectIdentifier(@my.o2, 2).SizeOf));

В этом случае, если нужно освободить объект o2, передаем идентификатор, который в своем методе Free определяет, какой объект нужно освободить. Это позволяет избежать передачи ссылки на объект и избежать двойного освобождения, так как в деструкторе TMyClass уже не происходит проверка на Assigned(o2).

Заключение

Для исправления утечек памяти важно понимать, как объекты и потоки взаимодействуют друг с другом и как управлять их жизненным циклом. В данном примере мы рассмотрели два способа решения проблемы: изменение метода передачи данных потоку и использование идентификаторов объектов. Выбор метода зависит от конкретной архитектуры приложения и предпочтений разработчика.

Создано по материалам из источника по ссылке.

Утечки памяти в Delphi могут быть вызваны неправильным управлением объектами и потоками, особенно при попытке двойного освобождения уже освобожденных объектов.

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Память и Указатели ::