Действительно ли очистка объекта / освобождение массива необходимы в VB6 / VBA (Плюсы / минусы?)

Question

Многое из того, что я узнал о VB, я почерпнул из использования статического анализа кода (в частности, Project Analyzer от Aivosto).И одна из вещей, которую он проверяет, заключается в том, очистили ли вы все объекты и массивы.Раньше я просто делал это вслепую, потому что так сказал папа.Но теперь, когда я знаю немного больше о том, как VB освобождает ресурсы, мне кажется, что все это должно происходить автоматически.Является ли это унаследованной функцией от версии до VB6, или есть причина, по которой вы должны явно возвращать объектам значение nothing и использовать Erase для массивов?

Answer 1

Проблема, как я понимаю, связана с тем фактом, что VB6 (и его предшественники) имеет свои корни в COM и его системе сбора мусора с подсчетом ссылок.

Представьте, например, что вы объявляете ссылку на объект из сторонней библиотеки.Этот объект имеет счетчик ссылок COM, который используется как для поддержания его работоспособности, так и для определения того, когда он должен быть уничтожен.Он уничтожается не тогда, когда вы устанавливаете для него значение Nothing, а когда количество ссылок на объект достигает нуля.

Так вот, не все COM-компоненты были написаны на Visual Basic.Некоторые из них были написаны на C или C ++.Структурированная обработка исключений существовала не во всех языках.Таким образом, в случае возникновения ошибки не было гарантировано, что количество ссылок на объект будет должным образом уменьшено, и было известно, что COM-объекты зависали дольше, чем предполагалось.По сути, это не было проблемой с Visual Basic.Это была проблема со связью.(И это, как вы могли бы заметить, причина .NET не использует подсчет ссылок.)

Вот почему разработчики Visual Basic стали одержимы выпуском ссылок на объекты перед выходом из подпрограмм.Вы просто не знаете, какой компонент, который вы выделяете, создается под капотом.Но когда вы освобождаете свою ссылку на него, вы, по крайней мере, освобождаете свое количество ссылок на него.Это стало почти религиозной мантрой.Объявлять, использовать, выпускать.Это был обычный способ ведения дел.

Конечно, Visual Basic может быть лучше или быстрее при разыменовании переменных, которые я объявил в стеке.Но, черт возьми, я хочу, чтобы было ОЧЕВИДНО, что эти объекты были выпущены.Небольшая уверенность имеет большое значение, когда вы пытаетесь отследить утечку памяти.

Answer 2

Мэтт Керланд, автор Расширенный Visual Basic 6, который знает о Visual Basic больше, чем большинство из нас когда-либо узнают, считает, что это напрасные усилия.Рассмотрим эту цитату (стр. 110) о DAO, библиотеке доступа к COM-данным, которая в первую очередь предназначена для ядра базы данных Access:

еще один пример плохого кода демонтажа.В DAO есть методы Close, которые должны быть вызваны в правильном порядке, и объекты также должны быть выпущены в правильном порядке (набор записей перед базой данных, например).Это единственное плохое поведение объектной модели привело к неправильному представлению о том, что VB утекает память, если вы явно не установите для всех локальных переменных значение nothing в конце функции.Это абсолютно ложное представление в хорошо спроектированной объектной модели.VB может очищать переменные быстрее в конце Подстроки, чем вы можете из кода, и он проверяет переменные, даже если вы явно освобождаете свои ссылки.Любое усилие, которое вы прилагаете, дублируется.

Answer 3

Вы читали это Веб-страница Aivosto (от создателей Project Analyzer)?

Если вы используете статические переменные, важно освободить память они были заняты, когда вам больше не нужны переменные.С динамическими память переменных не такая уж большая проблема, потому что они уничтожаются когда процедура заканчивается.

Другими словами, вам не нужно беспокоиться об очистке обычных нестатических локальных переменных.

Answer 4

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

У меня была проблема внутри простой системы отслеживания времени простоя, когда сервер продолжал аварийно завершать работу случайным образом, потребовались недели, чтобы определить, что это была утечка памяти объекта, который должен был самоуничтожиться сам по себе.Мой код попадал в исключение и никогда не очищался после себя, в результате чего сервер (фактический веб-сайт, а не весь сервер) выходил из строя.

Answer 5

Да, сведите все объекты к нулю и очистите столько, сколько сможете.VB6 печально известен тем, что имеет утечки памяти, когда вы не очищаете свои данные.Сборка мусора была ниже номинала в VB6 / VBA.