2019 秋招提早批蘑菇街一面面经(带答案)

今天给你们分享一下个人秋招提早批面试经历,目前三面技术面已过,hr 面也面过了,正在等消息。因为内容太多,先分享一面的面经。php

自我介绍一下吧

面试官您好,我是 xxx 大学软件工程的一名大三学生,从大一开始学习前端,产生了对编程的兴趣,大二开始接触 Java,大二下学期学了 ssm,springboot 等框架,也作了一些项目。后来发现基础很重要,因而从大三开始一直到如今,一直在对基础进行学习。好比:JVM,并发,操做系统,网络等。前端

看你的项目是分布式系统,那你的上游系统调用你的系统时可能会出现超时的问题,怎么处理

在咱们的系统的话,通常有监控平台,请求超时会抛出异常,会触发企业微信邮件告警,开发人员知道之后去看一下对应的日志中的异常信息。查到具体是调用哪一个接口出现的问题,这个接口里是否调用外部系统,定位问题是外部的仍是内部的问题。java

那若是你看到的日志就是不少请求,你认为这种是什么问题,在外部系统没有问题的状况下核心线程池被打满了

我以为多是有人新改了一个功能并上线,不当心写了死循环致使的 CPU 飘高。mysql

PS:review code 的重要性面试

您说的线程池爆满的缘由是可能一个接口中存在耗时的操做,致使请求这个接口的请求一直占用线程池,线程池被打满,从而致使后续来的其余接口的请求也会被影响。redis

这种状况通常能够服务降级、限流来处理。算法

在外部流量没有暴增的状况下,若是你的服务每隔半个小时会出现服务不可用的状况,这种怎么排查

它这个是忽然每隔半个小时仍是其余状况?spring

就是这一天 11 点出现了,之后每隔半小时就会有两分不可用,qps 都保持正常值

我猜这种状况通常出如今,定时任务同步一些数据到其余系统,因为网络的问题,那边服务慢的话就会致使一个超时,而后就会发生这个问题。sql

正常接受请求,也没有任务跑,你会往哪一个方面想

那它会不会受到部署机器其余服务的影响呢。数据库

没有

想了几分钟…..,这个目前还想不到其余的。

我能够给你个提示,往内存方面想

昂,立马 get 到点,是可能存在内存泄露吗?是否是因为存在内存泄露致使 full gc,gc 太频繁致使的。

对,那这种问题怎么排查解决

若是内存溢出的话,通常可能会有 OOM 抛出,JVM 能够设置参数在出现 OOM 时 dump 下内存的镜像,而后你能够利用一些分析工具,分析这个 dump 文件,有的工具直接能够给你一些优化建议,或者你能够找到哪一个类的内存使用状况,找到内存泄露的点,去看代码。通常是 NIO 引发的,由于 Java 8 开启方法区使用的是元空间,不是永久代了。元空间是本地内存,不是堆内存,不受 JVM 管理,由操做系统管理,因此使用不当可能会出现内存泄露的问题。

好,那下一个问题,你那边用的是 dubbo 把

是借鉴 dubbo 开发的一个 rpc 框架吧

正常 Java 用的是 dubbo,以前是 php,为了 php 和 java 微服务之间的跨语言调用,实现了一个跨语言的 rpc,如今已经所有转为 Java 了,都用 dubbo 调用。并且微服务架构方面又作了改进,使用了 Service Mesh,面向云原生。

dubbo 服务的启动、注册流程,说一下

首先,有个服务的提供者启动起来后,会先向服务注册中心注册服务,若是是 zk 的话,它就是在某个 dubbo 的目录下注册上下,其余消费者想调用的话,就从 zk 上把对应的提供者的 ip 地址啥的拉下来缓存起来。而后就能够调用了。

那提供服务的提供者 ip 更改了,消费者是如何动态感知服务提供者的改变呢

通常分布式注册服务能够动态感知。若是是 zk 的话,服务提供者在 zk 上注册服务时建立的是临时节点,若是服务 ip 更改了或者服务挂了,服务的调用者经过 zk 的 watch 机制能够监听到服务提供者目录下的节点增长、删除、修改事件。

你用到了不少队列,kafka、rabbitmq 了解吗

我如今这边用的是 nsq 和 kafka,kafka 通常是大数据那边离线处理一些东西,nsq 通常是告警信息,两个系统之间进行解耦,进行信息交互时,发消息到 nsq。区别的话,kafka 对大数据处理能力比较好,nsq 的话通常做为一个正常的消息队列,同步改异步就能够用 nsq。

既然 Kafka 能够处理大数据,那为何不用 kafka,而用 nsq 呢?

这个问题我以前想过,问过个人 leader。kafka 通常是大数据那边流处理什么的,它那边通常都只接受 kafka 的消息,和大数据集成比较好。至于选 nsq 的话,它是结合当时的业务场景选择的,这个也没有选哪一个好哪一个坏。

那他当时选型的时候,为何不用 kafka

由于 kafka 貌似对于延时消息等支持的不太好,事务这些,它虽然对大数据的处理的好,可是它也有缺漏的地方,它有它的专攻方向,好比:吞吐量方面,可是也有它的不足之处,就比如计算机中的摩尔定律。通常业务系统常须要一些延时消息就须要用 nsq 了。

根据个人项目问的一些问题

……

有数据库调优经验吗?对于数据库有多索引匹配时,有什么经验吗

这个匹配的话,好比:ABC 三个组合索引,必需要顺序执行,好比 A = 2,C =2 。这个时候就不会执行,由于它破坏了顺序性。

