一道一线大厂面试题引发的思考

晚上10点，你拖着疲惫的身子准备打卡下班，突然钉钉群报警，你负责的项目线上出问题了，你心理一慌，什么鬼？

出现bug?不会啊，白天不是用的好好的，咋这个点就出问题了，此刻心理虽不爽，但还是马上掏出你的本本坐下继续解决起问题来........,费了九牛二虎之力，总算解决这个问题，现在已是晚上凌晨2点，打车穿过夜色中的长安大街，走在回家的路上。不知以上场景是否在你的身上或者身边发生过。

本篇的内容一方面来自于自己日常工作的真实写照，另一方面是之前有看到网上有人贴出去BAT等一线大厂面试的时候，有面试官问起，你是如何解决线上问题的呢？如何优化系统的性能呢？一般你处理的思路是什么呢？当时这位同学回答的不是很好，所以我的这篇文章就孕育产生了。线上出现一个性能问题或者排查了代码日志后任然找不到问题出在哪里的可以按一下思路尝试：

第一、大的思路通过以下两个方面来排查：

1.1. 系统层面

系统层面的分析主要是定位问题出现可能方面，是IO瓶颈？还是CPU瓶颈？还是内存瓶颈？

1.2.代码层面

代码层面的优化，建议采用以下准则：

1.2.1. 二八法则：在任何事物中，最重要的只占其中的20%，其余80%虽是数量上的占绝大多数，但是次要的。我相信你也听说过世界上80%的财富是掌握在20%的人手里的.so,在优化的过程中，我们要集中精力优化那20%最影响性能的或者容易出现bug或者性能阻塞的代码上。这个应该很好理解，我举个例子，比如有两层for循环第一层循环100 第二层循环10次，还有就是第一层循环10次，第二层循环100次，在同等外部因素条件下谁的执行效率会更高一些呢？（这个问题留给你思考），同样相似的原理也存在于数据库查询中，什么小表带动大表，大表带动小表，所谓这些总结出的这些口诀，初看哇好厉害，但仔细思考过后其背后的原理很简单。

1.2.2.编完代码，再优化：编码的时候总想着考虑最佳性能，未必是好事，这样极有可能损失代码的可读性和开发的效率

第二、系统层面排查

2.1. 使用top 命令 查看我们关注的点：

2.2. 分析内存瓶颈

通过上面的命令查看后若存在内存瓶颈，我们可以切换free命令更加直观的查看内存情况：

2.3.分析IO瓶颈

若IO存在性能上的瓶颈，top 工具中的%wa 就会偏高

进一步可以使用iostat来分析

• 如果%iowait的值过高，表示硬盘存在I/O瓶颈。
• 如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
• 如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；
• 如果 await 远大于 svctm，说明I/O 队列太长，io响应太慢，则需要进行必要优化。
• 如果avgqu-sz比较大，也表示有大量io在等待。

2.4.分析CPU瓶颈

若CPU存在性能上的瓶颈，top 工具中的%id就会偏低

通过排序我们是可以看到那个进程占用CPU比较高

通过top工具发现系统性能问题是由某个进程导致的之后，接下来我们就需要分析这个进程；继续 查询问题在哪；

分析进程的工具主要有：pstack和pstrace

pstack用来跟踪进程栈，这个命令在排查进程问题时非常有用，比如我们发现一个服务一直处于work状态（如假死状态，好似死循环），

使用这个命令就能轻松定位问题所在；可以在一段时间内，多执行几次pstack，若发现代码栈总是停在同一个位置，那个位置就需要重点关注，很可能就是出问题的地方；

而pstrace用来跟踪进程中的系统调用；这个工具能够动态的跟踪进程执行时的系统调用和所接收的信号。是一个非常有效的检测、指导和调试工具。系统管理员可以通过该命令容易地解决程序问题。

通过以上几个维度的分析基本就可以解决问题，本文提供的只是解决线上问题的方法论，具体的问题还需结合具体的生产场景进行具体分析，在笔者看来若你能掌握以上这些工具和思想方法，在处理线上突发问题的时候不输于一名中高级开发工程师（谦虚的讲），当然应对面试那也就小菜一碟了。