基础才是重中之重~多线程的代价~我的内存都被吃了!

回到目录

异步操作是.net4.5推出的新名词,事实上,这东西早就有了,它归根结底是通过线程池来实现的,即将一个大任务分成多个小任何块,每个线程并行处理其中的一个,完成后再把结果告诉主线程,在.net4.5推出后,这种技术得到了封装,让开发人员实现起来更加方便了,但是,并发(导步,多线程)并不是在哪里都适用的,使用不当,可能出现很多严重的后果!

看我的程序,这家伙已经占到了2.6G的内存空间了,很可怕吧!

出现这种问题的原因就是我没有把线程这东西搞清楚,在一个调用密集的环境里,使用了多线程,要知道,这种线程,线程池里会有N多个线程的,处理的速度我没有觉得提升,反而内存吃的很严重,这个原因就是因为你的工作线程太多的缘故

所以,多线程,并行,异步这些东西不是在哪都适用的,在调用密集时就能用它,因为它会吃你很多内存,如果非要用,请你把线程池的最大数限制一下,这个值可以控制在10以内。

下面是多线程吃内存的例子

          while (true)
            {
               // ThreadPool.SetMaxThreads(10, 10);//限制最大工作线程和i/o线程
                ThreadPool.QueueUserWorkItem(new WaitCallback((a) =>
                {
                    ConcurrentDictionary<string, SendingResult> test2 = new ConcurrentDictionary<string, SendingResult>();
                    test2.TryAdd(Guid.NewGuid().ToString(), new SendingResult
                     {
                         BatchNumber = Guid.NewGuid().ToString(),
                         DbName = "zzl",
                         EndId = 1,
                         StartId = 1,
                         TableName = "zzl",
                         OccurDate = DateTime.Now,
                     });
                }));

                if (DateTime.Now.Minute == 02)
                {
                    break;
                }
            }

查看一个任务管理器

当我把工作线程做了限制后,这种情况得到了改善

如果对于操作频繁(轮训服务)的工作,如果不使用多线程,反而根据不吃什么内存,性能反而更好!

感谢您的阅读!

回到目录

时间: 2024-09-29 04:26:13

基础才是重中之重~多线程的代价~我的内存都被吃了!的相关文章

基础才是重中之重~再说面向接口的编程

之前在我的文章中有对接口进行过讲解,但感觉讲的还是不够清晰,不够利针见血,这次我把面向接口的编程里,自认为比较核心的两点说一下: 接口详细介绍请看我的这篇文章 基础才是重中之重~为什么C#有显示实现接口 一切依赖于抽象,而不是实现 多个接口相同的行为,被一个对象实现 #region 多个接口相同的行为,被一个对象实现(一切依赖于抽象,而不是实现) interface IPainter { void Draw(); } interface ICowBoy { void Draw(); } clas

C# 多线程的代价~内存都被吃了!

异步操作是.net4.5推出的新名词,事实上,这东西早就有了,它归根结底是通过线程池来实现的,即将一个大任务分成多个小任何块,每个线程并行处理其中的一个,完成后再把结果告诉主线程,在.net4.5推出后,这种技术得到了封装,让开发人员实现起来更加方便了,但是,并发(导步,多线程)并不是在哪里都适用的,使用不当,可能出现很多严重的后果! 看我的程序,这家伙已经占到了2.6G的内存空间了,很可怕吧! 出现这种问题的原因就是我没有把线程这东西搞清楚,在一个调用密集的环境里,使用了多线程,要知道,这种线

基础才是重中之重~这时应该用泛型方法了

回到目录 泛型方法:是一个抽象的概念,将批量具有共性的操作进行抽象,使用泛型类型来表示这个方法,实现这些类型的方法具有相同的逻辑,而唯一不同的是,它们的类型,即类型在泛型方法里是个变量,这话感觉是用肺说出来的,呵呵! 今天在做开发时,遇到了这个问题,最后重构了自己的代码,重构后,使用了泛型方法,感觉代码美丽多了 没用泛型方法前 /// <summary> /// 更新老师与学生的关系 /// </summary> /// <param name="list"