你说这种状况是彻底用不到吗

是的,由于它不知足索引的最左匹配原则。

那好比说,我数据库有多个索引,A,B,BC,一个查询条件 A,B,C 都有,那通常怎么查看呢

这个通常的话是用 explain 去分析一下 sql 的执行计划,它会输出可能走的索引,真正走的索引,扫描的行数,额外的消耗(extra),用没用临时表等。

那它分析出来的索引就是数据库必定会用的索引吗

explain 分析出来的吗

或者说,你以为它 explain 分析出来的就是最佳的索引吗

通常状况下最佳的,数据库会根据你的 sql,经过解析器生成对应的语法分析树,它对这个树进行一些规则的优化后,会生成一些查询计划,经过基于时间成本的分析算法选出一个尽量是最佳的查询计划。这个具体合不合适很难说。

你没有遇到建的索引很差,致使走的索引是最差的状况吗

这个通常的话,多是你对索引一无所知,致使一些索引的规则不去遵照,并且数据库索引的匹配规则不少,很容易走坑。若是你的业务必定要走你设置的那个索引,mysql 也能够经过设置强制走你设置的某个索引。

你对 Java8 了解吗

了解,由于我如今参与的项目就大量用了 Java8 的特性。好比:stream,lambda 表达式,时间 API 等。具体应用场景的话,好比你一个接口要返回 VO List 集合,而你数据库查出来的是 DO List 集合,这个时候你就能够用集合的 stream 去作这个转换。相比于传统的写法,代码会变的很简单和清爽。

流式编写代码的好处和坏处能够说一下嘛

好处的话,写代码的效率快了,看和很舒服。

坏处的话,流式性能不怎么好,并发状况不少的状况下才体现出好。

我以为最主要的是,以前你本身写的话,就面向过程化了。流式的话,Java8 提倡的是面向函数式编程嘛。编程模型以前最开始是面向过程,而后面向对象,面向元编程,面向切面编程,面向函数式编程,之后 java9 的面向模块化编程。并且把过程封装在函数中,经过函数去转换数据的状态对于线程安全方面也有很大的好处。

若是数据库对一些记录存在热点更新操做,有大量的更新,怎么解决呢

通常能够利用多级缓存去解决。若是数据量太猛增的话,你用 redis 客户端访问 redis 服务端都访问不到,由于带宽被打满了嘛。这种状况能够提早去探测某个 key 是否是热点,而后在本地缓存操做。

你怎么即时同步数据给其余人呢

它会有一个算法提早探测某个 key 是不是热点,而后框架会帮你进行本地缓存的管理。

数据库有单热点,那你怎么解决

这种通常先作一个缓存,而后能够用消息队列削峰填谷。

操做缓存可能会超时,你怎么保证这个数据的正确性呢?由于你加了缓存呀

对对,这个数据库和缓存保持一致性比较难保证。并且大量数据访问更新,也不能加锁,由于数据库经过行锁保证线程并发安全问题。

我要你解决的就是行锁等待致使的性能被拉低的问题,用缓存也是能够的,可是不能保证 100% 的数据一致性,那个人业务场景就是想要 100% 的数据一致性,你如今有大概的解决思路吗

这个能够用多套数据库主从集群来解决吗?经过这种方式来提高数据库的写性能。让多个集群去抗。数据库中间件能够把流量分散到各个主从集群中的主库上。

能够,这算是一种解决方案,那还有其余办法吗

你打破这个行锁就好了

…… 我再想一想。这个 ……

主要是单条记录引发的,它就是频繁更新引发的。

昂,这个是否是能够……… 我看 JDK 源码,频繁更新它通常是: HashMap 是非线程安全的,后来出现了线程安全版的 HashTable,可是它性能比较差,由于它直接就对整个 hash 表进行了加锁。后来出现了 CurrentHashMap,出现了分段锁,下降了锁的粒度,其实就是一种思想,你对一个热点数据的访问的话,就是分而治之,多去搞几个,均摊一下。难道是利用 hash 一致性算法把这些写请求,多分几张表。

差很少吧,思想就是分而治之,只要把单点数据拆分掉,让它变成多条数据,而后去更新多条数据,最后再合成一条。

嗯嗯。如今大数据通常也这样,大的搞不动就拆分。

从和你的对话来看,我以为你基础也不错,基础我就不问了,我这边没有什么问题了,我看你这边,实习经历丰富,offer 收的也挺多。你有什么想问的

贵公司的技术栈,还有若是我进去之后所在的产品线。

面试官讲述了他们公司的技术栈和一些业务

面试官对个人一些职业规划的建议

多锻炼本身的技术思惟 + 业务思惟,能够往业务中台方向走。更好的支持别人的业务,技术主要服务于技术,要培养业务架构思惟。

总结

我以为面试过程当中要避免本身一直在说,能够多和面试官去互动,去问面试官是否是这样子,这样能够避免你理解错面试官的问题。咱们的项目可能大部分是 CRUD,可是咱们的思惟不能够停留在 CRUD,多去结合业务,也就是结合场景去思考你项目,这多是一个很大的优点。毕竟技术是用于服务业务,去解决业务需求。

整理面经不易,花了我周末大部分的时间,若是以为写的好话,欢迎关注公众号、转发,大家的支持是我继续写后续面经的动力。

file

搜索微信公众号:Java知其因此然,可免费领取某课、Java 后端面经等资源,还有统一环境(教你怎么配置一套开发环境)视频领取。

相关文章
相关标签/搜索