一起谈.NET技术,.Net Discovery系列之-深入理解平台机制与性能影响(下)

简介:   三.关于异常捕获机制   虽然我们已经很辛苦了,但是仍然有很多原因使代码运行失败,如引用null引用、索引越界、内存溢出、类型转换失败等等。这就需要我们的代码有足够的容错能力,在代码运行失败时,及时、主动的处理这些异常。

  三.关于异常捕获机制

  虽然我们已经很辛苦了,但是仍然有很多原因使代码运行失败,如引用null引用、索引越界、内存溢出、类型转换失败等等。这就需要我们的代码有足够的容错能力,在代码运行失败时,及时、主动的处理这些异常。

  ● 机制分析

  .Net 中基本的异常捕获与处理机制是由try…catch…finally块来完成的,它们分别完成了异常的监测、捕获与处理工作。一个try块可以对应零个或多个catch块,可以对应零个或一个finally块。不过没有catch的try似乎没有什么意义,如果try对应了多个catch,那么监测到异常后,CLR会自上而下搜索catch块的代码,并通过异常过滤器筛选对应的异常,如果没有找到,那么CLR将沿着调用堆栈,向更高层搜索匹配的异常,如果已到堆栈顶部依然没有找到对应的异常,就会抛出未处理的异常了,这时catch块中的代码并不会被执行。所以距离try最近的catch块将最先被遍历到。

  以下代码:

代码
 
  
try
{
Convert.ToInt32(
" Try " );
}
catch (FormatException ex1)
{
string CatchFormatException = " CatchFormatException " ;
}
catch (NullReferenceException ex2)
{
string CatchNullReferenceException = " CatchNullReferenceException " ;
}
finally
{
string Finally = " Finally " ;
}
 对应IL如下:
.method private hidebysig instance void Form1_Load(object sender,
class [mscorlib]System.EventArgs e) cil managed
{
// Code size 53 (0x35)
.maxstack 1
.locals init ([
0] class [mscorlib]System.FormatException ex1,
[
1] string CatchFormatException,
[
2] class [mscorlib]System.NullReferenceException ex2,
[
3] string CatchNullReferenceException,
[
4] string Finally)
IL_0000: nop
IL_0001: nop
IL_0002: ldstr
"Try"
IL_0007: call int32 [mscorlib]System.Convert::ToInt32(
string)
IL_000c: pop
IL_000d: nop
IL_000e: leave.s IL_0026
IL_0010: stloc.0

IL_0011: nop
IL_0012: ldstr
"CatchFormatException"
IL_0017: stloc.
1
IL_0018: nop
IL_0019: leave.s IL_0026
IL_001b: stloc.
2
IL_001c: nop
IL_001d: ldstr
"CatchNullReferenceException"
IL_0022: stloc.
3
IL_0023: nop
IL_0024: leave.s IL_0026
IL_0026: nop
IL_0027: leave.s IL_0033
IL_0029: nop
IL_002a: ldstr
"Finally"
IL_002f: stloc.s Finally
IL_0031: nop
IL_0032: endfinally
IL_0033: nop
IL_0034: ret
IL_0035:
// Exception count 3
.try IL_0001 to IL_0010 catch [mscorlib]System.FormatException handler IL_0010 to IL_001b
.
try IL_0001 to IL_0010 catch
[mscorlib]System.NullReferenceException handler IL_001b to IL_0026
.
try IL_0001 to IL_0029 finally
handler IL_0029 to IL_0033
}
// end of method Form1::Form1_Load
 
 

  末尾的几行代码揭示出IL是怎样处理异常处理的。最后三行的每一个Item被称作Exception Handing Clause,EHC组成Exception Handing Table,EHT与正常代码之间由ret返回指令隔开。

  可以看出,FormatException排列在EHT的第一位。

  当代码成功执行或反之而返回后,CLR会遍历EHT:

  1. 如果抛出异常, CLR会根据抛出异常的代码的地址找到对应的EHC(IL_0001 to IL_0010为检测代码的范围),这个例子中CLR将找到2条EHC, FormatException会最先被遍历到,且为适合的EHC。

  2. 如果返回的代码地址在IL_0001 to IL_0029内,那么还会执行finally handler IL_0029 to IL_0033中的代码,不管是否因成功执行代码而返 回

  事实上,catch与finally的遍历工作是分开进行的,如上文所言,CLR首先做的是遍历catch,当找到合适的catch块后,再遍历与之对应finally;而且这个过程会递归进行至少两次,因为编译器将C#的try…catch…finally翻译成IL中的两层嵌套。

