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

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

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

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

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

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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