以下是一枚在努力学习ing的编程小菜的程序员的真情求助：有的时候，遇到Bug百思不得其解，头大……有的时候，一直改……一直改，结果越改越乱……
· · ·对于许多的猿媛来说，你所经历的大部分Bug应该已经被别人修复并且分享出来了，所以这时候你可以好好利用下百度、Google、Stackoverflow等这些工具，他们应该会在第一时间帮到你。
但有时候猿媛们也一定会遇到些疑难的Bug，可能好几天都不得其解，搞得人焦头烂额，这时候就不要左改一下，右改一下胡乱试验了，而要冷静下来，理理头绪再动手。
以下是一位自称已奔四的老码农关于怎么样才能提高修改Bug的效率给出的一些建议：方法一：“换”术1. 换个环境试试2. 换个用户试试
3. 换个操作方式试试
4. 换一下数据试试
5. 换个浏览器试试
6. 换个版本试试
7. 换个人操作试试
方法二：搞清楚以下问题1.这个BUG什么情况下出现？什么情况下不出现？两种情况的区别在哪里？2. 这个BUG之前没有，现在出现了，中间都动了什么？
3. 这个BUG生产环境出现测试环境不出现，两个环境区别是什么？
4. 同样的功能，这样操作没有BUG，那样有BUG，两个操作的区别是什么？
这些问题搞清楚了，可以采用代码回退、修改配置、环境替换等方式验证BUG是否会消失，然后再找其中的原因。
Bug之常见“疑难杂症”及“治疗”方法：<<<1. 输出结果与预期不符，这种Bug一般都是由于代码逻辑错误造成的，如果能在开发环境重现，最好解决方法就是单步调试，设定每一步代码的预期结果，然后跟踪判断实际结果是否与预期结果一致，不一致的分析原因，如果在开发环境无法重现，无法单步调试的，可以采用添加输出日志的方式判断哪一步的问题。>>>2. 系统异常报错，这种情况下需要提取日志，找出错误堆栈信息，这时候最重要的事情是要把堆栈信息看懂、看完整。这是很多经验不足的程序员常见的问题，就知道报错了，报的什么错，这个错代表什么一概不知。而且往往堆栈信息是一个套一个输出的，比如Java里面表象上看是一个NullPointer Exception，但是如果你看到底，就会告诉你到底是什么错误引发了这个NullPointer。<<<3. 系统Crash，这个问题常见的原因是负载过高、并发过高、或者配置错误。最常见的就是内存溢出。这时候要首先排除配置错误的原因，主要靠查看Crash Log来分析原因，如果Crash Log没有有用的信息，就得排查硬件、内存、网络等方面的设置，看是否有配置错误的地方。再找不到就在测试环境用开发模式进行压测和调试。>>>4. 系统响应缓慢，这种问题一般是存在资源竞争或者系统资源不足的情况，举一个Java应用的例子来说，如果某些功能出现系统响应慢，处理步骤如下：查询TCP链接数是否超出系统可承受范围，命令：netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n ， 主要查看ESTABLISHED、TIME_WAIT、CLOSE_WAIT这几个数量是否异常过大。查询Java线程数是否正常，命令：ps -eLf | grep java -c查看和分析gc情况，命令：jstat -gcutil 76691 1000 5用jstack查看Java线程状态，命令 jstack pid >> xxxxx.txt，然后从这个文件里面分析java线程中各种状态线程的数量，命令：grep java.lang.Thread.State xxxxx.txt | awk '{print $2$3$4$5}' | sort | uniq -c ， 如果有非常多的blocked和deadlocked状态的线程，这个地方就是问题所在了。通过这些步骤，找出那些功能、那个方法、那段代码存在瓶颈和资源竞争，针对性的对这个地方进行改造就行了。
本文部分内容选自知乎作者：Jim Jin，已获作者授权，著作权归作者所有，转载请联系作者获得授权。链接：https://www.zhihu.com/question/36438025/answer/111992158
最后，如果某个地方出现BUG实在找不出什么原因，脑汁已干，计谋已尽，那就试试这位奔四码农大叔的绝招吧！小黄鸭调试方法 （Rubber Duck Debugging）1. 去买一只小黄鸭，就下面这样的，注意个头不要太大。
2. 把小黄鸭放到电脑屏幕前，就下面这样，最好面对你。
3. 打开你出问题的那段代码，面对着小黄鸭，用手指着代码，认真的一行一行的给它解释一下这行代码是干什么的，为什么这么写。
4. 然后……你现在知道问题在哪了吧！（小编认真脸）
当然，如果你不喜欢小黄鸭，也可以自行选择自己喜欢的对象，例如下边这位机智的程序猿（亮点请自己找）。
向女神姐姐倾诉
向卡哇伊小萝莉倾诉· · ·程序员是项很苦逼的职业，一个人很寂寞，有其他人呢又会觉得烦，因此也就应运产生了所谓的“小黄鸭调试法（Rubber duck debugging）”，就是在调试/纠错/测试过程中，耐心地向小黄鸭解释每一行程序的作用，以此来等待灵感的降临。