当然如果没有找到对应的catch块,那么CLR会直接执行finally,然后立即中断所有线程。Finally块中的代码肯定会被执行,无论try是否检测到了异常。

  ● 性能影响与改进建议

  异常捕获与处理是有性能代价的,虽然这种代价在托管环境中度量起来比较困难,但是这个过程毕竟经过一系列的遍历。所以仅从性能方面考虑,一般建议有以下几点准则:

  1.尽量给CLR一个明确的异常信息,不要使用Exception去过滤异常

  2.尽量不要将try…catch写在循环中

  3. try尽量少的代码,如果有必要可以使用多个catch块,并且将最有可能抛出的异常类型,书写在距离try最近的位置

  4.不要只声明一个Exception对象,而不去处理它

  5.使用性能计数器实用工具的CLR Exceptions检测异常情况,并适当优化

  6.使用成员的Try-Parse模式,如果抛出异常,那么用false代替它

  四.关于字符串拼接

  ● 机制分析

  .Net字符串型的变量有一个很特殊的机制,这个机制叫做字符串的驻留,其变现为字符串恒定不可改变。

  简单的说,字符串一旦建立,就会永久驻留在内存中,当你修改这个字符串变量时,CLR会在内存中新建一个新值,并不会修改旧值,旧值只有被垃圾回收器回收后,那部分被占用的空间才会释放掉。

  这样设计的目的无疑是为了提高字符串型变量的建立,因为新建字符串型变量时,CLR首先做的是在驻留池中遍历是否有相同的值的字符串,如果有则直接挂接变量指针,否则才会新建,但是在某些情况下,性能却反而降低。

  ● 性能影响与改进建议

  下面通过例子简单的说一下字符串驻留机制,假设有如下代码:

 
 
string str = ""
string a = " str_1 " + str;
a
= " str_2 " + str;

  第三行C#代码(a = "str_2"+ str;)的样子看起来是在修改变量a的旧值"str_1",但实际上是创建了一个新的字符串"str_2",然后将变量a的指针指向了"str_2"的内存地址,而"str_1"依然在内存中没有受到任何影响 ---这就是字符串的驻留,如果下一次有变量b的值被赋值为str_1,CLR不会重新为这个变量重新分配内存,而是直接将该变量的指针指向str_1,这样就提高了该变量的初始化速度,但是如果没有这样的一个b变量,那么str_1就会一直占用内存,直至垃圾收集,这样做浪费了内存资源。

  同样ToUpper、SubString、Trim、Replace、加号连接等操作都会产生驻留的字符串,各位在设计程序时要特别注意。

  经常看到有的同学使用Replace替换一个网页整个HTML的某些关键字,其实这样会极大的浪费内存,给垃圾回收器的策略引擎以错误的信号,使其频繁启动,从而导致性能的降低。

  所以,有以下建议供大家参考:

  1.在用Replace做大量字符串操作时,最好仅仅对最小单元进行操作

  2在尽量少的字符串中替换,有必要时还要配合正则的使用,在替换完毕后最好根据上下文的代龄情况,手动调用一次GC的回收方法;

  3.对大规模的字符串拼接操作,则推荐使用StringBuilder

  4.能用常量赋值的就别用变量。因为常量赋值的字符串是在编译器生成在字符串常量池的,关于常量池请参考Aicken以前的文章。

  相关文章:.Net Discovery系列-深入理解平台机制与性能影响(上)

                      .Net Discovery系列之-深入理解平台机制与性能影响 (中)

