在VB6/VBA中是否真的需要对象清除/数组释放(优点/缺点？)

Question

我从VB中学到的很多东西都是从静态代码分析(特别是Aivosto的项目分析器)中学到的.它检查的一件事是你是否清除了所有对象和数组.我曾经盲目地这样做,因为PA这么说.但是现在我对VB释放资源的方式了解得更多,在我看来,这些事情应该自动发生.这是VB6之前的遗留功能,还是有理由将对象显式设置为空,并在阵列上使用Erase？

Answer 1

高级Visual Basic 6的作者Matt Curland 比我们大多数人都更了解Visual Basic,他认为这是浪费精力.考虑这个关于DAO的引用(p110),DAO是主要以Access数据库引擎为目标的COM数据访问库:

另一个糟糕的拆解代码示例.DAO具有必须以正确顺序调用的Close方法,并且对象也必须以正确的顺序释放(例如,在Database之前的Recordset).这种单一的不良对象模型行为导致了VB泄漏内存的误解,除非您在函数末尾显式地将所有局部变量设置为空.在精心设计的对象模型中,这是一个完全错误的概念.VB可以在End Sub行中更快地清除变量,而不是从代码中清除变量,即使您明确发布了引用,它也会检查变量.你所做的任何努力都是重复的.

Answer 2

据我了解，这个问题与 VB6（及其前身）植根于 COM 及其引用计数垃圾收集系统这一事实有关。

例如，想象一下，您声明对第三方库中的对象的引用。该对象有一个 COM 引用计数，用于使其保持活动状态并确定何时应将其销毁。当您将其设置为 Nothing 时，它不会被销毁，但当对象的引用计数达到零时。

现在，并非所有 COM 组件都是用 Visual Basic 编写的。有些是用 C 或 C++ 编写的。并非所有语言都存在结构化异常处理。因此，如果发生错误，则不能保证对象上的引用计数适当减少，而且 COM 对象的停留时间比预期的要长。这对于 Visual Basic 本身来说不是问题。这是 COM 问题。（您可能会注意到，这就是 .NET 不使用引用计数的原因。）

这就是为什么 Visual Basic 开发人员热衷于在退出例程之前释放对象引用。您根本不知道您分配的组件正在幕后创建什么。但是当你释放对它的引用时，你至少释放了对它的引用计数。它几乎成了一种宗教咒语。声明、使用、发布。这是 COM 的做事方式。

当然，Visual Basic 在取消引用我在堆栈上声明的变量方面可能会更好或更快。但是该死的，我希望这些对象已被释放，这是显而易见的。当您尝试追踪内存泄漏时，一点保证会大有帮助。