这是比较冷僻的一点，多线程之旅(2) _自己的精简线程池_线程调度策略写一篇文章叫C#源代码，做线程队列的时候，官方一般的queueuserworkking
一、公式的定义首先看看公式的定义：
来源：
3359 docs.Microsoft.com/zh-cn/dot net/API/system.thread pool.queueuserworkitem？ view=net框架- 4.8
3359 docs.Microsoft.com/zh-cn/dot net/API/system.thread pool.unsafequeuserworkitem？ view=net框架- 4.8
对其进行排队以执行（1）QueueUserWorkItem(WaitCallback, Object)方法，并指定包含要在该方法中使用的数据的对象。 在线程池线程可用时执行此方法。
参数：
等待呼叫后退。 表示要执行的方法。
对象。 包含方法中使用的数据的对象。
（2）UnsafeQueueUserWorkItem(WaitCallback, Object)将指定的委托排队到线程池，但不会将调用堆栈传播到辅助线程。
参数：
等待呼叫后退。 表示线程池中的线程选择工作项时调用的委托。
Object，在接受线程池服务时传递给委托方。
二、看上面的官方解释，像往常一样着迷，不用担心是上面的问题。 可能是因为翻译问题而难以理解。
文章“http://www.cs framework.com/archive/2/arc-2-2011 07 27-1759.htm”中介绍了这个问题。
threadpool类具有UnsafeQueueUserWorkItem方法。 此方法与通常调用的QueueUserWorkItem方法非常类似。 首先，我将简要介绍这两种方法的区别。
如果存在尝试访问受限资源(例如打开文件)的线程，clr将执行代码访问安全(cas )检查。 也就是说，clr检查调用线程调用栈中的所有程序集是否都具有资源的访问权限。 如果存在没有所需许可权限的程序集，clr将抛出安全执行异常。 假设您无权在运行代码的线程所在的程序集上打开文件，则当线程尝试打开文件时，clr会抛出安全执行异常。
为了继续运行线程，线程可以将工作项添加到线程池的队列中，以便线程池中的线程执行用于打开文件的代码。 当然，这必须在具有适当许可权限的程序集中进行。 这种“工作区”智能获取安全权限的现象可以极大地破坏恶意代码受限的资源。 为了防止获取此类安全权限，QueueUserWorkItem方法在内部遍历调用线程堆栈，并获取所有授予的安全权限。 然后，当线程池中的线程运行时，这些权限将与线程合并。 因此，线程池中的线程将在调用QueueUserWorkItem方法的线程所在的权限集中运行。
(虽然似乎有些绕圈子，但简单地说，QueueUserWorkItem是一种安全的线程池机制，它能够遍历调用线程池中线程的“堆栈”，以获取程序集在堆栈中拥有的安全权限当对线程调用堆栈时，该线程的将继承调用堆栈内容的权限。 这避免了权限较小的堆栈通过调用权限较大的线程来获取不正确的数据。
堆栈内容无权打开文件，但线程池中的线程可以打开文件。 堆栈通过调用线程池中的线程打开文件，获得打开文件的权限。 ）
OK，再看看UnsafeQueueUserWorkItem
遍历线程堆栈并获取所有安全权限与性能密切相关。 如果希望提高受计算约束的异步操作的队列性能，可以调用UnsafeQueueUserWorkItem方法。 此方法只是将工作项添加到线程池的队列中，而不遍历调用线程的堆栈。 因此，该方法运行得比QueueUserWorkItem方法快，但为APP应用程序打开了潜在的安全漏洞。 只有在可以确保线程池中的线程执行的代码未触及受限资源，或者可以确信接触部分资源没有问题时，才能调用unsafequeueuserwork-item方法。 同样，请注意，调用此方法需要打开安全权限控制策略和控制权限标记，以防止不受信任的代码偶然或故意提高许可权限
(有了上面的铺位，UnsafeQueueUserWorkItem就很清楚了。 为了提高效率，unsafequeuserworkitem信任堆栈中的内容，直接执行而不是遍历堆栈信息或读取权限。 ）
三、另一篇文章(https://www.cn blogs.com/Jeffrey Zhao/archive/2009/07/22/thread-pool-1-the-goal-and-the )
编写程序时，可以使用ThreadPool类的两个静态方法QueueUserWorkItem和UnsafeUserQueueWorkItem将任务添加到CLR线程池中。 这两种方法的区别在于前者收集调用方的executer，这意味着后者不会在最终“创建”任务时的环境中执行，例如，保存的当前线程的执行信息(认证和语言文化)。 因此，比较两种方法的绝对性能，Unsafe方法略优。 但是，通常建议使用QueueUserWorkItem方法。 因为保留执行上下文可以避免很多麻烦，而这点性能损失实际上没什么大不了的。
虽然这句话表达不清楚，但它可能表明QueueUserWorkItem方法在处理线程时会进行更多的信息评估，更安全。 相比之下，UnsafeQueueUserWorkItem的执行效率更高。