Потоки .NET и сборка мусора / фантомный процесс - PullRequest
Новая
       42

Потоки .NET и сборка мусора / фантомный процесс

0 голосов
/ 21 сентября 2018

В настоящее время я пытаюсь выяснить, как лучше всего запустить приложение .NET Core 2.x в качестве службы Windows, особенно для запуска конечной точки NServiceBus для системы обмена сообщениями.Мой оригинальный прототип был создан на основе некоторых документов Windows Service от Particular.Затем я взял этот функционирующий прототип и превратил его в стандартную библиотеку .NET, из которой могли бы работать другие члены команды, но обнаружил, что он не слишком интуитивен для них (или для меня самого, если я отвлекся от него на 2 недели).

Естественно, после того, как я создал работающий прототип и он был развернут в производство, я нашел более элегантное решение, использующее .NET Core GenericHostBuilder, любезно предоставленное Mr.Стив Гордон .Большая часть кода имеет смысл для меня, но я зациклен на new Thread(...).Start();, вероятно потому, что у меня нет особого опыта использования Thread в C # и .NET.

  1. new * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * '*' s '', что не имеет никакого отношения к нему, кажется действительно неправильным.Я обеспокоен тем, что это может привести к утечке памяти, или сборщик мусора его подберет?Я нашел этот ТАК ответ, который дает мне некоторое заверение, что даже если у меня нет ссылки на Thread, CLR найдет.Так что, похоже, не должно быть никакого беспокойства о том, что GC завершит поток, верно?
  2. Может кто-нибудь объяснить мне, почему Abort() не вызывается для Thread?Это потому, что CLR управляет потоками и знает, как остановить другие потоки, когда основной поток завершает работу?Или это как-то связано с вызовом метода ServiceBase.Stop() в методе IHostLifetime.StopAsync()?

Если эти вещи можно объяснить где-нибудь в документации по Thread, я большечем рад получить "RTFM" и найти документы.Я просто не нашел ничего, что дало бы мне ясное объяснение на данный момент.

1 Ответ

0 голосов
/ 21 сентября 2018

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

В отношении Thread.Abort против Thread.Interrupt, Мой честный ответ заключается в том, что вы никогда не должны использовать ни один из этих методов для завершения потока.Рекомендуется вообще не использовать методы Thread.Abort или Thread.Interrupt - вам лучше воспользоваться объектами синхронизации (такими как WaitHandles или Semaphores, ect, ect, ect) и выполнить постепенное завершение потоков, которые вы используете.

В мудрых словах Эрика Липперта (постоянный мастер CLR)

Короче говоря, Thread.Abort в лучшем случае указывает на плохой дизайн, возможно, ненадежныйи чрезвычайно опасно.Следует избегать любой ценой;единственный раз, когда вы должны подумать об прерывании потока, это какой-то код «аварийного завершения», когда вы пытаетесь уничтожить домен приложения как можно более чисто.

Некоторое дополнительное чтение

...