​引发类型为“System.OutOfMemoryException”的异常-.Net 内存溢出​

.Net 内存溢出(System.OutOfMemoryException)的常见情况和处理方式总结
在什么情况下会出现OutOfMemonryException呢? 在我们试图新建一个对象时,而垃圾收集器又找不到任何可用内存时被抛出,这种情况下我们是可以捕获该异常的; 另一种情况是,CLR需要内存时,而却系统却不能提供,也会抛出该异常. 但此时,我们的应用程序是不能捕获该错误的.
 

内存溢出(OutOfMemoryException)的调试分析


32位操作系统的寻址空间是4G,其中有2G被操作系统占用,也就是说留给用户进程的内存只有2G(其中还要扣除程序加载时映像占用的部分空间,一般只有1.6G~1.8G左右可以使用)。 如果进程运行中需要申请内存,而操作系统无法为其分配内存空间,则会产生内存不足的异常,在.net中为System.OutOfMemoryException(The exception that is thrown when there is not enough memory tocontinue the execution of a program.)。 虽然最终的表现都为OutOfMemoryException,但其产生的原因可能是不一样的,动手解决此问题之前需要先对进程当前内存的使用状态进行分析,找出正确的原因,才能对症下药。下面分享一下调试此类问题的一些心得。

更多内容请参考:http://blog.csdn.net/lazyleland/article/details/6704661

iis应用程序池 内存溢出错误 System.OutOfMemoryException

在ASP.NET Web服务器上,ASP.NET所能够用到的内存,通常不会等同于所有的内存数量。在machine.config配置文件中,配置节<processModel>中有一个属性“memoryLimit”,这个属性的值是一个百分值,默认为“60”,即指定了ASP.NET进程(在任务管理器中大家就可以看到ASP.NET的进程,IIS5中为aspnet_wp,IIS6中为w3wp)能够使用所有物理内存的60%。当ASP.NET使用的内存量超过这个限额时,IIS会开始自动回收(recycle)进程,即创建一个新的进程去负责应付Http请求,而将旧进程所占用的内存回收。

当我们有一台很大内存的服务器时,“memoryLimit”这个值是需要进行适当的调整的。比如我们准备了一台chemas-microsoft-com ffice marttags" />t="on">4G内存的服务器,那么t="on">4G×60%=t="on">2.4G。但是,对于Win32操作系统,一个进程所能占用的所有内存空间只有t="on">2G。当ASP.NET进程占用的内存开始达到t="on">2G时,由于它并没有达到t="on">2.4G的“回收阈值”,所以IIS不会启动recycle进程操作,但是由于Win32的限制,实际上已经不能给这个进程分配更多的内存了,于是,OutOfMemoryException就很可能会被抛出了。为了避免这样的情况,我们就必须将“memoryLimit”适当调小,以让IIS更早的进行进程回收。

微软推荐的ASP.NET进程占用内存是不超过60%,并最好使计算出的实际值不超过t="on">800M。就是说,对于一台t="on">4G内存的服务器,最好将“memoryLimit”属性设置成“20”。设置一个适当的回收阈值,让IIS适时的进行进程回收,对于保证整个服务器的稳定运行,避免OutOfMemoryException是非常重要的。

在IIS6中,ASP.NET进程的回收阈值不再由配置节中的“memoryLimit”属性决定,而是由IIS管理器中的应用程序池配置中的设置决定。

但是,即使正确设置了这些配置,也不能保证完全避免OutOfMemoryException的发生,原因可能是多样而复杂的,比如内存回收操作可能耗时太多等等。开发人员要注意的,就是在代码中时刻牢记不要无谓的使用和浪费内存。:)

如果你有一台大内存的服务器,同时对Win32操作系统中对于进程最高使用t="on">2G内存的限制很郁闷,可选的解决方法有两个:

使用/3GB模式启动计算机,方法参加文后的链接
使用Windows Server 2003 64bits Edition
另外如果运行程序的机器是64位的,在vs里将程序的首选32位选项去掉,在项目属性,生成里 将首选32位这个勾选去掉
 

避免内存溢出的几点要素


如果要创建数组,请确保其大小正确。

确保有足够的内存用于内部用途和新的托管对象。

如果您正在 .NET Compact Framework 上进行编程,当没有足够的内存可用于内部用途或新的托管对象时,公共语言运行库会引发此异常。要避免此异常,应避免编写占用 64KB 或更多内存的大方法。

过多的托管内存使用量通常由以下因素造成:

将大型数据集读入内存中。
创建过多的缓存条目。
上载或下载大文件。
在分析文件时过多地使用正则表达式或字符串。
过多的视图状态。
会话状态中有过多的数据或者会话过多。
当对 COM 对象调用一个方法,并且该方法返回包含安全数组(大小不固定的数组)的用户定义类型时,可能引发此异常,并附带一条额外的消息“存储空间不足,无法完成此操作”。这是因为 .NET Framework 无法封送带有安全数组类型的结构字段。
一种不当使用字节数组导致内存溢出的情况举例

