本文转载自微信公众号《跨界架构师》，作者Zachary。转载本文请联系跨界架构师公众号。大家好，我是Z哥，毫不夸张的说，程序员可能一半的时间都花在了bug上。虽然，根据28条原则，大多数bug都可以在搜索引擎上找到（业务bug除外），但往往剩下的20%的bug会占用我们80%的时间。虽然解决这个问题最好的办法就是减少bug的产生，但是要减少到0是不可能的，我们还是需要提高自己的调试效率。因为在调试方面，水平高的人在效率上可能至少领先一个数量级。我从事这个行业快9年了，这样的案例我见过太多了。还有一个在网络上传播率很高的案例。有一个问题，阿里巴巴内部团队排查了好几天都没有结果。之所以很多人的Debug能力长期停滞不前，在我看来，主要有两个原因。一是对IDE的功能了解不够，只会使用一直用到的基本功能。二是没有掌握合理的Debug思路，属于“幸运”玩家。不同的编程语言和主流的IDE是不一样的，所以我就第二点主要说说我的经验。一些有经验的程序员都知道，Debug过程中最重要的不是如何修复bug，而是如何找到bug发生的地方。所以，下面的思路主要是和排查bug相关的。缩小问题的范围有很多方法可以缩小问题的范围。本质上就是从当时的环境中找出与问题更相关的变量。最常见的变量主要有以下几个：运行环境数据运行浏览器对应的源代码版本建议您先从这些变量进行验证。然后弄清楚上次正常运行和当前有bug的运行之间发生了什么。在大多数情况下，问题的根源就隐藏在那里。毕竟，那种隐藏已久的难题是很少见的。细化优化各类bug的标准处理流程。工作中的很多流程都需要SOP。在修bug的事情上也可以做到这一点，这样每次修一个难bug的过程都可以搞定。常见的bug主要有四类：输出不符合预期程序错误程序响应明显程序崩溃慢每个类别都有适合他们的排查方法，如果你总是用同样的套路来排查这4类问题，效率会更高自然是低会太高。01输出不符合预期的bug最头疼，为什么呢？因为它不像那种异常报错的bug，它有堆栈信息，可以快速缩小排查范围，甚至可以直接定位到发生的地方。那我们该怎么办呢？如果问题出在测试环境，那么从单步调试入手是最简单的。这时候如果对IDE调试工具的了解更深，效率会更高，比如条件变量、多线程调试等等。这里多说一句，强烈建议大家掌握自己使用的IDE的条件变量和多线程调试这两种方法。在现在的环境下，整个软件开发领域的大型项目和多线程应用比几年前要多很多。许多。如果不能单步调试，只能通过多打日志来达到接近单步调试的效果。但这需要你做出一些预测，只要登录一些代码分支和可疑位置即可。毕竟写代码记录日志是需要时间的。02Programerror这种bug对于有一定经验的程序员来说是最容易出现的，因为它直接告诉你异常发生的代码位置。但是对于新手来说就不一样了。很多新手会拿一堆描述异常的词给搜索引擎，比如（NullPointerException），找到N篇以上。一本一本读完，尝试之后，发现自己的问题都解决不了，其实是因为不习惯看栈信息。因为别人的NullPointerException和你的NullPointerException的原因是不一样的。整个调用链记录在栈信息中，所以你可以在这里看到完整的方法调用顺序。不过值得提醒的是，在日常写代码的时候，千万不要随意尝试catch代码块，然后再抛出新的异常，因为这样会导致堆栈信息不完整。03程序响应明显慢。这种问题通常发生在资源竞争或资源短缺的情况下。检查它们也更加困难。如果说前两类问题中高级问题和低级问题的区别仅仅在于求解效率的高低，那么这个问题可能就是低级程序员无论花多少时间都找不到问题的原因花费。不过没关系，我建议大家以后遇到这种情况，还是先从以下几个指标入手吧。TCP连接数内存占用线程数对于TCP连接，你身边总得有一本netstat命令手册，然后敲命令查看连接数是否接近65535？TIME_WAIT和CLOSE_WAIT状态的连接是否过多？在大多数情况下，与TCP连接相关的问题主要有两个：使用连接后没有及时释放连接。对于高频调用，不使用长连接，而是使用短连接。这时候一旦下游服务响应变慢，就会很快填满65535个连接。内存问题的分析主要是通过分析GC来进行的，主要关注的是是否有什么类型的对象占用内存过多。如果太大，主要有以下两个原因：一个大对象应该共享使用，代码中不小心写了每个实例。在分配对象时，不小心加上了static关键字，导致GC无法回收为其分配的内存。不同的编程声音有不同的GC分析工具，需要掌握。对线程的分析，与TCP连接类似，主要关注线程的数量和状态。线程越多，性能越好。数字越高，线程之间上下文切换所花费的时间可能比实际执行代码逻辑所花费的时间越多。另外，是否有大量线程阻塞或死锁？随便挑一个线程，分析一下它当前的栈信息，就是问题所在。04程序崩溃崩溃的原因主要有两个。是因为上述原因3没有及时发现，导致程序一直运行到资源耗尽，在操作系统的干预下强行终止运行。代码中存在未捕获的异常。第一点是指原因3的处理方法，第二点很简单。在代码的最外层做一个大trycatch，然后把堆栈信息记录在日志里，发到网上。你自然可以看到问题在那里，然后去寻找原因。2处理方法。最后，提高Debug能力还需要多加练习。因此，强烈建议大家在条件允许的情况下，勇敢地挑起排查线上疑难杂症的任务，哪怕不是自己直接负责的功能模块。在外人看来你可能是在为别人“擦屁股”，但这会显着提高你的调试能力，而且很容易对你形成依赖，让你越来越强大。好的，总结一下。在这篇文章中，Z哥和大家分享了我对提高Debug效率的看法。要想提高Debugging的效率，首先要对IDE工具有一定的了解，知道一些高级的使用方法。二是要有自己的Debug思维方式。对于第二点，我建议的步骤是：缩小问题范围，细化和优化每一类bug的标准处理流程程序错误程序明显响应缓慢程序崩溃希望对你有所帮助。在我看来，Debug是一件非常有趣和有成就感的事情，不亚于设计一个项目框架。而Debug也能让你真正明白什么是“魔鬼藏在细节中”。
