最网最全bug定位套路，遇见bug再也不慌了

前言

““不积跬步&＃xff0c;无以至千里&＃xff1b;不积小流&＃xff0c;无以成江海。”

想成为编程大佬也一样&＃xff0c;不经过海量的bug、各种复杂的系统问题的处理经验&＃xff0c;那么始终是纸上谈兵的小菜鸟。

那么如何做到遇到bug淡定自若&＃xff0c;达到“他强任他强,清风拂山岗,他横由他横,明月照大江”的大佬境界呢&＃xff1f;

本文结合自己多年的编程经验&＃xff0c;给大家总结了这份bug定位套路大全&＃xff0c;也许能对你有所帮助。

一、日志定位法

基本上大部分的bug异常问题&＃xff0c;只要能找到相关的异常日志&＃xff0c;那么就不用太慌了&＃xff0c;根据提示的异常类型和出现位置&＃xff0c;很容易就定位出异常原因。
可以说&＃xff0c;日志是日常工作中定位bug&＃xff0c;修复异常问题的首要依据。

有人可能说&＃xff0c;那要是没有异常提示呢&＃xff1f;
大部分情况下&＃xff0c;可能和日志的输出级别有关。很多时候适当的降低日志级别&＃xff0c;会输出更多程序运行的相关信息&＃xff0c;给我们的bug修复提供更多的依据。

但要注意&＃xff0c;生产环境上要控制好日志的输出级别&＃xff0c;如果日志级别过低&＃xff0c;可能会导致日志文件增长过快&＃xff0c;对服务器的磁盘IO和存储空间造成较大的压力。
在spring boot中我们可以利用actuator组件实现日志级别的动态调整。

二、断点调试法

在开发过程中&＃xff0c;遇到程序出现异常或执行效果不符的情况&＃xff0c;有时可能只是代码逻辑的一些问题&＃xff0c;并不会抛出异常&＃xff0c;也就没有了相关的日志输出。这种情况下&＃xff0c;最适合的就是在对应的方法打上断点&＃xff0c;开启debug模式启动项目&＃xff0c;逐步调试分析程序的执行步骤和数据变化的情况。

程序员老鸟都知道&＃xff0c;能断点调试的bug&＃xff0c;都不叫什么bug。

断点调试又分为2种情况&＃xff1a;
1、本地断点调试
2、远程断点调试

很明显&＃xff0c;本地断点调试是我们日常开发过程中用的最多的&＃xff0c;在idea中给程序打上断点&＃xff0c;然后通过debug模式启动项目&＃xff0c;调用对应的方法&＃xff0c;进入断点后通过F7和F8逐步调试。适用于本地开发环境。

而远程断点调试则是通过和远程运行的程序建立websocket连接来进行断点调试&＃xff0c;本地的项目不用启动。适用于测试环境和生产环境。

三、google、百度大法

程序员圈子里有很多有趣的鄙视链&＃xff0c;比如搞C的看不起搞java&＃xff0c;搞java的看不起搞php的。
这里也说一条&＃xff0c;用google的瞧不起用百度的。

但是我想说&＃xff0c;年轻人才做选择&＃xff0c;作为程序员老鸟&＃xff0c;我都用。一般来说&＃xff0c;百度更适合中国人的口味&＃xff0c;搜索出的内容量也会比较多&＃xff0c;但是过滤出高质量符合自己的场景的文章有时候比较费事。
google的话&＃xff0c;感觉搜索结果中的文章质量会高很多&＃xff0c;特别是针对国外的一些网站。

当遇到一个看不懂的异常时&＃xff0c;将那一大串不明觉厉的异常日志直接扔到google&＃xff0c;百度里&＃xff0c;立刻搜出来各种大牛的处理问题的相关博文&＃xff0c;这酸爽&＃xff0c;大家都懂的。

当然&＃xff0c;最关键的是搜索的关键字&＃xff0c;这取决于你对bug现象的描述&＃xff0c;越言简意赅搜索到的信息反而越多。

四、stackoverflow大法

如果你从事编程多年&＃xff0c;还不知道stackoverflow这个牛逼的网站&＃xff0c;我只能说你可能是个假程序员。
在这个网站里&＃xff0c;你基本上可以找到你开发过程中遇到的所有bug。

如果找不到&＃xff0c;你还可以在里面发起提问&＃xff0c;会有很多大神给你提供思路和答疑&＃xff0c;当然前提是你的英语还不错。

