“奇怪”问题解决思路整理

处理过各种各样的“奇怪”问题，当然一般的问题，也不会找我处理

虽然每个问题最终产生的原因有各种各样，但还是有些套路可以整理的

可以从以下几个方面入手：

 

准确描述问题现象，很重要。以下几个点可以捋一下：

   1. 现象能否重现？在什么条件可以出现？重现频率 分 极少出现，偶尔出现，频繁出现，100%出现

   2. 出现现象的环境：包括硬件，系统，外接设备，程序以及各种库的版本

   3. 跟操作步骤是否有关？

如果现象可以“重现”的，往往是比较好解决的。难度系数与解决率均跟“重现频率”有很大关系

因此，重点关心“重现频率”

 

 

其次，出现问题后，我们应该怎么办？

这个是技术活，一般人还做不了。

从第一段里，可以得出一些“猜测”，这样也可以缩小解决问题的范围

1. windows VS调试功能还是非常强大的，网上方法也很多

2.Linux，主要还是依赖GDB了，这个也非常强大

-----

注意：往往这些第三方是定位不到具体点，只是能够提供一种相对比较准确的位置。比如说，可以通过GDB查看，线程，线程如果一直在增加，也会导致问题。至少你可以看到哪个线程在不断创建。对，一般只能到这一步。

有了，这一步，再去分析“相关”代码，这样比较准确一些

 

经常遇到的现象：我们通过第三方跟踪过去，发现出现问题的地方是一个库（非开源）的某一个函数。。

此时也就不能很好定位问题了，但也有点思路了。至少，我们调用这些接口存在一定问题。

 

 

最后，万变不离其宗的还是代码。（前提是程序出现问题）

这个需要一定经验积累。

这里也会存在一点悖论：

1. 代码本身不存在问题，即无论老化单元测试，单元耐压测试都没有问题。但出现问题的确也是这个模块。

     比如说：我们发现第三方库存在问题，第三方库的开发者比如像微软这样的角色，你都没有办法。需要花费很大精力去“证明”

 

其实，有些问题，真的很难可以“证明”的。因为出现次数本来就不多

 

 

其实，很多事情，会出现扯皮的事情，往往最终会妥协，或不了了之

回过头看，宁可“自己的代码”有问题，也比“其他”模块有问题来得好解决。扯皮的事情，很伤神，很吃力不讨好的。