在项目中摸爬滚打几年应该或多或少的见过有人把异常当做业务逻辑处理的情况(┬┬)比如说判断一个数字是否为整数,就想当然的用try catch包起来再进行int.Parse如果抛异常就说明不是整数简单粗暴也不需要写正则或者其他逻辑再比如一个字符串强制转化为Enum直接用Enum.Parse可能是因为对异常的开销不是特别了解这种不好的使用习惯也许被官方发现了后续给我们补了很多的Try前缀的方法比如int.TryParse,Enum.TryParse,dict.TryGetValue,用代码展示如下//原始写法 var num int.Parse(1); //使用try方式 var result 0; var b int.TryParse(1, out result);用Try系列方法没毛病但这写法让人吐槽还要单独定义result变量没撤官方还得靠我们这些开发者给他们发扬光大终于在C# 7.0 中新增了一个out variables语法糖。//try out 变量模式 var c int.TryParse(1, out int result2);这种out 变量模式就了一个方法获取两个值还没有抛异常的风险。二为什么要用tryxxx方法有了tryxxx方法之后你就应该明白微软已经在提醒我们开发人员不要滥用异常尤其在可预知可预见的场景下毕竟他们知道异常的开销真的是太大了不知者不怪哈。1. 肉眼看得见的低性能为了让大家肉眼能看见我们就用异常方法和tryxxx方法做一个性能比较迭代50w次看看各自的性能如何for (int i 0; i 3; i) { var watch Stopwatch.StartNew(); for (int k 0; k 50000; k) { try { var num int.Parse(xxx); } catch (Exception ex) { } } watch.Stop(); Console.WriteLine($i{i 1},耗费{watch.ElapsedMilliseconds}); } Console.WriteLine(---------------------------------------------); for (int i 0; i 3; i) { var watch Stopwatch.StartNew(); for (int k 0; k 50000; k) { var num int.TryParse(xxx, out int reuslt); } watch.Stop(); Console.WriteLine($i{i 1},耗费{watch.ElapsedMilliseconds}); } Console.ReadLine();看结果还挺吓人的相差480倍 好熟悉的一个数字。。。南朝四百八十寺多少楼台烟雨中三 异常的超强开销为什么异常有那么大的开销 只有知己知彼才能心中有数看过我多线程视频的朋友应该知道线程的创建和销毁代价都是非常大的其中有一项就是需要代码从用户态切换到了内核态毕竟线程是操作系统层面的事情和你CLR无关CLR只是做了一层系统包装而已其实很多人都想不到我们用的try catch finally底层也是封装了操作系统层面的Windows 结构化异常处理也叫做SEH什么意思 就是当你throw之后代码需要从用户态切换到内核态这个开销是不会小的还有一个开销来自于Exception中的StackTrace这里面的值需要从当前异常的线程栈中去抓取调用堆栈栈越深开销就越大。1. 从用户态到内核态大家肯定会说甭那么玄乎凡事都要讲个证据,Do more,Talk less 这里我准备分两种情况讲解。1 有catch情况准备在catch的时候阻塞住然后抓它的dump文件。public static void Main(string[] args) { try { var num int.Parse(xxx); } catch (Exception ex) { Console.WriteLine(ex.Message); Console.ReadLine(); } }使用!dumpstack把当前 0号线程 的所有托管和非托管堆栈全部打出来简化后如下0:000 ~0s ntdll!NtReadFile0x14: 00007ffff805aa64 c3 ret 0:000 !dumpstack OS Thread Id: 0x2bf0 (0) Current frame: ntdll!NtReadFile0x14 Caller, Callee (MethodDesc 00007fffde3a40b8 0x18 System.Console.ReadLine()) (MethodDesc 00007fff810d59f8 0xa5 ConsoleApp4.Program.Main(System.String[])), calling (MethodDesc 00007fffde3a40b8 0 System.Console.ReadLine()) 00000044433fc700 00007fffe07a29e0 clr!ExceptionTracker::CallCatchHandler0x9c, calling clr!ExceptionTracker::CallHandler clr!ClrUnwindEx0x40, calling ntdll!RtlUnwindEx ntdll!RtlRaiseException0x4e, calling ntdll!RtlpCaptureContext clr!IL_Throw0x114, calling clr!RaiseTheExceptionInternalOnly (MethodDesc 00007fffde4f95c0 System.Number.StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean)), calling mscorlib_ni0x53976a (MethodDesc 00007fffde3b5330 0xae System.Number.ParseInt32(System.String, System.Globalization.NumberStyles, System.Globalization.NumberFormatInfo)), calling (MethodDesc 00007fffde4f95c0 0 System.Number.StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean)) (MethodDesc 00007fffde1ebfa8 0x2eb System.Globalization.NumberFormatInfo..ctor(System.Globalization.CultureData)), calling (MethodDesc 00007fffde1eba68 0 System.Globalization.CultureData.GetNFIValues(System.Globalization.NumberFormatInfo)) (MethodDesc 00007fff810d59f8 0x49 ConsoleApp4.Program.Main(System.String[])), calling (MethodDesc 00007fffde3b1708 0 System.Int32.Parse(System.String))因为是堆栈所以执行流就要从后往前看你会发现流程大概是这个样子int.Parse - CLR - ntdll - CLR - Console.ReadLine很显然 ntdll.dll 是操作系统层级的一个核心文件这就从用户态切入到了内核态如果不是很明白我画一张简图吧。。。2. 无catch处理大家肯定很好奇如果无catch会是怎么样大家也可以用windbg去挖一下。public static void Main(string[] args) { var num int.Parse(xxx); } 0:000 !dumpstack OS Thread Id: 0xd68 (0) Current frame: ntdll!NtTerminateProcess0x14 Caller, Callee mscoreei!RuntimeDesc::ShutdownAllActiveRuntimes0x285, calling KERNEL32!ExitProcessImplementation mscoreei!CLRRuntimeHostInternalImpl::ShutdownAllRuntimesThenExit0x14, calling mscoreei!RuntimeDesc::ShutdownAllActiveRuntimes clr!EEPolicy::ExitProcessViaShim0x9c clr!SafeExitProcess0x9d, calling clr!EEPolicy::ExitProcessViaShim ntdll!KiUserExceptionDispatch0x53, calling ntdll!NtRaiseException clr!RaiseTheExceptionInternalOnly0x188426, calling clr!EEPolicy::HandleFatalError clr!IL_Throw0x45, calling clr!LazyMachStateCaptureState (MethodDesc 00007fffde4f95c0 System.Number.StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean)), calling mscorlib_ni0x53976a (MethodDesc 00007fffde3b5330 0xae System.Number.ParseInt32(System.String, System.Globalization.NumberStyles, System.Globalization.NumberFormatInfo)), calling (MethodDesc 00007fffde4f95c0 0 System.Number.StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean)) (MethodDesc 00007fffde1ebfa8 0x2eb System.Globalization.NumberFormatInfo..ctor(System.Globalization.CultureData)), calling (MethodDesc 00007fffde1eba68 0 System.Globalization.CultureData.GetNFIValues(System.Globalization.NumberFormatInfo)) (MethodDesc 00007fff810e59f8 0x37 ConsoleApp4.Program.Main(System.String[])), calling (MethodDesc 00007fffde3b1708 0 System.Int32.Parse(System.String))可以看到进程的退出逻辑给了托管程序入口mscoreei.dll而再也没有进入Main函数了 为此我也补一张图给大家看看2. 抓取线程调用栈当大家慌慌张张的看到异常的时候第一眼会去看异常信息是什么 第二眼会去看异常出在了哪一行代码这就是线程的调用栈这个信息非常重要可以快捷的帮助我们找到问题解决问题放在Exception的StackTrace中先上一段代码。public static void Main(string[] args) { Run(); Console.ReadLine(); } public static void Run() { var ex new FormatException(你的格式错误啦); throw ex; }1 StackTrace何时塞入的到目前为止还没看到哪本书说到StackTrace是何时被塞入的 由于水平有限我也试着探测一下下。从代码中可以看到不是在new的时候塞入的那会是哪里呢2 从CLR中寻找答案既然不在用户代码那就到CLR中去看看在windbg中用dumpstack去查看非托管堆栈。0:000 !dumpstack OS Thread Id: 0x4090 (0) Current frame: ntdll!NtTerminateProcess0x14 Caller, Callee clr!EETypeHashTable::FindItem0x532, calling clr!NgenHashTableEEClassHashTable,EEClassHashEntry,4::PersistedBucketList::GetBucket clr!JIT_StrCns0xd0, calling clr!HelperMethodFrameRestoreState (MethodDesc 00007fff810f5a08 0x70 ConsoleApp4.Program.Run()), calling clr!IL_Throw clr!IL_Throw0x45, calling clr!LazyMachStateCaptureState (MethodDesc 00007fff810f5a08 0x70 ConsoleApp4.Program.Run()), calling clr!IL_Throw (MethodDesc 00007fff810f59f8 0x28 ConsoleApp4.Program.Main(System.String[])), calling 00007fff81200488 (stub for ConsoleApp4.Program.Run())从简化后的流程看怀疑是由clr!HelperMethodFrameRestoreState处理的为什么这么说呢 因为我们定义的FormatException ex会传给CLR的不信可以用kb看一看。0:000 kb # RetAddr : Args to Child : Call Site 00 00007fffe07a3181 : 00000000e0434352 0000006d4a7fe938 0000017b30ad2d48 0000017b2f081690 : KERNELBASE!RaiseException0x68 01 00007fffe07a45f4 : fffffffffffffffe 0000017b2ef02542 000000000000000a 0000017b2f040910 : clr!RaiseTheExceptionInternalOnly0x31f 02 00007fff811d0950 : 0000000070000001 00007fff810c4140 0000006d4a7fedb8 0000006d4a7fec78 : clr!IL_Throw0x114 03 00007fff811d08b8 : 0000017b30ad2d30 00007fff810c4140 0000000000000000 00007fff00000000 : 0x00007fff811d0950 04 00007fffe0736c93 : 0000017b30ad2d30 00007fff810c4140 0000000000000000 00007fff00000000 : 0x00007fff811d08b8 05 00007fffe0736b79 : 0000000000000000 00007fffe0737aae 0000006d4a7fefb8 0000000000000000 : clr!CallDescrWorkerInternal0x83 06 00007fffe0737410 : 0000006d4a7fefb8 0000006d4a7ff048 0000006d4a7feeb8 0000000000000001 : clr!CallDescrWorkerWithHandler0x4e 07 00007fffe08dcaf2 : 0000006d4a7fee00 0000000000000001 0000000000000001 0000017b2efcecf0 : clr!MethodDescCallSite::CallTargetWorker0x102 08 00007fffe08dd4b3 : 0000000000000001 0000000000000000 0000017b30ad2d30 0000017b30ad2d30 : clr!RunMain0x25f 09 00007fffe08dd367 : 0000017b2f040910 0000006d4a7ff420 0000017b2f040910 0000017b2f082770 : clr!Assembly::ExecuteMainMethod0xb7 0a 00007fffe08dccb3 : 0000000000000000 0000017b2ef00000 0000000000000000 0000000000000000 : clr!SystemDomain::ExecuteMainMethod0x643 0b 00007fffe08dcc31 : 0000017b2ef00000 00007fffe08de090 0000000000000000 0000000000000000 : clr!ExecuteEXE0x3f 0c 00007fffe08de0a4 : ffffffffffffffff 00007fffe08de090 0000000000000000 0000000000000000 : clr!_CorExeMainInternal0xb2 0d 00007fffe1208a61 : 0000000000000000 00007fff00000091 0000000000000000 0000006d4a7ff9f8 : clr!CorExeMain0x14 0e 00007fffe133a4cc : 0000000000000000 00007fffe08de090 0000000000000000 0000000000000000 : mscoreei!CorExeMain0x112 0f 00007ffff5cc4034 : 00007fffe1200000 0000000000000000 0000000000000000 0000000000000000 : MSCOREE!CorExeMain_Exported0x6c 10 00007ffff8033691 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : KERNEL32!BaseThreadInitThunk0x14 11 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart0x21其中第一行的00 00007fffe07a3181 : 00000000e0434352 0000006d4a7fe938 0000017b30ad2d48 0000017b2f081690 : KERNELBASE!RaiseException0x68中的第三个参数地址0000017b30ad2d48 就是我们的异常类打印出来看一下。0:000 !do 0000017b30ad2d48 Name: System.FormatException MethodTable: 00007fffde285c38 EEClass: 00007fffde3930e0 Size: 160(0xa0) bytes File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll Fields: MT Field Offset Type VT Attr Value Name 00007fffde2059c0 40002a2 8 System.String 0 instance 0000017b30ad4c80 _className 00007fffde282a50 40002a3 10 ...ection.MethodBase 0 instance 0000000000000000 _exceptionMethod 00007fffde2059c0 40002a4 18 System.String 0 instance 0000000000000000 _exceptionMethodString 00007fffde2059c0 40002a5 20 System.String 0 instance 0000017b30ad2de8 _message 00007fffde2883d8 40002a6 28 ...tions.IDictionary 0 instance 0000000000000000 _data 00007fffde205b70 40002a7 30 System.Exception 0 instance 0000000000000000 _innerException 00007fffde2059c0 40002a8 38 System.String 0 instance 0000000000000000 _helpURL 00007fffde205dd8 40002a9 40 System.Object 0 instance 0000017b30ad2e98 _stackTrace 00007fffde205dd8 40002aa 48 System.Object 0 instance 0000017b30ad2f28 _watsonBuckets 00007fffde2059c0 40002ab 50 System.String 0 instance 0000000000000000 _stackTraceString 00007fffde2059c0 40002ac 58 System.String 0 instance 0000000000000000 _remoteStackTraceString 00007fffde2085a0 40002ad 88 System.Int32 1 instance 0 _remoteStackIndex 00007fffde205dd8 40002ae 60 System.Object 0 instance 0000000000000000 _dynamicMethods 00007fffde2085a0 40002af 8c System.Int32 1 instance -2146233033 _HResult 00007fffde2059c0 40002b0 68 System.String 0 instance 0000000000000000 _source 00007fffde2831f8 40002b1 78 System.IntPtr 1 instance 0 _xptrs 00007fffde2085a0 40002b2 90 System.Int32 1 instance -532462766 _xcode 00007fffde21e720 40002b3 80 System.UIntPtr 1 instance 0 _ipForWatsonBuckets 00007fffde1f5080 40002b4 70 ...ializationManager 0 instance 0000017b30ad2e18 _safeSerializationManager 00007fffde205dd8 40002a1 100 System.Object 0 shared static s_EDILock Domain:Value 0000017b2efe0af0:NotInit 0:000 !do 0000017b30ad2e98 Name: System.SByte[] MethodTable: 00007fffde20dde8 EEClass: 00007fffde390920 Size: 120(0x78) bytes Array: Rank 1, Number of elements 96, Type SByte (Print Array) Content: .........../{...P.........Jm....Z.........................Jm....Y.............................. Fields: None此时_stackTrace已经有值了毕竟Console上已经打印出来了。最后补充一下大家也可以通过!threads去找异常的线程如下图的中System.FormatException 0000017b30ad2d48然后通过!printexception去打印这个地址0000017b30ad2d48上异常对象。0:000 !threads ThreadCount: 2 UnstartedThread: 0 BackgroundThread: 1 PendingThread: 0 DeadThread: 0 Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 0 1 80c 0000016816f508f0 2a020 Preemptive 0000016818CCE3B8:0000016818CCFFD0 0000016816ef0b10 0 MTA System.FormatException 0000017b30ad2d48 6 2 12d8 0000016816f7b0e0 2b220 Preemptive 0000000000000000:0000000000000000 0000016816ef0b10 0 MTA (Finalizer) 0:000 !printexception 0000017b30ad2d48 Exception object: 0000017b30ad2d48 Exception type: System.FormatException Message: 你的格式错误啦 InnerException: none StackTrace (generated): SP IP Function 0000001F8F7FEE90 00007FFF811E0951 ConsoleApp4!ConsoleApp4.Program.Run()0x71 0000001F8F7FEEE0 00007FFF811E08B9 ConsoleApp4!ConsoleApp4.Program.Main(System.String[])0x29 StackTraceString: none HResult: 80131537三总结