ThreadPool-QueueUserWorkItem

 [System.Security.SecurityCritical]  // auto-generated_required
        [MethodImplAttribute(MethodImplOptions.NoInlining)] // Methods containing StackCrawlMark local var has to be marked non-inlineable
        public static bool UnsafeQueueUserWorkItem(
             WaitCallback           callBack,     // NOTE: we do not expose options that allow the callback to be queued as an APC
             Object                 state
             )
        {
            StackCrawlMark stackMark = StackCrawlMark.LookForMyCaller;
            return QueueUserWorkItemHelper(callBack,state,ref stackMark,false);
        }
 
        //ThreadPool has per-appdomain managed queue of work-items. The VM is
        //responsible for just scheduling threads into appdomains. After that
        //work-items are dispatched from the managed queue.
        [System.Security.SecurityCritical]  // auto-generated
        private static bool QueueUserWorkItemHelper(WaitCallback callBack, Object state, ref StackCrawlMark stackMark, bool compressStack )
        {
            bool success =  true;
 
            if (callBack != null)
            {
                        //The thread pool maintains a per-appdomain managed work queue.
                //New thread pool entries are added in the managed queue.
                //The VM is responsible for the actual growing/shrinking of 
                //threads. 
 
                EnsureVMInitialized();
 
                //
                // If we are able to create the workitem, we need to get it in the queue without being interrupted
                // by a ThreadAbortException.
                //
                try { }
                finally
                {
                    QueueUserWorkItemCallback tpcallBack = new QueueUserWorkItemCallback(callBack, state, compressStack, ref stackMark);
                    ThreadPoolGlobals.workQueue.Enqueue(tpcallBack, true);
                    success = true;
                }
            }
            else
            {
                throw new ArgumentNullException("WaitCallback");
            }
            return success;
        }

项目中有大文件传输需求，用户在网页端填好某个IP下的共享目录，服务端通过所填路径检测共享目录下的文件以供用户选择待传输的文件，

用户勾选相应文件后点击提交，服务端遂开始执行文件传输。所有的逻辑过程都在同一后台代码中，传文件的代码和其他业务代码都在同一线程中，

因而在文件过大时用户所在页面要等待很久很久，极大地影响用户体验，所以后来将传文件的过程放在新的线程中，以便提高页面响应效率。

将文件传输过程放在新线程中使用的是ThreadPool.QueueUserWorkItem()方法，调用方式是：

下面来认识一下ThreadPool，先看下引用地址：线程池之ThreadPool类与辅助线程 - <第二篇>