Question

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

我想到的唯一方法就是创建一个新的“观察者”线程，它只是阻止对客户端线程的Join调用。这是一个简单的演示：

首先是我的'图书馆'。它抓取客户端线程，然后创建一个阻止'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的worker的方法，并在文档中明确表示不应该在线程之间共享worker。这是修改后的库：

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的WorkScope，但与上面的第一个替代方法不同，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();
    }
}

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

Answer 1

您可以创建具有终结器的线程静态监视器。当线程处于活动状态时，它将保持监视器对象。当thead死亡时，它将停止持有它。之后，当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();
    }
}

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

Answer 2

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

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();
    }
}

Answer 3

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

这就是99％的所有此类lib调用如何在必须跨客户端调用保留状态的情况下工作，例如。套接字句柄，文件句柄。

Answer 4

除了做任何异步花哨的东西以完全避免一个线程之外，我会尝试将所有观察结合到一个线程中，该线程轮询所有已经命中你的库的线程的.ThreadState属性，比如每100ms（我是我不确定你需要多快清理资源......）

Answer 5

您的.Join解决方案对我来说非常优雅。被阻止的观察者线程并不是那么可怕。

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

5 个答案: