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

Question

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

EDIT:

Также посмотрите это , оно может помочь вам ответить на ваши вопросы. Хорошо читать ИМО