java后端debug排查问题思路

问题排查思路

这里说的是主要是debug以及线上问题排查的思路.

解决问题的步骤

确认环境、确定问题、复现问题、查看日志、定位问题 、解决问题

确认环境/url/参数

• 确认是哪个环境。

是开发环境，测试环境，还是生产环境。

如果问题是在测试环境，去开发环境看问题，不一定能复现。

如果采用了微服务架构，还要查看注册中心，服务是否生效，启用了哪一个实例。

• 哪个接口？哪些参数？哪个时间段？

确认url是否正确，参数有没有传错了。

确定问题

有时候测试/用户提出的问题，不一定是bug。

一定要跟需求做校对，确认是否与需求一致，是否因需求不合理导致的。

复现问题

问清楚测试/用户，问题是如何出现的，具体的操作步骤是什么，查看是否因为操作步骤不正确导致的。

在相同的环境，自己重新操作一遍，复现问题。

如果无法复现，问清楚出错的操作时间，直接查看日志。

如果无法确定逻辑，可以问产品，问测试。
如果无法确定是哪个接口，哪个字段，可以问前端。

查看日志

生产环境中，是没法进行debug的，所以日志非常重要。
开发中，一定要把重要的变量打印出来。
打印日志， 非常有利于解决问题。

• 链路追踪
  如果项目使用了微服务架构，最好有相应的链路追踪中间件，比如 SkyWalking。
  traceId，用于标识一次请求的ID。在同一个请求调用过的服务模块中，traceId都是相同的。
  可以通过traceId不断地追踪。

从上往下追踪，A服务调用B服务，先去A服务看下日志，找出 traceId，然后去B服务根据 traceId 继续追踪。

如果没有 SkyWalking, 也可以看下打印的日志有没有带上线程 id，可以根据线程id去跟踪。
在日志比较多的情况下，根据线程id找出请求相关的日志，方便定位问题。

• 异常错误
  如果是异常错误，直接查看error日志中在堆栈信息，找到出错在代码就可以了。

• 逻辑错误
  查看info/debug日志中的信息。
  如果关键的信息没有打印日志，那么补充日志后，重新发布到开发/测试环境中。
  在解决问题时，补充日志，重新发布环境，是非常有效的方法。 虽然土，但是有用。
  绝大部分逻辑问题，都可以通过打印日志解决。

• 复制数据到本地环境调试
  如果是在生产环境，可以把日志打印出来，如果是对象，可以打印成json字符串，本地环境再转换成对象。
  通过复制数据到本地环境，进行调试。

查询数据源

将查询或更新的sql或es等语句找出来，在对应的数据源中查询进行定位。

可以用下 MyBatis Log Free 插件： (免费)显示Mybatis的Sql。一下子把sql打印出来。
可以说是开发必须的插件了，遇到问题，马上打印sql，能快速定位问题。

定位问题

数据的流程一般是： 数据源产生数据—>加工数据—>目标变量获取数据

如果数据有问题，那么就要从这三方面分析，是在哪一步出错了。

是数据源的数据本来就不对，或者数据在加工过程中出错了，还是目标变量取错了数据，数据出错 ？

IDEA查看变量的调用链，可以参考以下文章：
https://www.cnblogs.com/expiator/p/10856482.html

解决问题

修改代码后，重新发布环境，查看问题是否已经解决。

结语

实际中遇到的问题，可能会更加复杂，还是需要多思考，多分析，多解决实际问题。

无他，唯手熟尔。