目录
相关文章
|
19天前
|
人工智能 前端开发 开发工具
解读.NET 技术的开发潜力
本文全面介绍了.NET技术在软件开发领域的核心优势、创新应用及面临的挑战。.NET以其统一的开发平台、强大的工具和跨平台能力,成为企业级应用、Web应用乃至游戏开发的理想选择。然而,在性能优化、容器化及AI集成等方面仍需不断突破。通过积极拥抱开源和社区驱动模式,.NET将持续推动软件开发的进步。
38 1
|
1月前
|
监控 网络协议 API
.NET WebSocket 技术深入解析,你学会了吗?
【9月更文挑战第4天】WebSocket 作为一种全双工协议,凭借低延迟和高性能特点,成为实时应用的首选技术。.NET 框架提供了强大的 WebSocket 支持,使实时通信变得简单。本文介绍 WebSocket 的基本概念、.NET 中的使用方法及编程模型,并探讨其在实时聊天、监控、在线游戏和协同编辑等场景的应用,同时分享最佳实践,帮助开发者构建高效实时应用。
80 12
|
25天前
|
人工智能 前端开发 Devops
.NET技术自发布以来,在软件开发领域发挥了重要作用
【9月更文挑战第12天】.NET技术自发布以来,在软件开发领域发挥了重要作用。本文分为三部分探讨其在现代开发中的应用:首先介绍.NET的核心价值,包括语言多样性、强大的开发工具支持、丰富的类库、跨平台能力和活跃的社区;接着分析其在企业级应用、Web开发、移动应用、云服务及游戏开发中的实际应用;最后讨论.NET面临的挑战与未来趋势,如性能优化、容器化、AI集成及跨平台框架竞争等。通过不断的技术创新和社区驱动,.NET将持续推动软件开发的进步。
29 4
|
1月前
|
人工智能 开发框架 算法
C#/.NET/.NET Core技术前沿周刊 | 第 2 期(2024年8.19-8.25)
C#/.NET/.NET Core技术前沿周刊 | 第 2 期(2024年8.19-8.25)
|
1月前
|
传感器 应用服务中间件 Linux
C#/.NET/.NET Core技术前沿周刊 | 第 3 期(2024年8.26-8.31)
C#/.NET/.NET Core技术前沿周刊 | 第 3 期(2024年8.26-8.31)
|
1月前
|
人工智能 算法 C#
C#/.NET/.NET Core技术前沿周刊 | 第 1 期(2024年8.12-8.18)
C#/.NET/.NET Core技术前沿周刊 | 第 1 期(2024年8.12-8.18)
|
2月前
|
开发者 API Windows
从怀旧到革新:看WinForms如何在保持向后兼容性的前提下,借助.NET新平台的力量实现自我进化与应用现代化,让经典桌面应用焕发第二春——我们的WinForms应用转型之路深度剖析
【8月更文挑战第31天】在Windows桌面应用开发中,Windows Forms(WinForms)依然是许多开发者的首选。尽管.NET Framework已演进至.NET 5 及更高版本,WinForms 仍作为核心组件保留,支持现有代码库的同时引入新特性。开发者可将项目迁移至.NET Core,享受性能提升和跨平台能力。迁移时需注意API变更,确保应用平稳过渡。通过自定义样式或第三方控件库,还可增强视觉效果。结合.NET新功能,WinForms 应用不仅能延续既有投资,还能焕发新生。 示例代码展示了如何在.NET Core中创建包含按钮和标签的基本窗口,实现简单的用户交互。
53 0
|
1月前
|
开发框架 前端开发 JavaScript
ASP.NET MVC 教程
ASP.NET 是一个使用 HTML、CSS、JavaScript 和服务器脚本创建网页和网站的开发框架。
28 7
|
29天前
|
存储 开发框架 前端开发
ASP.NET MVC 迅速集成 SignalR
ASP.NET MVC 迅速集成 SignalR
39 0
|
2月前
|
开发框架 前端开发 .NET
ASP.NET MVC WebApi 接口返回 JOSN 日期格式化 date format
ASP.NET MVC WebApi 接口返回 JOSN 日期格式化 date format
37 0