Эффективность сборщика "мусора".NET
Хорошо вот соглашение. Существуют некоторые люди, которые поместили их жизни в руки сборщика "мусора".NET и некоторых, которые просто привычка доверяет ему.
Я - один из тех, который частично доверяет ему, пока это не чрезвычайно очень важная производительность (я знаю, что знаю.. производительность, очень важная + .NET не привилегированная комбинация), в этом случае, я предпочитаю вручную избавляться от своих объектов и ресурсов.
То, что я спрашиваю, - то, если существуют какие-либо факты относительно того, насколько эффективный или неэффективный мудрый производительностью сборщик "мусора" действительно?
Не совместно используйте личные мнения или likely-assumptions-based-on-experience, я хочу несмещенные факты. Я также не хочу про/обманных обсуждений, потому что это не ответит на вопрос.
Спасибо
Править: Для разъяснения я в основном говорю: Какое приложение мы пишем, очень важный ресурс, или не мы можем просто забыть обо всем и позволить GC обработать его, или не можем мы?
Я пытаюсь надеть ответ в действительности, что GC делает и не делает и где он мог бы перестать работать, где ручное управление памятью будет успех, ЕСЛИ будут такие сценарии. Это имеет ОГРАНИЧЕНИЯ? Я не знаю, как я мог возможно объяснить свой вопрос далее.
У меня нет проблем ни с каким приложением, это - теоретический вопрос.
4 ответа
Достаточно эффективен для большинства приложений. Но вам не нужно жить в страхе перед GC. В действительно горячих системах, требующих низкой задержки, вы должны программировать таким образом, чтобы полностью ее избегать. Я предлагаю вам ознакомиться с этим Техническим документом по быстрому добавлению :
Хотя сборщик мусора выполняется довольно быстро, для его выполнения требуется время, и, следовательно, сборка мусора в вашем непрерывный режим работы может вызвать как нежелательную задержку, так и изменение задержки в тех приложениях, которые очень чувствительны к задержке. В качестве иллюстрации , если вы обрабатываете 100 000 сообщений в секунду и каждое сообщение использует небольшую временную строку из 2 символов, около 8 байтов (это {{ 1}} функция кодирования строки и реализация строкового объекта) выделяется для каждого сообщения. Таким образом вы создаете почти 1 МБ мусора в секунду. Для системы, которой может потребоваться обеспечить постоянную производительность в течение 16 часов, это означает, что вам придется навести порядок 16 часов x 60 минут x 60 секунд x 1 МБ памяти примерно 56 ГБ памяти. Лучшее, что вы можете ожидать от сборщика мусора , это то, что он полностью очистит его за либо коллекции поколения 0, либо 1 и вызывают дрожание, хуже всего то, что они вызовут сборку мусора поколения 2 со связанным большим {{1} } всплеск задержки.
Но имейте в виду, что такие уловки, как предотвращение воздействия сборщика мусора, действительно сложно . Вам действительно нужно подумать, находитесь ли вы на том этапе своих требований к производительности, когда вам нужно учитывать влияние GC.
Любой алгоритм сборки мусора будет благоприятствовать определенным действиям (например, оптимизации). Вам нужно будет протестировать сборщик мусора в соответствии с вашим шаблоном использования, чтобы увидеть, насколько он эффективен для вас. Даже если кто-то другой изучит конкретное поведение сборщика мусора .net и предоставит «факты» и «цифры», ваши результаты могут сильно отличаться.
Я думаю, что единственный разумный ответ на этот вопрос - это анекдот. У большинства людей нет проблем с эффективностью сборки мусора даже в крупномасштабных ситуациях. Он считается по крайней мере таким же эффективным или более эффективным, чем GC других управляемых языков. Если вы все еще обеспокоены, вероятно, вам не следует использовать управляемый язык.
Не беспокойтесь об этом.
Причина в том, что если вы когда-нибудь обнаружите крайний случай, когда сборщик мусора отнимает значительное количество времени, вы сможете справиться с ним, сделав точечную оптимизацию. Это не будет концом света - вероятно, это будет довольно легко.
И вы вряд ли найдете такие крайние случаи. Он действительно работает на удивление хорошо. Если вы знакомы с распределителями кучи только в типичных реализациях C и C ++, .NET GC - совсем другое дело. Я был так поражен этим , что написал это сообщение в блоге, чтобы попытаться донести суть .
Вы не можете всегда забывать о распределении памяти, независимо от того, используете вы GC или нет. Хорошая реализация GC дает вам то, что большую часть времени вы можете позволить себе не думать о распределении памяти. Однако окончательного распределителя памяти нет. Для чего-то важного вы должны знать, как управляется память, а это подразумевает знание того, как все делается внутри. Это верно как для сборки мусора, так и для выделения кучи вручную.
Есть сборщики мусора, которые предлагают гарантии в реальном времени. «В реальном времени» не означает «быстро», это означает, что время отклика распределителя может быть ограничено. Это своего рода гарантия, необходимая для встроенных систем, таких как те, которые управляют электрическими командами в самолете. Как ни странно, с сборщиками мусора легче получить гарантии в реальном времени, чем с ручными распределителями.
Сборщик мусора в текущих реализациях .NET не работает в реальном времени; они эвристически эффективны и быстры. Обратите внимание, что то же самое можно сказать и о ручном распределении с помощью malloc () в C (или new в C ++), поэтому, если вам нужны гарантии в реальном времени, вам уже нужно использовать что-то особенное. .Если вы этого не сделаете, то я не хочу, чтобы вы разрабатывали встроенную электронику для автомобилей и самолетов, которые я использую!