首頁猿問關(guān)于在.NET中干凈地終止線程的問題

關(guān)于在.NET中干凈地終止線程的問題

C# .NET

墨色風(fēng)雨 2019-07-26 15:43:17

關(guān)于在.NET中干凈地終止線程的問題我理解Thread.Abort（）在我讀過的關(guān)于這個主題的大量文章中是邪惡的，所以我目前正在扯掉我的中止，以便以更清潔的方式取代它; 并且在比較了stackoverflow上的人們的用戶策略之后，然后在閱讀MSDN上的“ 如何：創(chuàng)建和終止線程（C＃編程指南） ”之后，兩者都說明了一種非常相似的方法 - 即使用volatile bool方法檢查策略，這很好，但我還有幾個問題....如果你沒有一個簡單的工作進程只是運行一個運算循環(huán)的代碼，那么我的優(yōu)勢就在于此。比如說對我來說，我的進程是一個后臺文件上傳程序進程，我實際上是循環(huán)遍歷每個文件，所以這是一些東西，并確保我可以while (!_shouldStop)在頂部添加我的每個循環(huán)迭代，但我有更多的業(yè)務(wù)流程它發(fā)生在它下一次循環(huán)迭代之前發(fā)生，我希望這個取消程序是快節(jié)奏的; 不要告訴我，我需要在整個工作人員功能中每隔4-5行循環(huán)播放這些？我真的希望有一個更好的方法，有人可以告訴我這是否實際上是正確的[并且只有？]做到這一點的方法，或者他們過去用來實現(xiàn)我所追求的目標的策略。謝謝幫派。進一步閱讀：所有這些SO響應(yīng)都假設(shè)工作線程將循環(huán)。這并不適合我。如果它是線性的，但是及時的背景操作怎么辦？

查看完整描述

3 回答

達令說

TA貢獻1821條經(jīng)驗獲得超6個贊

好吧，不幸的是，在多線程中，你經(jīng)常不得不妥協(xié)“快速”以獲得清潔......你可以立即退出一個線程Interrupt，但它不會很干凈。所以不，你不必_shouldStop每隔4-5行清理一次支票，但是如果你確實打斷了你的線程，那么你應(yīng)該處理異常并以干凈的方式退出循環(huán)。

更新

即使它不是一個循環(huán)線程（也許它是一個線程執(zhí)行一些長時間運行的異步操作或某種類型的塊用于輸入操作），你可以Interrupt，但你仍然應(yīng)該抓住ThreadInterruptedException并徹底退出線程。我認為你讀過的例子非常合適。

更新2.0

是的我有一個例子......我只會根據(jù)您引用的鏈接向您展示一個示例：

public class InterruptExample{
    private Thread t;
    private volatile boolean alive;

    public InterruptExample()
    {
        alive = false;

        t = new Thread(()=>
        {
            try
            {
                while (alive)
                {
                    /* Do work. */
                }
            }
            catch (ThreadInterruptedException exception)
            {
                /* Clean up. */
            }
        });
        t.IsBackground = true;
    }

    public void Start()
    {
        alive = true;
        t.Start();
    }


    public void Kill(int timeout = 0)
    {
        // somebody tells you to stop the thread
        t.Interrupt();

        // Optionally you can block the caller
        // by making them wait until the thread exits.
        // If they leave the default timeout, 
        // then they will not wait at all
        t.Join(timeout);
    }}

反對回復(fù) 2019-07-26