排查bug的通用思路

在这里插入图片描述
⭐️前言⭐️

APP点击某个按钮没有反应/PC端执行某个操作后，响应较慢，通用的问题排查方法:

从多个角度来排查问题

🍉欢迎点赞 👍 收藏 ⭐留言评论

🍉博主将持续更新学习记录收获，友友们有任何问题可以在评论区留言

🍉博客中涉及源码及博主日常练习代码均已上传GitHub

请添加图片描述

🍅综合排查流程

网络请求和响应的检查

分离端复现问题

前端单独测试：可以在浏览器中将开发者工具的网络连接调为“离线模式”来测试前端逻辑。模拟前端点击操作，查看是否存在接口调用。如果前端逻辑应该在无网络时拦截，但未拦截，说明前端存在问题。
后端单独测试：通过工具（比如postman）模拟前端发起API请求，查看后端接口的响应是否符合预期。确保后端在接受到正确的请求时，返回符合业务逻辑的响应

分析慢点

定位慢点：可以通过浏览器控制台抓请求或者记录时间戳的方式，分析延迟主要出现在前端、网络还是后端
- 可以在前端和后端的关键节点记录时间错，通过时间戳的对比定位慢点
分段日志埋点：在后端的关键逻辑处添加日志记录耗时（比如业务处理开始、结束，数据库查询开始、结束）
- 使用System.currentTimeMillis()记录时间差，快速找到耗时长的部分

分阶段排查

协同调试

1.请求问题：

2.静态资源问题：

业务逻辑复杂：
- 业务代码中嵌套调用过多、逻辑判断繁琐，导致请求处理耗时。
- 不必要的循环或递归操作，特别是处理大规模数据时未优化算法。
代码优化不足：
- 代码中存在未优化的阻塞操作（如线程等待、同步锁竞争）。
- 不合理的数据结构选择（如线性搜索代替哈希表）。
第三方接口调用慢：
- 调用外部服务（如支付接口、第三方API）时出现网络延迟或接口响应慢。
- 第三方服务限流或超时未处理，导致阻塞。
异常处理问题：
- 异常处理逻辑不完善，导致未捕获异常不断重试或抛出。
缓存问题：
- 缓存未命中：
  - 请求频率高但未利用缓存优化
  - 热数据未加载到缓存，直接从数据库读取数据
- 缓存击穿、雪崩或穿透：
  - 高并发时，缓存过期或被大量无效请求穿透
  - 缓存层压力过大，导致失效或阻塞
- 缓存更新策略问题：
  - 缓存未及时更新，导致大量请求命中无效数据并触发数据库查询
队列与任务调度问题：
- 消息队列积压：
  - 消息队列（如RabbitMQ、Kafka）中消费速度低于生产速度，导致请求延迟
  - 消费者线程数量不足或处理能力有限
- 任务调度延迟：
  - 定时任务频繁触发，导致线程资源耗尽
  - 分布式任务调度系统负载不均或出现故障