五、问题复现法

一般本地开发环境的异常问题都比较容易复现&＃xff0c;比较困难的是测试环境&＃xff0c;生产环境的异常问题。
比如网络问题导致的请求失败&＃xff0c;服务器配置问题导致请求被拒绝&＃xff0c;数据结构和数据记录不一致导致的异常&＃xff0c;GC异常&＃xff0c;偶然性或周期性出现的异常等等。

总的来说&＃xff0c;就是开发环境和测试、生产环境的环境不一致导致问题很难复现。

1、尽可能减少程序运行环境之间的差异
2 、扩大日志记录的时间&＃xff0c;记录多个异常周期内的日志
3、记录请求的入参出参
4、本地模拟环境重线异常问题

当你本地能复现问题后&＃xff0c;就可以随便整了&＃xff0c;可以采用各种手段尝试解决问题。成功后将解决方案照搬到生产环境就可以了。

六、排除法

很多异常很可能可以由多种原因引发&＃xff0c;这时候你就需要采用排除法&＃xff0c;针对每一个可能的原因去尝试。
还有的时候&＃xff0c;针对一些中间件&＃xff0c;组件参数的优化&＃xff0c;也可以采用排除法。

在你对异常情况没有情绪定位的时候&＃xff0c;可以采用排除法&＃xff0c;尽可能的缩小异常查找的范围&＃xff0c;进而定位问题。

七、同类比较法

这个也是我在开发过程中常用的一种异常定位办法。
典型的场景是&＃xff0c;明明是相同或者类似的一个功能模块&＃xff0c;A模块里面能正常运行&＃xff0c;B模块里面缺一直出现问题。
这时候比较笨的办法就是仔细比较2个模块里面这个功能实现有那些查询&＃xff0c;做一些对应的调整。

程序员不能光会Ctrl&＃43;C 和 Ctrl&＃43; V&＃xff0c;你可能需要更多的思考。

八、官方文档法

一般来说&＃xff0c;官方文档是一个技术或框架的最准确的说明文档&＃xff0c;是我们程序开发过程中最直接、最正确的首要依据。

很多时候在网上找的博客文章&＃xff0c;往往由于没有说明问题的上下文环境&＃xff0c;中间件或组件的版本不一致&＃xff0c;导致对自己的问题定位没有什么指导价值。

这时候&＃xff0c;通过官方文档你可以获取最正确的第一手资料&＃xff0c;是帮助我们定位异常的重要依据。

查看官方文档的时候&＃xff0c;一定要选择和自己项目中一致的版本号。

九、源码分析法

真正的大神&＃xff0c;定位问题的手段往往都朴实无华。

各种问题都能够直接怼源码&＃xff0c;通过手撕源码&＃xff0c;达到“他自狠来他自恶 我自一口真气足”的大神境界。

任你异常变化万千&＃xff0c;通过跟踪源码&＃xff0c;直指问题核心&＃xff0c;定位异常原因。

阅读源码这招威力虽然强大&＃xff0c;但是对使用者的“内功”会有较高的要求&＃xff0c;非3&＃xff0c;5年内功不可轻易修炼&＃xff0c;使用者需要量力而行。

十、大神求教法

开发过程中&＃xff0c;bug万千&＃xff0c;作为一个新入职场的小菜鸟&＃xff0c;阅历尚浅&＃xff0c;内功不够&＃xff0c;遇到bug后&＃xff0c;首先还是要自己多思多想&＃xff0c;尽力尝试分析原因&＃xff0c;独自解决问题。

每解决一个bug就是自己程序人生的一次成长的机会&＃xff0c;所以不要轻易放过。

当尝试无果后&＃xff0c;需要梳理好问题的上下文以及前因后果&＃xff0c;然后施展终极大招——大神求教法。这里的大神可以是团队里的老人&＃xff0c;可以是技术社区的大佬&＃xff0c;可以是技术群里的高人。

得到大佬指点后重新尝试&＃xff0c;解决问题后&＃xff0c;需要做好相关的异常解决笔记&＃xff0c;日积月累之下&＃xff0c;自然也成为了同事眼中的大神。

总结

本文主要给大家分享了自己工作多年的bug处理经验&＃xff0c;希望大家所有收获&＃xff0c;遇见bug再也不慌。