То, почему свободно () не позволенный войти, собрало "мусор" языки?

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

Среди предотвращенных проблем:

• Двойной free() с
• Вызов free() по указателю на память, которой вы не владеете, что приводит к несанкционированному доступу в других местах
• Вызов free() для указателя, который не был возвращаемым значением функции выделения, например, для получения адреса некоторого объекта в стеке или в середине массива или другого выделения.
• Разыменование указателя на память, которая уже была free() d

Кроме того, автоматическое управление может привести к повышению производительности, когда ГХ перемещает живые объекты в консолидированную область. Это улучшает локальность ссылок и, следовательно, производительность кэша.

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

Я не могу сказать, что это ответ , но приходит на ум, что если вы можете бесплатно , вы можете случайно удвоить освободить указатель / ссылку или, что еще хуже, использовать один за другим. Что противоречит основному принципу использования таких языков, как c # / java / etc.

Конечно, одним из возможных решений этой проблемы было бы, чтобы ваш бесплатный принимал аргумент по ссылке и после освобождения устанавливал для него значение null . Но тогда, что, если они передадут r-значение следующим образом: free (something ()) . Я полагаю, у вас может быть перегрузка для версий с r-значением, но вы даже не знаете, поддерживает ли C # такую ​​вещь: -P.

В конце концов, даже этого было бы недостаточно, потому что, как уже указывалось, вы можете иметь несколько ссылок на один и тот же объект. Установка для одного значения null ничего не сделает, чтобы помешать другим получить доступ к теперь освобожденному объекту.

Достаточно интересно, что у вас есть доступ к сборщику мусора через System.GC - хотя, судя по всему, что я читал, настоятельно рекомендуется разрешить сборщику мусора управлять самим собой.

Однажды мне посоветовали использовать следующие 2 строки от стороннего поставщика для решения проблемы сборки мусора с помощью объекта DLL, COM или чего-то подобного:

// Force garbage collection (cleanup event objects from previous run.)
GC.Collect();         // Force an immediate garbage collection of all generations
GC.GetTotalMemory(true);

Тем не менее, я бы не стал возиться с System. GC, если я точно не знал, что происходит под капотом. В этом случае совет стороннего поставщика «устранил» проблему, с которой я имел дело, относительно их кода. Но я не могу не задаться вопросом, действительно ли это было обходным путем для их неработающего кода ...

Вызов GC.Collect почти всегда лучше, чем наличие явного бесплатного метода. Вызов free имеет смысл только для указателей / ссылок на объекты, на которые есть ссылки из ниоткуда. Это то, что подвержено ошибкам, поскольку есть вероятность, что ваш вызов free для указателя неправильного типа.

Когда среда выполнения ссылается на подсчет мониторинга для вас, она знает, какие указатели могут быть освобождены безопасно, а какие нет, поэтому позволяя сборщику мусора решать, какая память может быть освобождена, избегает класс дыр уродливых ошибок. . Можно подумать о реализации среды выполнения с GC и free , где явный вызов free для одного блока памяти может быть намного быстрее, чем выполнение полного GC.Collect (но не ожидайте, что освобождение каждого возможного блока памяти «вручную» будет быстрее, чем сборщик мусора). Но я думаю, что разработчики C #, CLI (и других языков со сборщиками мусора, таких как Java) решили отдать предпочтение надежности и безопасности, а не скорости.

Если вы находитесь в ситуации, когда «не хотите полагаться на умный сборщик мусора», то, скорее всего, вы неправильно выбрали фреймворк для своей задачи. В .net вы можете немного манипулировать GC ( http://msdn.microsoft.com/library/system.gc.aspx ), в Java - нет.

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

Ручное управление разрешено. Например, в Ruby вызов GC.start освободит все, что может быть освобождено, хотя вы не можете освобождать вещи по отдельности.

Многие из других ответов содержат хорошие объяснения того, как работает GC и как вы должны думать при программировании для системы времени выполнения, которая предоставляет GC.

Я хотел бы добавить один трюк, который я стараюсь держать в уме при программировании на языках с GC'd. Правило гласит: "Важно как можно быстрее отказаться от указателей". Под отбрасыванием указателей я подразумеваю, что я больше не указываю на объекты, которые я больше не буду использовать. Например, в некоторых языках это можно сделать, установив переменную в Null. Это можно рассматривать как подсказку сборщику мусора, что можно собрать этот объект, если на него нет других указателей.