2

由于该进程将被操作系统杀死，并且无论如何分配的所有内存都将被回收，因此可以不在单元完成部分释放对象/资源吗？

例如，

unit Threading;

interface

implementation

  var threadpool: ThreadPool;

initialization

  threadpool := ThreadPool.Create;

finalization

  threadpool.Free; // is it OK to remove this?

end.
4

3 回答 3

9

由于该进程将被操作系统杀死，并且无论如何分配的所有内存都将被回收，因此可以不在单元完成部分释放对象/资源吗？

是的，可能是。进程终止时系统会清理资源。

但是，有几个附带条件：

  1. 大多数泄漏检测工具会在将控制权返回给系统之前检查进程是否销毁了所有动态分配的内存。你打算做什么使这些工具无能为力。
  2. 如果您的代码曾经内置到动态库（例如 DLL 或包）中，则可以卸载该库，而主机进程会持续存在。这是一个泄漏，可能会影响主机进程的可行性。
  3. 有些对象需要完成，有时需要排序约束。在不了解您的班级的情况下，我们无法判断。
于 2015-10-15T11:57:06.557 回答
5

如果Free从终结部分中删除调用，那么threadpool它的所有子对象将始终出现在应用程序的内存泄漏报告中。那时很难找到真正的内存泄漏。

某些对象可能会在销毁时执行日志记录操作或删除锁定文件。所以可能需要执行所有的析构函数。

作为（Delphi）开发人员，您应该始终注意清理堆。否则你可能会失去对内存管理的控制。重新获得控制权可能会花费您或您的公司大量资金。

于 2015-10-15T11:49:13.820 回答
1

是的，没关系，但是：

1）您可以使用以下构造：

ThreadPool := ThreadPool.Create;
RegisterExpectedMemoryLeak(ThreadPool);

这种方法使您免于强制明确的单元引用顺序（因此该单元不会在使用它的单元之前取消初始化）。

2）否则你可以 nil 变量（或者如果你想要 System.SysUtils 依赖，可以使用 FreeAndNil ）：

finalization
  ThreadPool.Free;
  ThreadPool := nil;

通过这种方式，您可以轻松找到发布时正在访问 ThreadPool 的人员。

3）您可以将 TInterfacedObject 用于源类的实现或包装。

于 2015-10-15T13:16:40.903 回答