解决new Thread().Start导致高并发CPU 100%的问题

最新推荐文章于 2025-03-04 09:00:07 发布

原创最新推荐文章于 2025-03-04 09:00:07 发布 · 1.3k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言 #后端

.NET 专栏收录该内容

229 篇文章

订阅专栏

本文通过实际案例介绍如何使用线程池替代频繁创建线程，有效解决项目性能瓶颈。通过限制线程数量并采用ThreadPool.QueueUserWorkItem方法，显著提升了系统并发处理能力。

以下文章来源于UP技术控，作者conan

UP技术控.

江东子弟多才俊，卷土重来未可知。——唐·杜牧

背景

之前接手一个项目的时候，发现到处是

new Thread(()=>{
//do something
}).Start();

这么做的目的，无非是为了减少页面等待时间提高用户体验，把一些浪费时间的操作放到新线程中在后台运行。

问题

但是这样带来的问题是大量的创建线程，非常影响项目的性能，尤其是在一些大并发量访问的时候，经常导致后果是cpu 100%。

当然，如果你的项目到处是这样写的，然后，没挂，至少说明这个方法没几个人再用。

解决方法

于是下意识的想着给项目优化下，第一想法是走队列，但是发现项目压根没有使用队列，很多操作还停留在有个任务表，有任务的时候，往里面加内容，然后有个定时任务，每分钟执行一次，定时的去消费任务；

于是想着怎么先最少的改动，先把问题解决，后面的事情在做考虑。

其实问题的本质是new 太多Thread了，那么最简单的方法就是限制数量。

于是 ThreadPool.QueueUserWorkItem就登场了。

对于线程队列 ThreadPool.QueueUserWorkItem 很多人应该都不陌生，下边看微软的解释：

将方法排入队列以便执行，并指定包含该方法所用数据的对象。此方法在有线程池线程变得可用时执行。

方法如下

  protected static Logger Logger = LogManager.GetCurrentClassLogger();
        public ActionResult Index()
        {
          //  Logger.Debug("执行了  开始 ");
            ThreadPool.QueueUserWorkItem(new WaitCallback(InsertNewsInfoExt), "param");
         //   Logger.Debug("执行了  结束 ");
            return View();
        }
        private void InsertNewsInfoExt(object info)
        {
         //   Logger.Debug("执行了  InsertNewsInfoExt  开始");
            Thread.Sleep(1000*200);
            Logger.Debug("执行了  InsertNewsInfoExt 结束 ");
            new Thread(t =>
            {
                try
                {
                    Logger.Debug("执行了  Thread ");
                 
                }
                catch (Exception ex)
                {
                    Logger.Error(ex.Message);
                }

            }).Start();

        }

根据msdn描述:线程池的默认大小为每个可用处理器有 25 个线程。使用 SetMaxThreads 方法可以更改线程池中的线程数

  //工作者线程最大数目，I/O线程的最大数目
            ThreadPool.SetMaxThreads(1000, 1000);   
            //启动工作者线程
           ThreadPool.QueueUserWorkItem(new WaitCallback(InsertNewsInfoExt), "param");