public partial class _Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        byte[] bytes = File.ReadAllBytes("D:\toClient.xls");//toClient.xls 大小为20M
        Response.BinaryWrite(bytes);
    }
}
上面的程序如果所输出的文件特别大的话,有可能会直接报:System.OutOfMemoryException。正确的做法是把文件的字节流分段输出,其实asp.net有现成的方法Response.WriteFile(filePath)就是这么做的。

如下是正确的写法:

Response.ContentType = "application/octet-stream";
Response.AddHeader("Content-Disposition", "attachment; filename=" + HttpUtility.UrlEncode(downloadName, System.Text.Encoding.UTF8));
Response.WriteFile("D:\toClient.xls");
Response.Flush();
Response.End();
当asp.net出现内存溢出时,一种简单的处理方法是马上回收应用程序池。但是这样并没有彻底解决问题。

创建Image类型时出现内存溢出(System.OutOfMemoryException)

错误代码: System.Drawing.Image myimg=System.Drawing.Image.FromFile(file.FullName);

当打开的文件不是图像文件时会引发的异常:

MSDN:如果文件没有有效的图像格式,或者如果 GDI+ 不支持文件的像素格式,则此方法将引发 OutOfMemoryException 异常。

这样的异常信息容易让人误解。
 

另外,在程序中适当的地方主动调用GC来回收

--- end ---

转载自:引发类型为“System.OutOfMemoryException”的异常-.Net 内存溢出_Jack2013tong的博客-CSDN博客_引发system.outofmemoryexception

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
  本书为框架设计师和广大开发人员设计高质量的软件提供了权威的指南。书中介绍了在设计框架时的最佳实践,提供了自顶向下的规范,其中所描述的规范普遍适用于规模不同、可重用程度不同的框架和软件。这些规范历经.NET框架三个版本的长期开发,凝聚了数千名开发人员的经验和智慧。微软的各开发组正在使用这些规范开发下一代影响世界的软件产品。 第1章 概述 1 1.1 精心设计的框架所具备的品质 2 1.1.1 精心设计的框架是简单的 2 1.1.2 精心设计的框架设计代价高 3 1.1.3 精心设计的框架充满利弊权衡 3 1.1.4 精心设计的框架应该借鉴过去 4 1.1.5 精心设计的框架要考虑未来发展 4 1.1.6 精心设计的框架应具有良好的集成性 4 1.1.7 精心设计的框架是一致的 4 第2章 框架设计基础 6 2.1 渐进框架 7 2.2 框架设计的基本原则 10 2.2.1 场景驱动设计的原则 11 2.2.2 低门槛原则 17 2.2.3 自说明对象模型原则 20 2.2.4 分层架构原则 25 2.3 小结 27 第3章 命名规范 28 3.1 大小写约定 29 3.1.1 标识符的大小写规则 29 3.1.2 首字母缩写词的大小写 31 3.1.3 复合词和常用术语的大小写 33 3.1.4 是否区分大小写 35 3.2 通用命名约定 35 3.2.1 单词的选择 36 3.2.2 使用单词缩写和首字母缩写词 37 3.2.3 避免使用语言特有的名字 38 3.2.4 为已有API的新版本命名 39 3.3 程序集和DLL的命名 42 3.4 名字空间的命名 43 3.5 类、结构和接口的命名 47 3.5.1 泛型类型参数的命名 49 3.5.2 常用类型的命名 50 3.5.3 枚举类型的命名 51 3.6 类型成员的命名 53 3.6.1 方法的命名 53 3.6.2 属性的命名 54 3.6.3 事件的命名 55 3.6.4 字段的命名 57 3.7 参数的命名 57 3.8 资源的命名 58 3.9 小结 59 第4章 类型设计规范 60 4.1 类型和名字空间 62 4.2 类和结构之间的选择 67 4.3 类和接口之间的选择 69 4.4 抽象类的设计 76 4.5 静态类的设计 78 4.6 接口的设计 79 4.7 结构的设计 81 4.8 枚举的设计 83 4.8.1 标记枚举的设计 89 4.8.2 给枚举添加值 93 4.9 嵌套类型 94 4.10 小结 96 第5章 成员设计 97 5.1 成员设计的一般规范 97 5.1.1 成员重载 97 5.1.2 显式地实现接口成员 102 5.1.3 属性和方法之间的选择 106 5.2 属性的设计 112 5.2.1 索引属性的设计 113 5.2.2 属性改变的通知事件 115 5.3 构造函数的设计 117 5.4 事件的设计 123 5.5 字段的设计 130 5.6 操作符重载 132 5.6.1 重载operator== 136 5.6.2 类型转换操作符 136 5.7 参数的设计 138 5.7.1 枚举和布尔参数之间的选择 140 5.7.2 参数的验证 142 5.7.3 参数的传递 145 5.7.4 参数数量可变的成员 147 5.7.5 指针参数 150 5.8 小结 152 第6章 为扩展性而设计 153 6.1 扩展机制 153 6.1.1 非密封类 153 6.1.2 保护成员 155 6.1.3 事件与回调函数 156 6.1.4 虚成员 158 6.1.5 抽象(抽象类型与抽象接口) 160 6.2 基类 162 6.3 密封 163 6.4 小结 166 第7章 异常 167 7.1 抛出异常 171 7.2 为抛出的异常选择合适的类型 175 7.2.1 错误消息的设计 176 7.2.2 异常处理 177 7.2.3 对异常进行封装 182 7.3 标准异常类型的使用 184 7.3.1 Exception与SystemException 184 7.3.2 ApplicationException 184 7.3.3 InvalidOperationException 184 7.3.4 ArgumentException、ArgumentNullException及ArgumentOutOfRangeException 185 7.3.5 NullReferenceException、IndexOutOfRangeException及AccessViolationException 186 7.3.6 StackOverflowException 186 7.3.7 OutOfMemoryException 187 7.3.8 ComException、SEHException及其他CLR异常 188 7.3.9 ExecutionEngineException 188 7.4 自定义异常的设计 188 7.5 异常与性能 190 7.5.1 Tester-Doer模式 190 7.5.2 Try-Parse模式 191 7.6 小结 192 第8章 使用规范 193 8.1 数组 193 8.2 attribute 195 8.3 集合 198 8.3.1 集合参数 199 8.3.2 集合属性与返回值 200 8.3.3 数组与集合之间的选择 204 8.3.4 自定义集合的实现 205 8.4 ICloneable 207 8.5 IComparableT与IEquatableT 208 8.6 IDisposable 210 8.7 对象 210 8.7.1 Object.Equals 210 8.7.2 Object.GetHashCode 212 8.7.3 Object.ToString 213 8.8 Uri 214 8.9 System.Xml的使用 216 8.10 相等性操作符 218 8.10.1 值类型的相等性操作符 218 8.10.2 引用类型的相等性操作符 219 第9章 常用的设计模式 220 9.1 聚合组件 220 9.1.1 面向组件的设计 222 9.1.2 因子类型 224 9.1.3 聚合组件规范 224 9.2 Async模式 227 9.3 Dispose模式 232 9.3.1 基本Dispose模式 234 9.3.2 可终结类型 240 9.4 Factory模式 243 9.5 Optional Feature模式 247 9.6 Template Method模式 251 9.7 超时 252 9.8 结束语 254 附录A C#编程风格约定 255 A.1 通用风格约定 255 A.1.1 花括号的使用 255 A.1.2 空格的使用 257 A.1.3 缩进的使用 259 A.2 命名约定 259 A.3 注释 260 A.4 文件的组织 261 附录B 通过FxCop来实施设计规范 263 B.1 FxCop是什么? 263 B.2 FxCop的发展过程 264 B.3 FxCop的工作原理 265 B.4 FxCop规范的覆盖范围 265 B.4.1 与命名规范有关的FxCop规则 265 B.4.2 与类型设计规范有关的FxCop规则 274 B.4.3 与成员的设计有关的FxCop规则 277 B.4.4 与为扩展性而设计有关的FxCop规则 284 B.4.5 与异常有关的FxCop规则 285 B.4.6 与使用规范有关的FxCop规则 287 B.4.7 与设计模式有关的FxCop规则 291 附录C API规范样例 292 术语表 299 推荐读物 303 索引 305