C# 基础才是重中之重~对象的生与死

为何要写 之所以写这篇文章,完全是因为学生们在实际开发中遇到的问题,一个对象占用的内存空间总不被释放,导致系统内存不断攀升,其最主要原因是我们对“对象的生与死”不清楚,或者从来没有认真去考虑过这件事,确实一个对象在被声音,初始化,使用或者最后被系统回收,整个的过程与我们关系确实不大,我们开发人员直接用就行了,对于C#这种托管语言你没必要去自己回收它,但有时,我们多了解一点系统的回收机制,对我们的程序还是很有好处的. 对象的种类(根据作用域) 1 类对象,静态对象,使用static修饰符进行声明,

基础才是重中之重~对象的生与死

回到目录 为何要写 之所以写这篇文章,完全是因为学生们在实际开发中遇到的问题,一个对象占用的内存空间总不被释放,导致系统内存不断攀升,其最主要原因是我们对“对象的生与死”不清楚,或者从来没有认真去考虑过这件事,确实一个对象在被声音,初始化,使用或者最后被系统回收,整个的过程与我们关系确实不大,我们开发人员直接用就行了,对于C#这种托管语言你没必要去自己回收它,但有时,我们多了解一点系统的回收机制,对我们的程序还是很有好处的. 对象的种类(根据作用域) 1 类对象,静态对象,使用static修饰符

基础才是重中之重~泛型类的静态构造方法可不是只执行一次呀

回到目录 最近做了一个数据库的读写分离项目,使用到了DbCommand拦截器,在程序开发过程中没有发现什么特别的问题,而当开发完成后,在进行测试阶段时,一个偶然的机会让我发现了,原来我的拦截器注入不只是注入一次,而是每种类型的仓储都会注入一次,这个问题事实上是相关严重的一件事,如果你的拦截器处理逻辑很多,那么,这将是非常消耗性能的. 原因,静态构造方法对泛型类不是唯一的,而是相互独立的 public abstract class DbContextRepository<TEntity> : I

基础才是重中之重~Dictionary&lt;K,V&gt;里V的设计决定的性能

回到目录 字典对象Dictionary<K,V>我们经常会用到,而在大数据环境下,字典使用不当可能引起性能问题,严重的可能引起内在的溢出! 字典的值建议为简单类型,反正使用Tuple<T> 字典的键在查找时,时间复杂度为O(1),性能不会有任何问题,所以不要愿望它 下面代码是对500万的字典进行测试,首先赋值,然后取出一个随机机,性能在毫秒级 static void Draw() { int count = 5000000; Console.WriteLine("test

基础才是重中之重~Emit动态构建方法(参数和返回值)

回到目录 对于Emit我们知道它的可以动态构建程序集,类型,方法,属性等,或者说只要手动使用C#创建的东西使用Emit也都可以动态创建它们,Emit由于它的特别之处,所以在很多领域得到了广泛的应用,像最近比较火的AOP技术,它最核心的功能就是方法拦截了,我们使用Emit也是可以实现方法拦截功能的,详细可以看大叔这篇文章<Lind.DDD.Aspects通过Plugins实现方法的动态拦截~Lind里的AOP>. 有参数,没有返回值的方法构建与调用 [TestMethod] public voi

基础才是重中之重~用好configSections让配置信息更规范

对于小型项目来说,配置信息可以通过appSettings进行配置,而如果配置信息太多,appSettings显得有些乱,而且在开发人员调用时,也不够友好,节点名称很容易写错,这时,我们有几种解决方案 1 自己开发一个配置信息持久化类,用来管理配置信息,并提供面向对象的支持 2 使用.net自带的configSections,将配置信息分块管理,并提供实体类,便于开发人员友好的去使用它 本文主要说说第二种方案,它由实体类,实体类工厂及配置文件三个部分,看代码: 实体类设计: namespace C