Как Вы избавляетесь от объекта в c#
OK. Я прочитал еще немного об ошибке, которую я получил. Проблема заключалась в том, что текущий пакет redux, который устанавливался по умолчанию, был несовместим с устанавливаемой версией @ angular-redux / store. Произошло обновление основной версии до версии redux, которая не имеет обратной совместимости. Мне пришлось установить redux@3.7.2, и это решило проблему.
7 ответов
Короткий ответ: если это не имеет неуправляемые ресурсы (дескрипторы файлов и т.д.), Вы не должны волноваться.
Длинный ответ немного более включен.
Когда.NET решает, что хочет освободить некоторую память, она запускает сборщик "мусора". Это ищет все объекты, которые все еще используются, и отмечает их как таковой. Любая локальная переменная (в любом стековом фрейме любого потока), который может все еще быть считан количества как корень также, как и статические переменные. (На самом деле я полагаю, что на статические переменные ссылаются через живые Текстовые объекты, на которые ссылаются через живые объекты AppDomain, но по большей части можно рассматривать статические переменные как корни.)
Сборщик "мусора" смотрит на каждый объект, упомянутый корнем, и затем находит больше "живых" ссылок на основе переменных экземпляра в тех объектах. Это рекурсивно вызывает вниз, находя и отмечая все больше объектов как "живое". После того как это закончило этот процесс, это может затем посмотреть на всю остальную часть объектов и освободить их.
Это - очень широкое концептуальное изображение - но это становится намного более подробным при размышлении о модели поколений сборки "мусора", финализаторов, параллельный набор и т.д. Я настоятельно рекомендую считать CLR Jeff Richter через C#, который входит в это в большом количестве деталей. У него также есть двачастьстатья (назад с 2000, но все еще очень релевантный), если Вы не хотите покупать книгу.
Конечно, все это не означает, что Вы не должны волноваться об использовании памяти и объектное время жизни в.NET. В особенности:
- Создание объектов бессмысленно будет стоить производительности. В частности, сборщик "мусора" является быстрым, но не бесплатным. Ищите простые способы уменьшить Ваше использование памяти, как Вы кодируете, но микрооптимизирующий перед знанием, у Вас есть проблема, также плохо.
- Возможно "пропустить" память путем создания объектов достижимыми для дольше, чем Вы предназначили. Двумя довольно частыми причинами этого являются подписки события и статические переменные. (Подписка события делает обработчик событий достижимым от издателя события, но не наоборот.)
- При использовании большей памяти (живым, достижимым способом), чем Вы имеете в наличии, Ваше приложение откажет. Нет много.NET, может сделать для предотвращения этого!
- Объекты, которые используют нересурсы памяти обычно, реализуют
IDisposable. Необходимо звонитьDisposeна них для высвобождения тех средств, когда Вы закончены с объектом. Обратите внимание, что это не освобождает сам объект - только сборщик "мусора" может сделать это.usingоператор в C# является наиболее удобным способом звонитьDisposeнадежно, даже перед лицом исключения.
Автоматически. Когда MyObject выходит из объема (в конце Теста), он отмечается для сборки "мусора". В какой-то момент в будущем, время выполнения.NET очистит память для Вас
Править: (Я должен указать ради полноты, что при передаче MyObject куда-нибудь он передается ссылкой и не будет собран "мусор" - это только, когда больше ссылок на объект не плавает, вокруг которого GC свободен собрать его),
Править: в сборке конечных версий будет обычно собираться MyObject, как только это не использовано (дополнительную информацию см. в моем ответе - разность потенциалов),
Другие ответы корректны, если Ваш объект не является экземпляром класса, который реализует IDisposable интерфейс, в этом случае Вы должны (явно, или неявно через a using оператор), называют объект Dispose метод.
Это вынудит сборщик "мусора" избавиться от неиспользуемых объектов.
GC.Collect();
GC.WaitForPendingFinalizers();
Если Вы хотите, чтобы конкретный объект был собран.
object A = new Object();
...
A = null;
GC.collect();
GC.WaitForPendingFinalizers();
В оптимизированном коде это возможно и вероятно, что MyObject будет собран до конца метода. По умолчанию настройка отладочного процесса в Visual Studio создаст с отладкой, включают, и оптимизирование выключают, что означает, что MyObject будет сведен к концу метода (так, чтобы можно было посмотреть на значение при отладке). Здание с оптимизирует прочь (отладка не имеет значения в этом случае), позволяет MyObject быть собранным после того, как это полно решимости быть неиспользованным. Один способ вынудить это остаться в живых в конец метода состоит в том, чтобы назвать GC.KeepAlive (MyObject) в конце метода.
Обычно сборка "мусора" может зависеться от очистки, но если Ваш объект будет содержать какие-либо неуправляемые ресурсы (соединения с базой данных, открытые файлы и т.д.), то необходимо будет явно закрыть те ресурсы и/или exceute расположить метод на объекте (если это реализует IDisposable). Это может привести к ошибкам, таким образом, необходимо быть осторожными, как Вы имеете дело с этими типами объектов. Просто закрывая файл после использования это не всегда достаточно начиная с исключения, прежде чем завершение выполнится, оставит файл открытым. Или используйте блок использования или попытку наконец блок.
Нижняя строка: "использование" является Вашим другом.