Power BI是一款用于数据分析和可视化的强大工具,但在处理大量数据或复杂计算时,可能会引发一些异常,其中之一就是“System.OutOfMemoryException异常。 当我们在Power BI中加载或处理大量数据时,可能会遇到内存不足的问题,导致系统无法为应用程序分配足够的内存空间,从而引发“System.OutOfMemoryException异常。 这种异常的出现通常是由以下原因引起的: 1. 数据量过大:当我们尝试加载和处理大量的数据时,系统的内存可能无法容纳全部数据,导致内存不足的异常。 2. 复杂的计算:如果我们在Power BI中进行复杂的计算操作,可能会消耗大量的内存资源,从而导致内存溢出。 3. 不合理的内存管理:如果我们在Power BI中使用了不合理的内存管理方法,例如频繁地创建和销毁对象,可能会造成内存碎片和内存泄漏,最终导致内存不足异常。 为了解决这个问题,我们可以尝试以下方法: 1. 减少数据量:如果我们的数据集过大,可以考虑筛选、聚合或分段加载数据,以减少内存压力。 2. 优化计算操作:优化复杂计算的算法,减少计算量,提高计算效率,从而减少内存占用。 3. 合理管理内存:在编写Power BI代码时,合理利用内存,避免不必要的内存分配和释放操作,例如使用缓存、复用对象等方法来减少内存占用。 4. 增加系统内存:如果以上方法无法解决问题,可以考虑扩大系统的内存容量,以支持更大规模的数据处理和计算操作。 总之,当我们在Power BI中遇到“System.OutOfMemoryException异常时,需要仔细分析异常引发的原因,并采取相应的优化措施来解决该问题。同时,合理规划和管理内存资源,以确保应用程序在处理大数据量和复杂计算时不会出现内存不足的异常

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值