记一次线上问题排查:C#可选参数的坑

线上报了大量异常,错误信息为:找不到XX方法实现

代码调用关系是:

查看代码历史记录,发现最近上线前对 GetUserDottedLineSuperiors 方法做过修改,增加了一个可选参数。

跟相关开发同学确认后,是Hotfix的方式上线了UserService.dll,没有整版发布(而在测试环境验证的时候是整版发布)。

按说,改了哪里的代码,只需要更新该代码所在的dll即可,也就是只更新UserService.dll是没毛病的。

But,这样是不对的。

我们分别看一下DataRule.dll的源码和反编译后的代码:

代码(上图)还是保持着增加可选参数之前的样子,因为有可选参数的存在,编译一点问题都没有。

然而,反编译后(上图),发现编译器给加了一个可选参数的默认值。

说明虽然DataRule项目里的代码虽然没动,但是编译后的dll其实是跟之前不一样了。因此需要更新这个DataRule.dll。

由此也可以窥视一下C#的可选参数的实现方式,实际是在调用点加上了参数的默认值。

--------------------------------------------------------------------------------------------------------------------------------

其实一开始我也好奇,因为看IL,确实是给可选参数增加了[OPT]的标签,按说应该起作用

后面有时间再查一下MethodTable,我猜应该是MethodTable中此方法是3个参数,而且调用点应该也是去查MethodTable中三个参数对应的方法地址,因为调用的地方,IL是:

确实是要跳到三个参数对应的方法地址

原文地址:https://www.cnblogs.com/cc299/p/11520806.html

时间: 2024-10-10 02:30:09

记一次线上问题排查:C#可选参数的坑的相关文章

线上操作与线上问题排查实战

转自:https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960323&idx=1&sn=e04af14d2ebf939133869e0f18bb0dd1&chksm=bd2d01df8a5a88c98c3cb94a99334a16b372fd997f36bc757a38bb44b70d977797fa840064dc&mpshare=1&scene=23&srcid=0816Yl1Rl

线上问题排查

线上操作与线上问题排查实战 技术同学需要经常登录线上的服务器进行操作,58到家架构部/运维部/58速运技术部,联合进行了一次线上操作与线上问题排查实战演练,同学们反馈有收获,特将实战演练的问题和答案公布出来,希望对大家也有帮助. 一.了解机器连接数情况 问题:1.2.3.4的sshd的监听端口是22,如何统计1.2.3.4的sshd服务各种连接状态(TIME_WAIT/ CLOSE_WAIT/ ESTABLISHED)的连接数. 参考答案: netstat -n | grep 1.2.3.4:2

服务器线上问题排查研究

线上问题诸如: 1.线上服务器CPU占用率高如何排查? 2.线上服务器Load飙高如何排查?  3.线上服务器频繁发生Full GC如何排查?  4.线上服务器发生死锁如何排查? 一:线上服务器CPU占用率高如何排查? 问题发现: 在每次大促之前,我们的测试人员都会对网站进行压力测试,这个时候会查看服务的cpu.内存.load.rt.qps等指标. 在一次压测过程中,测试人员发现我们的某一个接口,在qps上升到500以后,CPU使用率急剧升高. CPU利用率,又称CPU使用率.顾名思义,CPU利

JVM 线上故障排查基本操作--CPU飙高

JVM 线上故障排查基本操作 CPU 飚高 线上 CPU 飚高问题大家应该都遇到过,那么如何定位问题呢? 思路:首先找到 CPU 飚高的那个 Java 进程,因为你的服务器会有多个 JVM 进程.然后找到那个进程中的 “问题线程”,最后根据线程堆栈信息找到问题代码.最后对代码进行排查. 如何操作呢? 通过 top 命令找到 CPU 消耗最高的进程,并记住进程 ID. 再次通过 top -Hp [进程 ID] 找到 CPU 消耗最高的线程 ID,并记住线程 ID. 通过 JDK 提供的 jstac

Java架构师线上问题排查,这些命令程序员一定用得到!

Java架构师线上问题排查,这些命令程序员一定用得到! 线上问题排查,以下场景,你遇到过吗? 一.了解机器连接数情况 问题:1.2.3.4的sshd的监听端口是22,如何统计1.2.3.4的sshd服务各种连接状态(TIME_WAIT/ CLOSE_WAIT/ ESTABLISHED)的连接数. 常见方法: · netstat -n | grep 1.2.3.4:22 | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' · nets

Java 开发必须掌握的线上问题排查命令

作为一个合格的开发人员,不仅要能写得一手还代码,还有一项很重要的技能就是排查问题.这里提到的排查问题不仅仅是在coding的过程中debug等,还包括的就是线上问题的排查.由于在生产环境中,一般没办法debug(其实有些问题,debug也白扯...),所以我们需要借助一些常用命令来查看运行时的具体情况,这些运行时信息包括但不限于运行日志.异常堆栈.堆使用情况.GC情况.JVM参数情况.线程情况等. 给一个系统定位问题的时候,知识.经验是关键,数据是依据,工具是运用知识处理数据的手段.为了便于我们

系统上线那点事 - 记一次线上系统故障

该项目是一个微信转盘游戏抽奖营销项目.因为运营营销时间要求紧迫.开发測试部署上线用了10天不到,有些准备工作并没有到位,如: 1.因为总体开发在上线前2天才完毕,測试了解这个项目需求是在开发的第二周,并没有充足的时间进行完好的功能,UI机型适配,系统压力測试. 2.技术上因为合作方的公众号密钥并不适合直接给出,所以由对方封装微信接口获取所需功能,对方封装的微信接口给出比較迟,在预定開始时间前三天: 微信的网页接口授权回调域名仅仅有一个.这个回调域名还有其它应用在使用,不能直接简单的改为我们部署应

JVM 线上故障排查基本操作

# 前言 对于后端程序员,特别是 Java 程序员来讲,排查线上问题是不可避免的.各种 CPU 飚高,内存溢出,频繁 GC 等等,这些都是令人头疼的问题.楼主同样也遇到过这些问题,那么,遇到这些问题该如何解决呢? 首先,出现问题,肯定要先定位问题所在,然后分析问题原因,再然后解决问题,最后进行总结,防止下次再次出现. 今天的文章,就如我们的题目一样,讲的是基本操作,也就是一些排查线上问题的基本方法.为什么这么说呢?因为线上问题千奇百怪,就算是身经百战的专家也会遇到棘手的问题,因此不可能在一篇文章

Java开发必须掌握的线上问题排查命令

作为一个合格的开发人员,不仅要能写得一手还代码,还有一项很重要的技能就是排查问题.这里提到的排查问题不仅仅是在coding的过程中debug等,还包括的就是线上问题的排查.由于在生产环境中,一般没办法debug(其实有些问题,debug也白扯...),所以我们需要借助一些常用命令来查看运行时的具体情况,这些运行时信息包括但不限于运行日志.异常堆栈.堆使用情况.GC情况.JVM参数情况.线程情况等. 给一个系统定位问题的时候,知识.经验是关键,数据是依据,工具是运用知识处理数据的手段.为了便于我们