.Net против Java сборщик мусора - PullRequest
61 голосов
/ 29 января 2009

Кто-нибудь знает основные различия между сборщиками мусора Java и .Net? Поиск в Интернете мало что показал, и это был вопрос, который возник в ходе теста.

Ответы [ 5 ]

106 голосов
/ 29 января 2009

Разница между GC CLR (.Net) и GC JVM, а не самими языками. Оба могут быть изменены, а спецификация их поведения свободна, чтобы можно было изменить это без ущерба для правильности программ.

Существуют некоторые исторические различия в значительной степени из-за того, что .Net разрабатывался с учетом уроков эволюции Java (и других платформ, основанных на gc). В дальнейшем не предполагайте, что .Net one был в некотором роде превосходящим, потому что он включал функциональность с самого начала, это просто результат прихода позже.

Заметное публично видимое различие заключается в том, что MS GC раскрывает свою порождающую природу (через API GC), что, вероятно, останется верным в течение некоторого времени, поскольку это очевидный подход, основанный на поведении, которое демонстрирует большинство программ: Большинство ассигнования чрезвычайно недолговечны.

В первоначальной JVM не было сборщиков мусора, хотя эта функция была быстро добавлена. Коллекторы первого поколения, внедренные Oracle Sun и другими, как правило, были Марком и Свипом. Было понято, что компактный подход с разметкой меток приведет к гораздо лучшей локализации памяти, оправдывая дополнительные затраты на копирование. Среда выполнения CLR дебютировала с таким поведением.

Разница между Sun Oracle и Microsoft в реализации GC - это «конфигурация».

Sun предоставляет огромное количество опций (в командной строке) для настройки аспектов ГХ или переключения его между различными режимами. Многие опции имеют -X или -XX, чтобы указать на отсутствие поддержки в разных версиях или поставщиках. CLR, напротив, обеспечивает почти отсутствие возможности конфигурирования; Ваш единственный реальный вариант - использование серверных или клиентских коллекторов, которые оптимизируют соответственно задержку пропускной способности стихов.

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

29 голосов
/ 30 января 2009

Это просто добавление к превосходному ответу ShuggyCoUk. .NET GC также использует так называемую кучу больших объектов (LOH). CLR предварительно выделяет группу объектов в LOH, и все выделенные пользователем объекты размером не менее 85000 байтов также выделяются в LOH. Кроме того, double[] из 1000 или более элементов выделяется на LOH также из-за некоторой внутренней оптимизации.

LOH обрабатывается по-разному, чем кучи поколений:

  • Он очищается только во время полного сбора и никогда не уплотняется, как кучи поколений.
  • Выделение из LOH выполняется через свободный список, очень похожий на то, что malloc обрабатывается во время выполнения C, тогда как выделение из кучи поколений по сути делается простым перемещением указателя в поколении 0.

Я не знаю, есть ли в JVM что-то похожее, но это важная информация о том, как обрабатывается память в .NET, так что, надеюсь, вы найдете это полезным.

19 голосов
/ 30 января 2009

Если я правильно помню, JVM не освобождает освобожденную память обратно операционной системе, как это делает CLR.

3 голосов
/ 29 января 2009

Java 5 внесла много изменений в свои алгоритмы GC.

Я не C # maven, но эти две статьи подсказывают мне, что обе они эволюционировали от простой маркировки и развертки к моделям нового поколения:

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html http://www.csharphelp.com/archives2/archive297.html

1 голос
/ 29 января 2009

Я нашел это:

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

здесь и это

Также как JVM управляет уничтожением объектов, так же как и CLR с помощью алгоритма сбора мусора Mark и Compact

здесь

Надеюсь, это поможет ...

...