Сборка мусора рабочей среды? - PullRequest
1 голос
/ 24 марта 2010

Может ли кто-нибудь рассказать, какую работу вы выполняете при сборе мусора в повседневной работе?

Сколько вы рассматриваете сборку мусора в вашем SDLC?

Ответы [ 4 ]

4 голосов
/ 24 марта 2010

Преимущество сборки мусора заключается в том, что вы не слишком беспокоитесь об этом или вообще не беспокоитесь. Реализации более низкого уровня можно планировать (заранее или на лету) проще, имея больше времени, чтобы беспокоиться о других сложных проблемах, не принимая во внимание освобождение памяти.

Есть некоторые вещи, которые следует иметь в виду, чтобы воспользоваться сборщиком мусора, но они обычно просты или интуитивно понятны. Пара примеров:

  • Возможно, вам придется изменить свое мышление, чтобы воспользоваться тем фактом, что циклические ссылки больше не являются проблемой (если, конечно, все задействованные ресурсы управляются). К этому довольно легко и весело привыкнуть!

  • Полезно определять переменные в минимально возможной области видимости. Но вы все равно захотите это сделать .

Итак, если вы переходите на .NET из какого-то места без управляемой памяти, да, прочитайте немного о GC, но если вы обнаружите, что не думаете об этом, в этом смысл , не надо беспокойство. * * 1023

Редактировать : Имейте в виду, что вы все еще можете использовать неуправляемые ресурсы в .NET. Даже во многих распространенных пространствах имен .NET используются неуправляемые ресурсы. Вы должны понимать .Dispose() (и соответствующее ключевое слово Using) как подсказки, что вы вступаете в неуправляемую память. ( см. Меня здесь об этом. )

2 голосов
/ 24 марта 2010

В большинстве случаев вам не нужно слишком беспокоиться о GC. Если вы беспокоитесь об этом, это, вероятно, означает, что у вас есть основные проблемы кодирования (случайная утечка ссылок на объекты, возможно, из-за статических событий и т. Д.).

Так что воспринимайте это как реактивную вещь, когда вы обнаружите, что у вас есть проблема - и используйте профилировщик памяти, чтобы найти и исправить эту проблему.

1 голос
/ 24 марта 2010

Моей главной задачей ежедневной корпоративной работы по сбору мусора является обеспечение хорошего уборочного сервиса. ;)

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

0 голосов
/ 24 марта 2010

Главное, что нужно понять о ГХ, это то, что это не панацея. Это применимо к памяти и ресурсам, похожим на память , т.е. ресурсы, которыми вы располагаете ограниченным, но довольно большим запасом, и эквивалентные экземпляры ресурса взаимозаменяемы, т.е. любые два буфера памяти объемом 1 МБ одинаково хороши что с ними нужно делать.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...