程序员进阶之排错和避坑方法论

知名电商高级 Java 工程师,CSDN 博客专家,前网易 Java 高级开发工程师,博客阅读量过百万,有数篇博客被知名技术类公众号转载。《解锁大厂思维:剖析《阿里巴巴 Java 开发手册》》专栏作者,5000多人订阅。 擅长方法论,喜欢总结和分享。 个人博客:https://blog.csdn.net/w605283073 微信:mingmingruyuexz (请注明来自GitChat)

文章正文

1. 前言

程序员的职业生涯中会遇到无数个 BUG .

面对同一个问题,不同人解决的速度体现着个人的技术水平。一分钟就可以定位问题的程序员和一个小时还毫无头绪的程序员注定拥有不一样的发展轨迹。

定位问题是解决问题的前提,如何尽可能避免出现 BUG 也是一门学问然而,现在很少有系统化介绍这一块内容的高质量文章。

为了弥补这一块空缺,计划将自己在工作中积累的一些经验通过本 Chat 系统化输出给大家,让大家在遇到问题时有清晰的思路,可以快速定位问题,提高技术水平;让大家了解如何尽量避免出现 BUG,少走弯路,提高进阶的速度。

在本 Chat 将重点围绕以下方面展开:

  • 为什么有些人可以 1 分钟定位问题,而有些人却搞了 1 小时还毫无头绪

  • 掌握排查错误的核心思路和方法

  • 如何尽量避免出现 BUG

2. 定位问题快与慢

不知道大家有没有认真想过,为啥有些人可以 1 分钟定位问题,而有些人却搞了 1 小时还毫无头绪?

难道是有些人运气好,有的人运气差?

在我看来,定位问题快慢的主要原因有:

  • 基础是否扎实
  • 是否有系统化靠谱的排错方法
  • 是否了解过或者遇到过常见的坑

2.1 基础是否扎实

很多同学基础不扎实,遇到问题像无头苍蝇一样毫无头绪,更多地是请教别人或者直接去搜索引擎里搜答案,反复尝试。

举一个真实的场景:如下图所示,为了提高性能,在事务方法中生成业务对象集合将其批量插入到 MySQL 某个业务表,然后将每一个元素分别通过消息队列发出去,分发到多个机器上查询出来做后续处理。结果可能数据量少的时候功能正常,数据量大的时候有些子任务就没有处理。

上架流程

如果你基础非常扎实,很快就可以猜到很可能事务还没提交就发送了消息,导致查询时查不到数据,因此消息要在事务提交之后再发送;

还有可能是数据库采用主从复制、读写分离的模式,读时读了从库,由于主从延迟导致未读到数据,此时可以强制读主库。

读写分离

越是疑难杂症,越是需要扎实的计算机基础,才能把握好大方向,逐渐快速缩小范围,进而定位到问题所在,并分析出原因。

2.2 是否有靠谱的排错方法

巩固基础不是一朝一夕的事情,同样的专业基础前提下,还是有人相对来说可以更快定位问题,另外一拨人则很可能还是靠瞎猜或第一时间就是直接搜索引擎搜索。

比如某个接口有性能问题,有些同学要新写一个测试接口或者加上切面代码,通过日志去打印要排错接口的耗时,显然效率很低,如果了解 arthas ,直接 trace 命令,无需编码可以快速定位到耗时最长的子函数,辅助你推断出最可能的原因。

2.3 是否了解过或者遇到过常见的坑

俗话说:“熟读唐诗三百首,不会作诗也会吟”。

比如你熟读《阿里巴巴 Java 开发手册》,那么你就知道三目运算自动拆箱可能会导致空指针,那么当你看到错误日志在三目运算这一行时,你就可以很快想到可能是自动拆箱导致的。

比如你遇到过或者看过 @Transcational 失效的文章,那么遇到失效的场景时你就可以分析可能的原因,比如常见的原因有:

  • 写到了非 public 方法上
  • propagation 设置错误
  • rollbackFor 设置错误
  • 自调用问题
  • try-catch 吃掉了异常
  • 数据库引擎不支持事务

类似的问题还有很多,希望大家可以通过前面给的几个简单的例子能够 Get 到排错快慢的原因。

2.4 其他因素

作者正在撰写中...
隐藏内容 支付可见
内容互动
写评论
加载更多
评论文章
¥6.66 购买
× 订阅 Java 精选频道
¥ 元/月
订阅即可免费阅读所有精选内容