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

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

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

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

问题

但是这样带来的问题是大量的创建线程,非常影响项目的性能,尤其是在一些大并发量访问的时候,经常导致后果是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(); }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.

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

复制
//工作者线程最大数目,I/O线程的最大数目 ThreadPool.SetMaxThreads(1000, 1000); //启动工作者线程 ThreadPool.QueueUserWorkItem(new WaitCallback(InsertNewsInfoExt), "param");1.2.3.4.
相关参数GetAvailableThreads:剩余空闲线程数GetMaxThreads:最多可用线程数,所有大于此数目的请求将保持排队状态,直到线程池线程变为可用GetMinThreads:检索线程池在新请求预测中维护的空闲线程数。QueueUserWorkItem:启动线程池里得一个线程(队列的方式,如线程池暂时没空闲线程,则进入队列排队)SetMaxThreads:设置线程池中的最大线程数SetMinThreads:设置线程池最少需要保留的线程数

这样就解决了无限制 new Thread 的问题,实现了最少改动。

THE END
本站服务器由亿华云赞助提供-企业级高防云服务器