面试中一个暴露能力等级的问题，从底层开始带你了解并发编程

举例一

描述：一次收到了服务器宕机的告警，从监控上可以看到机器出现故障当时有非常频繁的fullGC。于是进行了重启，发现没有解决问题。所以我们直接开始排查问题原因，从监控中可以看到一个接口请求量高于平时。通过撸代码发现这个接口里有个sql的where条件失效，每次调用都是全表扫描，所以把服务器打挂了。我们用了1个多小时，定位问题后进行了热修复。

连环问1：你们的业务量有多少？在开始排查原因之前，除了重启是否有其他的止血措施？回答：高峰时有几百QPS，出问题正好在低峰期，也就10QPS，所以也没有什么大影响。所以没做其他的止血措施。我算了一下，业务中断1个多小时，影响业务少数也有4W笔。如果不需要承担一些后果，我猜测：要不就是上层领导自己扛下了压力，没有穿透过来，要不就是这个服务不是核心业务。而回答者的止血措施前期准备不足，稳定性意识也不是特别高。属于中规中矩的开发人员。

连环问2：这个问题在测试阶段怎么没发现？

回答：测试用例没有覆盖到。问题的根因是接口的核心逻辑，还不属于边界或者少量场景，我猜测整个团队把关都不是很严，缺少牛人指导。

由于两个连环问的回答技术含量一般，我没有就这个问题继续追问。

举例二

描述：一次与外部进行对接，结果从对接方的服务器上调用接口获取不到数据，我们ping、telnet等命令发现都没有问题，没有办法就进行了抓包，看到数据联通性是好的，就想到可能是配置问题，最终查到配置了包大小的限制导致。我觉得他的回答没有问题，不是我的主要考察方向，我没有追问。从这个回答中，我觉得对他的linux基本命令的掌握达标了。

举例三

描述：做了一个配置中心，用户在使用的时候使用方式不当。公司里主流使用xx1和xx2两种编程语言，这两种语言所用的序列化器肯定是不同的。用户在配置序列化器的使用对整个业务线的所有应用进行了全局配置，把所有服务配置成同一个序列化器。这个地方我们做配置中心的承担少部分责任，主要责任还是用户。本质原因是他们的操作失误，我们还是进行优化，增加了审核环节。连环问1：除了审核，针对配置中心，是否还有其他的优化空间呢？

回答：这个地方我们其实有很完善的文档，用户没有按要求操作我们也很无奈。

这时候，我觉得我们遇到了价值观上的分歧。服务、担当、协同上我们的认知是有差异的，没有谁对谁错，只是有差异。为了避免争执我转移问题到其他不相关问题上。这里说说我自己对此问题的想法：

这里配置中心需要做保证服务健壮性为核心的优化：1>配置需要灰度生效，而不是一次性全局生效。2>针对业务线级别全局配置这种大范围低频配置，应该增加专家审核环节，由配置专家进行把关，确保符合用户预期。3>像涉及到业务线多个服务的配置修改，需要将配置更新下发给涉及的每个服务负责人进行确认，服务负责人确认后才能生效。

配置这件事情，我再多说两句，几个月前刚刚做过调查问题，采样范围不广，也不能说多客观。但是从业界近几年的大事故来看，确实非常值得重视：

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

读者福利

更多笔记分享

]

更多笔记分享

[外链图片转存中…(img-Xf2R0n4Q-1710438287147)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录