Если вы прибегаете к уничтожению потока в смысле Thread.Abort(), вы в значительной степени говорите: «этот процесс настолько плох, что я собираюсь избавить его от страданий», в этом случае он на самом деле не имеет значения что такое семантика памяти. Убийство потока - это очень плохая вещь , и оно может нарушать большое количество вещей, о которых мы думаем в отношении поведения кода.
Но: с точки зрения поведения памяти ; Потоки (а именно: активная часть стека и любые статические значения потоков / слоты потоков) являются одним из многих видов «корня». Уничтожение потока логически удалит один корень, поэтому в следующий раз GC будет запущен, если что-то было только живым, потому что оно было прямо или косвенно доступно из стекового фрейма / thread-statics / поток-слоты этого потока, то он будет иметь право на сбор. Конечно, уничтожение потока таким способом может на самом деле увеличить проблем, особенно для неуправляемого кода - так как это может помешать правильной работе using / Dispose() кода, а это означает, что может потребоваться запуск большего количества финализаторов. Само пространство стека может также быть восстанавливаемым, но в общей схеме это имеет для меня незначительное значение - и процесс может пожелать сохранить его на том основании, что вы, вероятно, захотите другой поток .
Опять же: выделение, не убивать темы . Если вы можете установить сигнал где-нибудь, чтобы они периодически проверяли и раскручивали себя , тогда: отлично.