побочные эффекты сбора мусора?

Question

Это может быть вопрос, который стоит на высшем уровне, но я тип, который видит то, что прилипает к стене. При всех преимуществах памяти и управления жизненным циклом, обеспечиваемых сборкой времени, собранной мусором, были ли какие-либо заметные случаи неопределенности программы, вызванной условиями гонки между приложением и сборщиком мусора? Появился ли гештальт защитного программирования против такого рода вещей? Разумеется, программисты, привыкшие к RAII, должны изучать уроки, когда в присутствии GC.

Answer 1

Я думаю, вы неправильно поняли, как работает сборщик мусора. Условия гонки между приложением и правильно реализованным сборщиком мусора невозможны, даже в принципе. Сборщик мусора собирает только объекты, которые приложение не имеет доступа к.

Поскольку только один из двух может когда-либо «владеть» данным объектом, условия гонки не могут произойти.

Answer 2

Когда я переехал в мир .NET шесть лет, я чувствовал себя неловко с GC, и я вроде как считал само собой разумеющимся, что он должен быть намного медленнее и что я должен быть еще более осторожным с моей памятью чтобы избежать создания свиней.

Через шесть лет я могу сказать, что моя перспектива полностью изменилась! Я могу только вспомнить время в течение этих лет, когда у меня была утечка памяти из-за забытого .Dispose(). Сравните это с C++, где вы производите утечку памяти каждый час кодирования ... ;-)

Я был вынужден вернуться в мир C++, и я полностью ошеломлен! Я использовал для работы с этим и как это один раз? Это чувствует, что я по меньшей мере в 10 раз более продуктивен в C#, чем в C++. И вдобавок ко всему: распределитель памяти ГК настолько невероятно быстро, что я до сих пор не могу поверить. Посмотрите на этот вопрос, где мне пришлось сделать вывод, что в моем конкретном случае версия .NET (C# или C++/CLI) выполняется в 10 раз быстрее, чем версия C++ MFC: C++ string memory allocation.

Я полностью переделал, но мне потребовалось много времени, чтобы полностью его принять.

Answer 3

Проблема с сборкой мусора заключается в том, что он управляет ресурсами памяти. К сожалению, программисты должны управлять много, много других типов ресурсов:

• файл и гнездо обрабатывает
• соединения с базой данных
• синхронизации Объекты
• Gui ресурсы

назвать лишь несколько. Чтобы успешно справляться с этим, вам действительно нужны концепции, воплощенные в идиоме RAII.

Answer 4

Когда я впервые начал программирование на C, я должен был быть очень методичным с моими malloc и realloc, и мне пришлось освобождать все, что я не использовал. Это была простая задача с крошечными заданиями колледжа, такими как создание двоичного дерева. Простой ...

Теперь, когда я начал разрабатывать приложение с графическим интерфейсом, написанным на всех C, мне приходилось больше думать и программировать из-за того, что я должен обратить внимание на возможные утечки памяти. Это стало хлопот. Я бы предпочел иметь половину продукта, чем половину продукта ass'd.

Я начал переходить на Java и C#.Мне нравилось, что все, что мне нужно было сделать, это разыменовать объект, и сборщик мусора придет и возьмет его за меня. Я также заметил, что мои программы работали немного медленнее с использованием Swing Java (как и ожидалось), но это было управляемо.

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

EDIT:

Also see this это может помочь вам ответить на ваши вопросы. Хорошо прочитано IMO