中断与异常模型图
内中断
内中断是由 CPU 内部事件引起的中断,通常是在程序执行过程中由于 CPU 自身检测到某些异常情况而产生的。例如,当执行除法运算时除数为零,或者访问了不存在的内存地址,CPU 就会产生内中断。
故障Fault
故障是在指令执行过程中检测到的错误情况导致的内中断,比如空指针,除0异常,缺页中断等
自陷Trap
这是一种有意的内中断,是由软件预先设定的特殊指令或操作引起的。比如syscall,int 3这种故意设定的陷阱
终止abort
终止是一种比较严重的内中断,通常是由于不可恢复的硬件错误或者软件严重错误导致的,比如内存硬件损坏、Cache 错误等
硬件异常
CPU内部产生的异常事件
用户异常
软件模拟出的异常,比如操作系统的SEH,.NET的OutOfMemoryException
外中断
外中断是由 CPU 外部的设备或事件引起的中断。比如键盘,鼠标,主板定时器。这些外部设备通过向 CPU 发送中断请求信号来通知 CPU 需要处理某个事件。外中断是计算机系统与外部设备进行交互的重要方式,使得 CPU 能够及时响应外部设备的请求,提高系统的整体性能和响应能力。
NMI(Non - Maskable Interrupt,非屏蔽中断)
NMI 是一种特殊类型的中断,它不能被 CPU 屏蔽。与普通中断(可以通过设置中断屏蔽位来阻止 CPU 响应)不同,NMI 一旦被触发,CPU 必须立即响应并处理。这种特性使得 NMI 通常用于处理非常紧急且至关重要的事件,这些事件的优先级高于任何其他可屏蔽中断。
INTR(Interrupt Request,中断请求)
INTR 是 CPU 用于接收外部中断请求的引脚(在硬件层面)或者信号机制(在软件层面)。外部设备(如磁盘驱动器、键盘、鼠标等)通过向 CPU 的 INTR 引脚发送信号来请求 CPU 中断当前任务,为其提供服务。这是计算机系统实现设备交互和多任务处理的关键机制之一。
用户异常
C#的异常,在Windows平台下是完全围绕SEH处理框架来展开。在Linux上则是围绕signal模拟成SEH结构,因为都会进入内核态,所以其开销并不低,内部走了很多流程。
static void Main(string[] args)
{
try
{
var num = Convert.ToInt32("a");
}
catch (Exception ex)
{
Debugger.Break();
Console.WriteLine(ex.Message);
}
Console.ReadLine();
}
眼见为实:用户Execption的调用栈
硬件异常
硬件异常指CPU执行机器码出现异常后,由CPU通知操作系统,操作系统再通知进程触发的异常。
比如:
内核模式切换:syscall
访问违例:AccessViolationException
visual studio中F9中断:int 3
static void Main(string[] args)
{
try
{
string str = null;
var len = str.Length;
Console.WriteLine(len);
}
catch (Exception ex)
{
Debugger.Break();
Console.WriteLine(ex.ToString());
}
Console.ReadLine();
}
与用户异常不同的是,异常的发起点在CPU上,并且CLR为了统一处理。会先将硬件异常转换成用户异常。以此来复用后续逻辑。所以相比用户异常,硬件异常的开销更大
眼见为实:硬件Execption的调用栈
硬件异常如何与用户异常绑定?
上面说到,CLR会先将硬件异常转换成用户异常。那么在抛出异常的时候,如何正确抛出一个托管堆认识的异常呢?
以空指针异常为例
核心逻辑在ProcessCLRException中,它会判断 Thread 是否挂了异常?没有的话就会通过MapWin32FaultToCOMPlusException来转换,然后通过 pThread.SafeSetThrowables 塞入到线程里。从而实现了硬件异常在托管堆上的映射。
眼见为实
上源码
https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/excep.cpp
.NET 异常处理流程
对.NET Runtime来说,主要实现以下四个操作
捕获异常并抛出异常的位置
通过线程栈空间获取异常调用栈
线程的栈空间维护了整个调用栈,扫描整个栈空间即可获取。
windbg的k系列命令就是参考此原理。
- 获取元数据的异常处理表
一旦方法中有try-catch语句块时,JIT会将try-catch的适用范围记录下来,并整理成异常处理表(Execption Handling Table , EH Table)
C# 代码
public class ExceptionEmample
{
public static void Example()
{
try
{
Console.WriteLine("Try outer");
try
{
Console.WriteLine("Try inner");
}
catch (Exception)
{
Console.WriteLine("Catch Expception inner");
}
}
catch (ArgumentException)
{
Console.WriteLine("Catch ArgumentException outer");
}
catch (Exception)
{
Console.WriteLine("Catch Exception outer");
}
finally
{
Console.WriteLine("Finally outer");
}
}
}
IL代码
.method public hidebysig static void Example() cil managed
{
// Code size 96 (0x60)
.maxstack 1
IL_0000: nop
IL_0001: nop
IL_0002: ldstr "Try outer"
IL_0007: call void [System.Console]System.Console::WriteLine(string)
IL_000c: nop
IL_000d: nop
IL_000e: ldstr "Try inner"
IL_0013: call void [System.Console]System.Console::WriteLine(string)
IL_0018: nop
IL_0019: nop
IL_001a: leave.s IL_002c
IL_001c: pop
IL_001d: nop
IL_001e: ldstr "Catch Expception inner"
IL_0023: call void [System.Console]System.Console::WriteLine(string)
IL_0028: nop
IL_0029: nop
IL_002a: leave.s IL_002c
IL_002c: nop
IL_002d: leave.s IL_004f
IL_002f: pop
IL_0030: nop
IL_0031: ldstr "Catch ArgumentException outer"
IL_0036: call void [System.Console]System.Console::WriteLine(string)
IL_003b: nop
IL_003c: nop
IL_003d: leave.s IL_004f
IL_003f: pop
IL_0040: nop
IL_0041: ldstr "Catch Exception outer"
IL_0046: call void [System.Console]System.Console::WriteLine(string)
IL_004b: nop
IL_004c: nop
IL_004d: leave.s IL_004f
IL_004f: leave.s IL_005f
IL_0051: nop
IL_0052: ldstr "Finally outer"
IL_0057: call void [System.Console]System.Console::WriteLine(string)
IL_005c: nop
IL_005d: nop
IL_005e: endfinally
IL_005f: ret
IL_0060:
// Exception count 4
.try IL_000d to IL_001c catch [System.Runtime]System.Exception handler IL_001c to IL_002c
.try IL_0001 to IL_002f catch [System.Runtime]System.ArgumentException handler IL_002f to IL_003f
.try IL_0001 to IL_002f catch [System.Runtime]System.Exception handler IL_003f to IL_004f
.try IL_0001 to IL_0051 finally handler IL_0051 to IL_005f
} // end of method ExceptionEmample::Example
IL代码中最后4行就代表了方法的异常处理表。
1. IL_000d to IL_001c 之间代码发生的Exception异常由IL_001c to IL_002c 之间的代码处理
2. IL_0001 to IL_002f 之间发生的ArgumentException异常由IL_002f to IL_003f之间的代码处理
3. IL_0001 to IL_002f 之间发生的Exception异常由IL_003f to IL_004f之间的代码处理
4. IL_0001 to IL_0051 之间无论发生什么,结束后都要执行IL_0051 to IL_005f之间的代码
枚举异常处理表,调用对应的catch块与finally块
当异常发生时,Runtime会枚举EH Table,找出并调用对应的catch块与finally块。
核心方法为ProcessManagedCallFrame:
https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/exceptionhandling.cpp
需要注意的是,一旦CLR找到catch块,就会先执行内层所有finally块中的代码,再等到当前catch块中的代码执行完毕finally才会执行
重新抛出异常
在执行catch,finally的过程中,如果又抛出了异常。程序会再次进入ProcessCLRException中走重复流程。
但是调用链会消失,如果想要防止调用链丢失,需要特殊处理。
static void Main(string[] args)
{
try
{
Test();
}
catch (Exception ex)
{
Console.WriteLine(ex);
}
} private static void Test()
{
try
{
throw new Exception("test");
}
catch (Exception ex)
{
}
}
我在这里踩过大坑,使用throw ex重新抛出异常,结果丢失了异常真正的触发点,日志跟没记一样。
finally一定会执行吗?
常规情况下,finally是保证会执行的代码,但如果直接用win32函数TerminateThread杀死线程,或使用System.Environment的Failfast杀死进程,finally块不会执行。
先执行return还是先执行finally?
C#代码
~~~
public static int Example2()
{
try
{
return 100+100;
}
finally
{
Console.WriteLine("finally");
}
}
~~~
IL代码
.method public hidebysig static int32 Example2() cil managed
{
.maxstack 1
.locals init (int32 V_0)
IL_0000: nop
IL_0001: nop
IL_0002: ldc.i4.1
IL_0003: stloc.0
IL_0004: leave.s IL_0014
IL_0006: nop
IL_0007: ldstr "finally"
IL_000c: call void [System.Console]System.Console::WriteLine(string)
IL_0011: nop
IL_0012: nop
IL_0013: endfinally
IL_0014: ldloc.0
IL_0015: ret
IL_0016:
.try IL_0001 to IL_0006 finally handler IL_0006 to IL_0014
}
从IL中可以看到,当try中包含return语句时,编译器会生成一个临时变量将返回值保存起来。然后再执行finally块。最后再return 临时变量。这个过程称为局部展开(local unwind)
再举一个例子
C#代码
public static int Test()
{
int result = 1;
try
{
return result;
}
finally
{
result = 3;
}
}
IL代码
.method public hidebysig static int32 Test() cil managed
{
.maxstack 1
.locals init (int32 V_0,
int32 V_1)
IL_0000: nop
IL_0001: ldc.i4.1
IL_0002: stloc.0
IL_0003: nop
IL_0004: ldloc.0
IL_0005: stloc.1
IL_0006: leave.s IL_000d
IL_0008: nop
IL_0009: ldc.i4.3
IL_000a: stloc.0
IL_000b: nop
IL_000c: endfinally
IL_000d: ldloc.1
IL_000e: ret
IL_000f:
.try IL_0003 to IL_0008 finally handler IL_0008 to IL_000d
}
虽然在finally块中修改了result的值,但是return语句已经确定了要返回的值,finally块中的修改不会改变这个返回值。不过,如果返回的是引用类型),在finally块中修改引用类型对象的内容是会生效的异常对性能的影响
引用别人的数据,自己就不班门弄斧了
大佬的研究
https://www.cnblogs.com/huangxincheng/p/12866824.html
<.NET Core底层入门>
总体来说,只要进入内核态。就没有开销低的。
CLS与非CLS异常(历史包袱)
在CLR的2.0版本之前,CLR只能捕捉CLS相容的异常。如果一个C#方法调用了其他编程语言写的方法,且抛出一个非CLS相容的异常。那么C#无法捕获到该异常。
在后续版本中,CLR引入了RuntimeWrappedException类。当非CLS相容的异常被抛出时,CLR会自动构造RuntimeWrappedException实例。使之与与CLS兼容
public static void Example2()
{
try
{
}
catch(Exception)
{
}
catch
{
}
}
.NET 9 的改进
.NET 9 重写了异常处理机制,新实现基于 NativeAOT Runtime的异常处理模型。
https://learn.microsoft.com/zh-cn/dotnet/core/whats-new/dotnet-9/runtime#faster-exceptions
转自https://www.cnblogs.com/lmy5215006/p/18604440
该文章在 2024/12/19 10:40:06 编辑过