场景1

场景2

场景3

1 从发现和分析问题方面准备。

2 从linux命令和日志层面分析问题的步骤。

1 事先准备很重要

2 面试开始是自我介绍，这时要表露出，自己解决过redis,dubbo等组件的线上问题

3 一旦开始说第一个组件层面解决过的问题时，先说如何发现

4 说解决问题时，业务可以一笔带过

5 说好一个组件方面的问题后别停

作为Java面试官，我发现有三个值得注意的观点。首先，很多程序员认为“高水平”就是熟练掌握业务知识并能解决单机版问题，但在面试官眼里，这只是基本的增删改查操作而已。

其次，真正掌握高并发、微服务和云技术等价值技能的程序员，却不一定懂得如何在面试中展示自己的专业能力，或者在面试官主导的面试中得到展示的机会很少。最后，在面试中，“说”比“做”更重要，因此程序员需要准备好展示自己的技能，并掌握如何在面试中凸显自己的优点。即使技能不够强，也可以依靠出色的面试表现获得更高级别的职位。例如，有些培训班学员就是通过出色的面试表现成功入职的。

在我作为Java面试官的经验中，遇到了很多这样的案例，从中可以深刻感受到，技术能力并不是面试成功的关键，更关键的是如何在面试中展现你的专业素养。

场景1

我曾经遇到一位求职者，他的简历上写着拥有5年Java开发经验，但在面试中却过于强调项目业务。我不得不引导式地提问，询问其项目的亮点，并希望了解redis在其中的运用情况。然而，他又开始大谈复杂的业务，告诉我为了确认这个业务和客户沟通了整整2天。最后，当我再次尝试询问redis的使用时，他才透露出该项目在获取数据时利用了redis来提高性能。

对于这样的求职者，我感到非常不满意。虽然他的简历显示他有5年Java开发经验，但是在面试中过多地谈论业务细节，却不能准确回答关键问题，给人留下了浮躁、不专业的印象。作为面试官，我更看重应聘者的技术实力和专业素养，因此，我建议所有求职者在应聘前多准备一些相关问题的回答，并且在面试中注重突出自己的技术实力。

场景2

曾经遇到一位求职者在简历中声称熟悉微服务组件dubbo和netty等技术，但在面试时却不知道如何准备。我问他项目中具体使用了哪些这些技术，结果他给我讲了一大堆dubbo和netty的底层细节，比如netty线程模型等。然后当我再进一步确认他是否真正实践过这些技术时，他告诉我只是用过API，或者只实现过一些很简单的技能。

这样的情况在面试中并不罕见。有些求职者为了在简历中突出自己的专业特长，会写入各种技术关键词，但实际上并没有真正掌握这些技术。作为面试官，我更看重求职者的实际能力和经验，而不是简单的技术名词。因此，我建议所有求职者在准备面试前，应该对自己所写的技术进行深入了解，并在实践中获得相关经验。只有这样，才能够在面试中表现出真正的专业素养。

场景3

有些具备3到5年大厂经验的Java开发者，很可能用过分布式等高级技术。然而，当被问及对Redis等组件的使用和解决性能问题时，他们通常只是零散地说一些细节，没有条理性。这其实是一个反例，因为有些求职者在面试中表现出色，能够结合业务细节谈论分布式和微服务，同时也能讲述自己如何解决实际问题。但是，进入项目组后却只展示了基础的增删改查技能，表现并不尽如人意。但是这并不意味着这些求职者无法进步。相反，只要拥有实践机会，他们就可以逐渐提升技能水平和薪资待遇。所以，在准备面试时，需要认真准备，不能仅仅结合项目和理论层面做准备。否则，即使是应聘基本技能的岗位，如果面成了，那么薪资也可能会被低估，或者错失进入大公司的机会。所以，如果想要挑战高级技能的岗位，准备充分非常重要。

1 从发现和分析问题方面准备。

在我的项目中，我们使用了Zabbix或CAT来监控我们的项目。只要有挂机、数据库和Redis慢查询等情况发生，就会触发告警。

