Каковы Очередь Финализатора и Control+ThreadMethodEntry?
IMO, Вам, вероятно, нужна способность для математики, обязательно не имея большого знания в поле. Так вещи Вы требуете для обладания способностью к математике, подобны вещам, которых Вы требуете для обладания способностью к программированию.
, Но в целом, я не могу помнить прошлый раз, когда я использовал любой вид высшей математики в ежедневном программировании, таким образом, нет.
3 ответа
Очередь финализатора содержит все объекты, для которых определен метод финализатора. Напомним, что финализатор - это средство для сбора неуправляемых ресурсов, таких как дескрипторы. Когда сборщик мусора собирает мусор, он перемещает любые объекты с финализатором в очередь финализатора. Позже - в зависимости от нехватки памяти, эвристики сборщика мусора и фазы луны - когда сборщик мусора решает собрать эти объекты, он спускается по очереди и запускает финализаторы.
После работы с утечками памяти в прошлом, если увидеть кучу объектов вашего поставщика в очереди финализатора, это могло быть небрежным кодом, но это не указывало на утечку памяти. Обычно хороший код предоставляет метод Dispose, который будет собирать как управляемые, так и неуправляемые ресурсы, и при этом удалять себя из очереди финализатора через GC. SuppressFinalize () . Итак, если объекты поставщика реализуют метод Dispose, а ваш код не вызывает его, это может привести к появлению группы объектов в очереди финализатора.
Вы пытались создать моментальный снимок в ANTS между двумя точками времени и сравнивая объекты, созданные между ними? Это может помочь вам идентифицировать любые утечки управляемых объектов.
Кроме того, если вы хотите увидеть, уходит ли память при запуске финализаторов, попробуйте это просто для проверки:
System.GC.Collect(); System.GC.WaitForPendingFinalizers(); // this method may block while it runs the finalizers System.GC.Collect();
Я не рекомендую запускать этот код в обычном режиме . Вы можете захотеть запустить его, если вы только что проделали тонну работы и создали много мусора. Например, в нашем приложении одна из наших функций может создать около 350 МБ мусора, который пропадает после закрытия окна MDI. Поскольку известно, что при этом остается много мусора, мы вручную вызываем сборку мусора.
Также обратите внимание, что в базовом коде Windows.Forms есть низкоуровневый кеш свойств, который будет удерживать последний открытый модальный диалог. Это могло быть источником утечки памяти. Один из верных способов избавиться от этой ссылки - вызвать другое простое диалоговое окно, а затем запустить приведенный выше код GC.
Очередь финализатора - это очередь, в которой экземпляры объектов, которые больше не используются, ожидают завершения сборщиком мусора. Все объекты в этой очереди будут финализированы, и ваша утечка памяти, вероятно, не связана напрямую с одним из них. Но один из этих объектов может не освободить все свои неуправляемые ресурсы.
Класс ThreadMethodEntry является реализацией IAsyncResult, и экземпляры этого класса обычно создаются при вызове асинхронных операций, таких как использование Invoke для обновления пользовательского интерфейса или использование Begin * / Конец * методов.
Вот хорошее сообщение в блоге, в котором описывается похожая проблема. На более техническом уровне вы можете использовать SOS.dll (который описывается в блоге) и Sosex.dll , чтобы помочь вам понять, почему эти объекты ThreadMethodEntry зависают в памяти. В этих расширениях WinDbg есть команды, которые могут отслеживать, какие другие объекты ссылаются на конкретный объект в памяти.