Зная о GC и не имея необходимости использовать его (или, как я полагаю), что такое типичное использование, и как я/моя система может пригодиться, если я умру сам и узнаю больше о GC?Как я могу использовать сборщик мусора?
ОБНОВЛЕНИЕ ... как я могу облегчить работу GC?
ОБНОВЛЕНИЕ ... как я могу сделать вещи проще для GC?
Самый простой способ облегчить работу GC - позволить ему выполнять свою работу без вмешательства. Он оптимизирует, когда он должен запускаться самостоятельно.
Я хотел бы изучить, когда следует использовать Finalizer в C#. Это одна из областей, где вы можете потенциально помочь GC.
Понимание вопроса Large Object Heap может быть полезным, так как это может вызвать проблемы.
http://techiemate.blogspot.com/2009/04/garbage-collection-in-net.html
Thanx для ссылок, помогая мне понять это уже уже –
Есть ли какие-либо обстоятельства, когда использование финализатора помогает GC? Я полагаю, что * не * использование финализатора помогает GC, потому что тогда не нужно отслеживать ваш объект в очереди финализации/freachable и т. Д. – LukeH
Типичное использование GC - не использовать его вообще и просто позволить CLR обрабатывать все для вас.
GC не похож на деструктор, который вы определили бы на C++. То есть вам не нужно определять его и освобождать ранее выделенную память. Вся суть GC заключается в том, что она автоматическая. Моя рекомендация дает нам больше информации о том, что вы пытаетесь сделать/понять, потому что это не звучит безопасно.
Если вы не заметили, что вы используете GC, то вы используете его, и вы используете его правильно.
Зная о внутренних элементах GC, только начинает иметь значение, если вы используете его неправильно.
PInvoke - очевидный встречный пример. Даже в контексте автономного кода C# вам все же необходимо понять концепцию достижимости, чтобы писать массивы данных на основе массивов, которые не протекают. –
Лучший способ использовать сборщик мусора ...
Не пытайтесь использовать его!
Позвольте этому сделать свое дело. Почти каждый раз, когда люди пытаются играть с GC, чтобы сделать его «более эффективным», они заканчивают его подавление и на самом деле ухудшают его работу.
Лучший способ использовать GC - это сделать меньше G. :-) Я часто видел наивные алгоритмы, которые при замене немного более умными, производящими 1/10 X, работают в несколько раз быстрее. GCs в эти дни очень хороши, но они не подходят для выполнения меньше работы в первую очередь, и никакой GC, который я видел, достаточно умен, чтобы распознать неэффективный алгоритм. – Ken
Чтобы облегчить работу с GC, всегда вызывайте Dispose() на любом объекте, поддерживая интерфейс IDisposable.
GC не имеет абсолютно никакого отношения к 'Dispose' и' IDisposable'. – LukeH
Не прямо, но 'Dispose' и' IDiposable' являются механизмами, позволяющими пропускать терминаторы на классах, которые в них нуждаются, и THUS упрощают сборщик мусора. Другие классы * должны * не представлять проблем ... – Haas
Всегда может быть полезно понять, как это работает; но в большинстве случаев вам не нужно слишком беспокоиться.
Когда вы начинаете выделять не управляемые ресурсы (или объекты, которые делают), стоит прочитать на IDisposable pattern, чтобы вы могли контролировать, когда ресурсы освобождаются (или «детерминированная финализация», если вы хотите хорошо знать себя при разговоре со сверстниками).
Несколько точек на кодирование с GC в виду:
Всегда убедитесь, чтобы отменить обработчики событий, когда вы больше не использовать их.Это самый распространенный способ сохранения объектов в течение их предполагаемого срока службы и также может вызывать ошибки, если объект Disposed имеет обработчики событий.
Если вы выполняете взаимодействие с неуправляемым кодом, вам нужно быть более осведомленным о любом совместном использовании управляемой памяти с неуправляемым кодом. Возможно, вам понадобится использовать pinning и/или GC.KeepAlive, чтобы помочь GC понять, что вам нужно неуправляемому коду. Постарайтесь свести к минимуму, так как это усложняет работу GC.
Вам практически не нужно реализовывать финализатор. Если у класса есть финализатор, он должен также реализовать ту же самую очистку, что и IDisposable, и вызвать GC.SuppressFinalize(this) после удаления, так как это помогает GC эффективно очищать после вашего класса.
В стиле управления памятью, обычно используемом на C, информация, которая отслеживает, какие области кучи свободны или распределены, отделена от информации, которая указывает, какие области фактически используются. Если информация о куче больше не нужна, код должен явно отмечать ее как нераспределенную, иначе она может оставаться навсегда.
Система на основе мусора рассматривает все ссылки на кучи-объекты в системе как окончательный индикатор, для которого используются объекты. Поскольку было бы нецелесообразно сканировать все ссылки на объекты в системе каждый раз, когда объект был выделен, система эффективно «разбивает» работу: пока свободное свободное пространство все еще существует в куче, память просто распределяется по объектам последовательно. Не предпринимается никаких попыток восстановить любое пространство до тех пор, пока куча не станет слишком полной.
Объект будет считаться «использованным», если какой-либо поток содержит ссылку на него в локальной переменной или если какая-либо глобальная переменная содержит ссылку на него или если объект, который считается «использованным», содержит ссылку к нему в любой области. Компилятор обычно может сказать, что локальная переменная, содержащая ссылку на объект, никогда не будет использоваться, но не может сделать такие определения с глобальными переменными или полями объектов. Если объект, который будет полезен, содержит ссылку на объект, которая больше никогда не будет использоваться, эта ссылка должна быть установлена в значение null (Nothing в VB). Если это не будет сделано, бесполезный объект будет «сохранен» до тех пор, пока полезный объект будет. Если полезный объект похож на основную форму приложения, результатом может быть утечка памяти, которая сохраняется до тех пор, пока приложение остается открытым.
Это достойное описание GC около 1960 года, но никакие производственные GC не работают так сегодня. Инкрементность и параллелизм используются, чтобы избежать пакетной обработки, потому что она использовала неловко-длинные паузы. Вместо того, чтобы откладывать сбор до тех пор, пока куча не заполнится, мусор собирается регулярно с усилием, сосредоточенным на недавно выделенных объектах. –
В то время как большинство современных систем сбора мусора используют поколения, поэтому большинству коллекций не нужно будет изучать все, это детализация реализации. Многие обычные сборщики мусора работают в режиме остановки в мире, и да - это может иногда приводить к раздражающим паузам. Ключевым моментом для понимания является то, что, как только память будет выделена в системе GC, она будет восстановлена, когда и только тогда, когда GC обнаружит, что никаких корневых ссылок на нее не существует. – supercat
Часто не существует способа явно указать сборщику мусора или распределителю, что определенный блок памяти больше не будет использоваться, потому что распределителю все равно. Когда выделена память, распределитель либо захватит кусок от свободного блока в конце кучи (при условии, что свободный блок достаточно большой), либо он выполнит цикл сбора мусора и надеется, что освободит достаточно места. Распределитель не будет пытаться использовать какой-либо другой кусок памяти для заполнения запроса. – supercat
Зная о GC и не имея необходимости использовать его (или, как я полагаю), что такое обычное использование, и как я/моя система может извлечь выгоду, если я сама умру и узнаю больше о GC?
Вы можете использовать знания об сборке мусора, чтобы повысить пропускную способность и латентность программного обеспечения, которое вы пишете.
ОБНОВЛЕНИЕ ... как я могу облегчить работу GC?
Используйте типы значений, чтобы уменьшить количество указателей в куче. Используйте деревья объектов вместо длинных массивов, чтобы сделать перемещение кучи более инкрементным и уменьшить латентность. Избегайте писать ссылки в mutables в куче, потому что это накладывает барьер записи и ухудшает пропускную способность и задержку.
Одним словом: не надо. –
Определите «проще». У вас есть проблема с сборкой мусора? Можете ли вы описать это в своем вопросе? – spender
В большинстве случаев, не касаясь .NET GC, это правильно. Здесь обсуждается конкретный пример, который может быть полезен: http://blogs.msdn.com/b/ricom/archive/2004/11/29/271829.aspx – gooch