如何检测客户端线程何时退出

本文关键字:客户端 线程 何时 退出 检测 何检测 | 更新日期: 2023-09-27 18:32:58

这是一个有趣的图书馆作家的困境。在我的库中(在我的例子中是 EasyNetQ(,我正在分配线程本地资源。因此,当客户端创建一个新线程,然后在我的库上调用某些方法时,就会创建新的资源。在 EasyNetQ 的情况下,当客户端在新线程上调用"发布"时,会创建一个到 RabbitMQ 服务器的新通道。我希望能够检测客户端线程何时退出,以便清理资源(通道(。

我想出的唯一方法是创建一个新的"观察者"线程,该线程只是阻止对客户端线程的 Join 调用。这里有一个简单的演示:

首先是我的"图书馆"。它获取客户端线程,然后创建一个在"加入"上阻塞的新线程:

public class Library
{
    public void StartSomething()
    {
        Console.WriteLine("Library says: StartSomething called");
        var clientThread = Thread.CurrentThread;
        var exitMonitorThread = new Thread(() =>
        {
            clientThread.Join();
            Console.WriteLine("Libaray says: Client thread existed");
        });
        exitMonitorThread.Start();
    }
}

下面是使用我的库的客户端。它创建一个新线程,然后调用我的库的 StartSomething 方法:

public class Client
{
    private readonly Library library;
    public Client(Library library)
    {
        this.library = library;
    }
    public void DoWorkInAThread()
    {
        var thread = new Thread(() =>
        {
            library.StartSomething();
            Thread.Sleep(10);
            Console.WriteLine("Client thread says: I'm done");
        });
        thread.Start();
    }
}

当我像这样运行客户端时:

var client = new Client(new Library());
client.DoWorkInAThread();
// give the client thread time to complete
Thread.Sleep(100);

我得到这个输出:

Library says: StartSomething called
Client thread says: I'm done
Libaray says: Client thread existed

所以它有效,但它很丑陋。我真的不喜欢所有这些被阻塞的观察者线程徘徊的想法。有没有更好的方法

第一种选择。

提供一个返回实现 IDisposable 的工作线程的方法,并在文档中明确指出不应在线程之间共享工作线程。下面是修改后的库:

public class Library
{
    public LibraryWorker GetLibraryWorker()
    {
        return new LibraryWorker();
    }
}
public class LibraryWorker : IDisposable
{
    public void StartSomething()
    {
        Console.WriteLine("Library says: StartSomething called");
    }
    public void Dispose()
    {
        Console.WriteLine("Library says: I can clean up");
    }
}

客户端现在稍微复杂一些:

public class Client
{
    private readonly Library library;
    public Client(Library library)
    {
        this.library = library;
    }
    public void DoWorkInAThread()
    {
        var thread = new Thread(() =>
        {
            using(var worker = library.GetLibraryWorker())
            {
                worker.StartSomething();
                Console.WriteLine("Client thread says: I'm done");
            }
        });
        thread.Start();
    }
}

此更改的主要问题是它是 API 的重大更改。现有客户端将不得不重写。现在这不是一件坏事,这意味着重新访问它们并确保它们正确清理。

不间断的第二种选择。API 为客户端提供了一种声明"工作范围"的方法。范围完成后,库可以清理。该库提供了一个实现 IDisposable 的工作范围,但与上面的第一种替代方法不同,StartSomething 方法保留在 Library 类上:

public class Library
{
    public WorkScope GetWorkScope()
    {
        return new WorkScope();
    }
    public void StartSomething()
    {
        Console.WriteLine("Library says: StartSomething called");
    }
}
public class WorkScope : IDisposable
{
    public void Dispose()
    {
        Console.WriteLine("Library says: I can clean up");
    }
}

客户端只需将 StartSomething 调用放在 WorkScope 中...

public class Client
{
    private readonly Library library;
    public Client(Library library)
    {
        this.library = library;
    }
    public void DoWorkInAThread()
    {
        var thread = new Thread(() =>
        {
            using(library.GetWorkScope())
            {
                library.StartSomething();
                Console.WriteLine("Client thread says: I'm done");
            }
        });
        thread.Start();
    }
}

我比第一种选择更喜欢它,因为它不会强迫库用户考虑范围。

如何检测客户端线程何时退出

您可以创建具有终结器的线程静态监视器。当线程处于活动状态时,它将保存监视器对象。当头颅死亡时,它将停止持有它。稍后,当 GC 启动时,它将完成您的显示器。在终结器中,您可以引发一个事件,该事件将通知框架有关客户端线程(观察到的(死亡的信息。

可以在以下要点中找到示例代码:https://gist.github.com/2587063

这是它的副本:

public class ThreadMonitor
{
    public static event Action<int> Finalized = delegate { };
    private readonly int m_threadId = Thread.CurrentThread.ManagedThreadId;
    ~ThreadMonitor()
    {
        Finalized(ThreadId);
    }
    public int ThreadId
    {
        get { return m_threadId; }
    }
}
public static class Test
{
    private readonly static ThreadLocal<ThreadMonitor> s_threadMonitor = 
        new ThreadLocal<ThreadMonitor>(() => new ThreadMonitor());
    public static void Main()
    {
        ThreadMonitor.Finalized += i => Console.WriteLine("thread {0} closed", i);
        var thread = new Thread(() =>
        {
            var threadMonitor = s_threadMonitor.Value;
            Console.WriteLine("start work on thread {0}", threadMonitor.ThreadId);
            Thread.Sleep(1000);
            Console.WriteLine("end work on thread {0}", threadMonitor.ThreadId);
        });
        thread.Start();
        thread.Join();
        // wait for GC to collect and finalize everything
        GC.GetTotalMemory(forceFullCollection: true);
        Console.ReadLine();
    }
}

我希望它有所帮助。我认为它比你额外的等待线程更优雅。

由于您不直接控制线程创建,因此您很难知道线程何时完成其工作。另一种方法可能是强制客户在完成后通知您:

public interface IThreadCompletedNotifier
{
   event Action ThreadCompleted;
}
public class Library
{
    public void StartSomething(IThreadCompletedNotifier notifier)
    {
        Console.WriteLine("Library says: StartSomething called");
        notifier.ThreadCompleted += () => Console.WriteLine("Libaray says: Client thread existed");
        var clientThread = Thread.CurrentThread;
        exitMonitorThread.Start();
    }
}

这样,任何呼叫您的客户端都被迫传递某种通知机制,该机制将告诉您何时完成其操作:

public class Client : IThreadCompletedNotifier
{
    private readonly Library library;
    public event Action ThreadCompleted;
    public Client(Library library)
    {
        this.library = library;
    }
    public void DoWorkInAThread()
    {
        var thread = new Thread(() =>
        {
            library.StartSomething();
            Thread.Sleep(10);
            Console.WriteLine("Client thread says: I'm done");
            if(ThreadCompleted != null)
            {
               ThreadCompleted();
            }
        });
        thread.Start();
    }
}

如果客户端线程调用内部分配一些资源的库,则客户端应"打开"库并获取所有进一步操作的令牌。 此标记可以是库内部向量的 int 索引,也可以是指向内部对象/结构的 void 指针。 坚持客户端必须在终止之前关闭令牌。

这就是 99% 的此类 lib 调用的工作方式,其中状态必须在客户端调用之间保留,例如套接字句柄、文件句柄。

除了做任何异步花哨的事情来完全避免线程之外,我会尝试将所有监视组合到一个轮询 .所有命中您的库的线程的 ThreadState 属性,例如,每 100 毫秒(我不确定您需要多快清理资源......

您的.Join解决方案对我来说看起来很优雅。 被阻止的观察程序线程并不是一件可怕的事情。