此外，如果日志中出现关键字exception过于频繁也会告警。同时，如果机器CPU或内存使用率过高也会触发告警。如果您想更深入地了解这个话题，可以去了解一下Zabbix等监控组件的具体配置细节，比如配置哪些参数可以监控数据库慢查询。当您准备充分后，您就能证明自己曾经配置过全局性架构的参数。此外，您还可以介绍一些自己曾经解决过的各种问题，并结合实际问题来证明自己的能力。

例如，我们的项目使用Zabbix进行监控，我通过配置某些参数（提前在网上查过），成功监控了数据库慢查询。一旦有超过5秒的SQL语句，就会触发告警；同时，我还配置了当内存使用率高于80%且持续时间超过5分钟时，会触发告警；此外，如果在5分钟内日志中出现100个以上的异常关键字，也会触发告警。这样，您至少能证明自己具备排查问题的能力。

2 从linux命令和日志层面分析问题的步骤。

继续，你可以说，当我发现业务问题后，首先会到Linux里使用vi命令打开日志，然后根据关键字搜索，在找到对应的时间节点后，再根据traceid或线程号找到错误日志的上下文。

这是分析业务问题的一般过程。如果我解决了空指针等问题，可以直接说明。如果是解决数据库慢查询问题，通常的做法是使用执行计划进行分析，查看关联表的数量是否太多，是否缺少索引或缓存，并详细讲解索引和Redis的用法。

对于CPU或内存OOM问题，一般的做法是使用Linux命令排序，查看哪些线程的CPU或内存使用率过高，必要时使用jstack或jmap命令进行分析。此外，还可以参考其他人的排查经验，例如一次排查内存问题的经验，其中原因是由于使用对象未关闭。结合自己的业务场景，例如支付项目中未关闭连接网银的对象导致OOM，可以更好地证明自己的技术能力。

以上是针对单机版的问题排查和解决方法。而通过“解决过的线上问题”，可以更好地证明自己对Redis等组件的掌握程度。例如，如果我没有在自己的项目中使用Redis，我可以先了解Redis的语法，例如基本数据结构有5种，可以使用jedis和redisTemplate操作Redis。然后，我可以想出自己项目中的业务场景，例如支付项目中使用Redis缓存常用的风控规则。最后，我可以到线上找别人解决过的问题，例如在某篇文章中，通过修改配置文件解决了某个问题。结合我的业务场景，我可以按照讲解过程进行分析，并提出相应的解决方法，以证明自己实际上已经解决了线上问题。

除了Dubbo以外，对于其他的组件，例如Kafka和Nacos等，我也可以参考其他人的排查经验，并到线上寻找解决过的问题。分布式组件层面，不仅需要看底层源码，还需要结合业务场景进行分析。在向面试官展示自己的技术能力时，无需一定要结合高并发场景说明，可以使用自己的业务场景来进行讲解，然后结合排查问题的思路，必要时再引入源码。即使我没有亲自使用过这些组件，哪怕我只是在小公司中从事增删改查工作，我也可以通过这种方式证明自己具有架构经验。

至于这里，dubbo问题，redis问题你是怎么发现的？

上文也说了，你项目引入了zabbix监控，监控发现了慢连接慢查询，然后看日志分析。

上文说了可以准备的点，这里再说下哪些点看似值钱，但面试时你其实是没法用的。

你掌握的技能只有融入了业务，才能证明你的实力，比如上文提到了解决慢查询解决分布式组件方面的问题，都是要融入业务。比如有些点，在项目里其实用不到，比如分布式锁，java并发锁这套，还有spring boot方面的源码，项目里要么不会直接用，即使要用也是用组件，而不会自己手写一套分布式锁。

这里比如大家没在项目里用过值钱技术，千万别自己想象一下业务中的使用场景，这样反而会坏事，比如某人认为redis+lua实现的分布式锁很值钱，然后自己想个业务场景，但真实项目里不大会用分布式锁，这样就穿帮了。

这种情况下，大家切记，是通过组件实现（缓存或消息发送等）功能，别手写代码，因为零基础说手写代码大概率会穿帮，用组件实现，看些api，再对应准备些解决过的问题就可以了。

这点衍生一下，你看过的技能，包括底层源码，如果不是组件，而且项目里用不到，你准备再多，只能证明理论方面的技能，其实只是聊胜于无。

最后给出一些高水平程序员（或者是冒充的高水平程序员）过面试的一些套路。