前言（也就是废话）在欢聚时代有四年多的经验。今年年底，嗯，不对，应该是去年。开始了一个多月的面试之旅。受访企业不多，但从体量上看，基本包括了BAT在内的所有一二三线厂商。当然最后还是很顺利的拿到了offer。虽然不是很理想，但我也很满意。毕竟对于我这种一直向往大厂的人来说，能够进入大厂已经是很好的职业转型了。在这个过程中，也积累了很多面试经验，也和很多朋友交流。很多人让我写一篇文章分享我的经验（只是其中的一小部分）。至于我，除了其他优点，很少会拒绝朋友们的好意。既然都这么急着问，那我也不负众望，放弃一天的假期写一篇实战经验分享下来。个人背景还好，废话不多说，先介绍一下个人背景。我是2017年毕业的，去年年底，我有大约四年半的工作经验。我当时面试的第一家公司是广州的。YY直播的前身欢聚时代集团也面试了字节跳动、Lazada、腾讯、网易等公司，最终拿到了欢聚和网易的offer。结果不尽如人意，可怎么说呢？下来之后感觉大厂的面试难度并没有想象中那么夸张。其中，我在字节和Lazada的技术端被刷过。我问过被推荐的朋友，可能不是技术原因。当然，这是后话了。我想说的是，即使是面试大公司，只要准备充分，还是可以从容应对的。每次面试结束后，我都有问题的记录和回顾。由于篇幅原因，本文只分享欢聚的面试经历，其他公司的面试经历我会在后面整理。HappyGatheringTimes第一面（1h），先自我介绍一下。固定链接面试官：既然你用的是Java语言，那么先说说Java的基础吧。Java有什么样的锁？Java包含的锁按照机制可以分为公平锁和非公平锁，乐观锁和悲观锁，独占锁和共享锁，还有什么是无锁，偏向锁，轻量级锁，重量级锁等等，比如作为Synchroizedupgradeprocess上面涉及到这几种锁的转换，也就这些了。面试官：好的，那说说Synchroized的升级过程吧？这应该是一个基本的刻板印象，不用多说面试官：你用过HashMap吗，它的存储结构是怎样的？不用说，八股文是最常见的。1.8之前的版本是数组加链表。1.8以后，链表长度达到8的阈值，变成红黑树。当然回答的时候尽量不要这么简单，可以多补充一些信息，比如为什么1.8之后就转，有什么优势等等，给面子，给面试官一个印象，我们的foundation是好的。面试官：你以前用过Volatile吗，修改的作用是什么？变量，保证多线程下修改的共享变量对其他线程可见；禁止指令重排序采访者：Volatile是如何保证可见性的，原理是什么？基于缓存一致性协议（MESI）面试官：线程池的参数是什么，Function是什么，运行的进程是怎么定型的，不多说了面试官：拒绝策略有哪些，你用的是哪个CallerRunsPolicy：线程池外的线程直接调用run方法执行，除非线程池shutdownAbortPolicy：直接丢弃任务，抛异常，默认策略DiscardPolicy：丢弃任务不报错DiscardOldestPolicy：丢弃阻塞队列中最早的任务，放入最新的taskbackinthequeue面试官：有哪些阻塞队列可以不断的加任务（SynchronousQueue），如果用SynchronousQueue，有两个task进来的时候，哪个能进队列，哪个不能进队列，要看线程池的情况。该队列不保留任务。如果提交了任务，则直接转发给线程或创建新线程执行。如果最大线程数满了，就不会进入队列**面试官：如果线程池空闲，哪个参数可以设置多久销毁**keepAliveTime面试官：看你简历上的项目使用mq，为什么使用RocketMQ而不是其他的，并说明选择的原因。公司的项目是电子商务系统。从性能和业务上来说，RocketMQ更合适也更够用。Kafka虽然性能更高，但是功能比较简单。一般来说，在性能达到要求的情况下，大数据和日志处理场景基本选择Kafka，业务处理选择RocketMQ。面试官：你的项目用的是哪个垃圾收集器？CMS面试官：为什么用CMS而不是G1？由于历史原因，一开始使用CMS创建项目，团队成员对G1的调优经验非常少。面试官：你知道CMS的缺点吗？它对CPU敏感。如果CPU数量少，吞吐量会下降很多。;无法处理浮动垃圾，并发清除阶段用户线程还在执行，可能会产生浮动垃圾，到一定程度会出现“ConcurrentModeFailure”，进而导致fullgc。面试官：FloatingforCMSGarbage，有没有办法设置一个参数-XX:CMSFullGCsBeforeCompaction，表示CMS在compacting之前进行多少次fullGC，默认为0。面试官：老年代的GC什么时候发生？老年代垃圾回收的发生意味着触发了FULLGC。一般是老年代空间不足或者调用了system.gc。是的，举个例子排除网络停电之类的抽风。上线问题一般是业务代码有问题或者访问过多导致的。然后根据是否是VMThread，决定使用jstack还是jstat命令进一步排查。面试官：我们来谈谈MySQL。你了解它的索引结构吗？数据库必问的索引构造，B+树面试官：主键索引和非主键索引和索引覆盖有什么区别？在innodb引擎中，非主键索引的叶子节点存放的是主键的值，而主键索引的叶子节点存放的是整行数据。如果没有索引覆盖，根据到非主键索引中查找对应的数据，需要去主键索引做回表查询。索引覆盖是指一个索引包含了所有需要的字段，不用回表查面试官：如果有联合索引a,b，然后顺序aasc,bdesc，索引会不会使用？8.0以后的版本可以，之前的版本不支持desc排序面试官：你是怎么优化sql的？一般来说，在业务代码开发之前一定要对sql进行优化，除了基本的表字段设计外，在开发过程中还需要为业务方法输出相应的sql语句，然后做相应的sql审核和解释分析。同时，还要考虑业务的流量。如果太高，是否需要优化比如强制索引面试官：你用过Redis做分布式锁，那么在Redis分布式锁的核心要保证哪些因素？返回？不，您可以设置等待时间。比如Redisson支持面试官：如果分布式锁的master挂了，锁没有同步到其他机器，那么其他线程也拿到锁。Redis没有分布式怎么办？绝对安全，最有保障的方式就是保证业务是幂等的。面试官：如果锁快要过期了，但是业务还没有处理，怎么处理可以参考Redission的watchdog设计，就是定时更新快要过期的锁。面试官：幂等性和分布式锁是不是同时需要？为什么在有幂等性的情况下还需要加分布式锁来防止用户误操作或者高流量呢？如果业务幂等性完全保证，可能会使流量达到db（很好的问题）面试官：你简历上写过缓存异常的解决方案，那你说说缓存穿透是什么样子的，怎么处理，以及它与缓存雪崩有何不同？缓存穿透：是指缓存或数据库中没有数据，所以每次请求都会去数据库而不是缓存。如果同时有大量的请求进来，会对数据库造成巨大的查询压力，甚至会破坏db系统。一般的解决办法有两种：1、缓存空对象，但是时间要设置的短一些，以免占用大量内存。2.Bloomfilter缓存雪崩：大量key同时失效，导致流量打db解决方案。General就是给key设置一个随机的过期时间，或者mutex来抵抗请求。面试官：项目有没有用到布隆过滤器？延伸一下，比如综合考虑，项目场景不需要做这方面那么复杂的功能，或者在运维层面已经做了很多异常请求拦截，所以不要让面试官想你不会想太多。面试官：你简历上也写了Spring，你了解SpringAOP的原理吗？常见八字随笔，基于Java动态代理，简单描述即可。面试官：如果一个类有两个方法有注解，然后一个调用另一个方法，那个方法的注解会生效吗？不会，因为同一个类不是调用方法的代理对象面试官：说说项目吧，简历上领券的过程是怎样的，为什么？缓存接近100ms的rt引入RocketMQ异步入库方式进行调峰，防止流量过大时接口RT过高。至于为什么还是接近100ms，是因为领取优惠券的逻辑一般都是优惠券包的形式。也就是说同时领取多张优惠券需要大量的判断逻辑，所以高峰期会比较费时间。面试官：你写到订单数据是按照userid维度分表的。基于业务场景的考虑，用户可以查看自己的订单。如果要查的维度是其他字段，比如productid，怎么办？可以把订单数据放到es里，或者定时任务把数据加到广面面试官：你项目每台机器设置多少线程访问，你测试过能支持多少访问吗？表示我们项目的cpu最高只有30%，也就是说至少可以支持两倍的访问量。我真聪明。我记得后面问了几个关于项目的问题，然后面试就结束了。说起来，第一题的难度并不算高。虽然有很多要点，但基本上是一篇普通的八卦文章。项目现场没有什么特别的。第二天HR通知我通过了第一面，然后预约了第二面。大约一周后开始第二轮面试（1小时）。同样是远程视频面试，但是和第一次面试不同的是，这次面试的大部分内容都是和项目相关的。所以，面试前的项目准备是必须下功夫的。不用问了，肯定是一开始就自我介绍了。介绍完后，面试官皱了将近一分钟才开口……面试官：看你的简历，你也在之前的公司待了两天。不用说，为什么这个时候出来找机会？你的前父亲不是都说了吗？要么你钱少了，要么你受了委屈。当然，面试的时候千万不能这么轻浮。谈谈个人发展，职业规划等等。面试官：你觉得现在的公司不能满足你吗？是的，这是我考虑很久的（废话，不然我就急着来面试了）面试官：你说你看过jdk源码，你觉得哪个设计让你惊艳？这因人而异。我会讲解大家熟悉的AQS部分和HashMap索引设计。面试官：缓存崩溃和渗透怎么做面试官：你简历上写了sql优化，那你是怎么设计一个正则八卦的索引的，尽量满足常用的查询字段和使用索引，然后用explain来多做分析大多数情况是可以计划的。下面的问题基本都是项目的细节，比如如何防止优惠券被刷，你觉得你什么时候在工作中有所收获，你做了什么。这些问题没有参考答案。每个人都有不同的项目和工作经验。不一样的，大家根据自己的实际情况回答即可。不过这个过程中还有几个点值得跟大家分享一下，就是分表的迁移和高并发突发流量的问题。因为我之前负责的项目是电商系统，日活百万，订单部分的分表处理也是一个技术亮点。肯定是简历上强调过的，所以在面试的时候也是被问到这两方面的场景。对于分表，我们之前将订单数据从单表同步到100个新表，以用户id为shardingkey，在迁移数据的过程中，需要考虑数据同步的一致性，不影响现有的业务流程，所以我们采用订阅binlog的方式来迁移数据，这是一种比较常规的方案。但是怎么说呢，虽然方案很常见，但是在实际操作中你会发现需要考虑的点很多，比如历史数据和增量数据的同步，是停止迁移还是继续迁移，数据之后迁移是否一致如何切换到新系统，新系统上线后数据异常如何回滚到旧系统等等，如果有同学做过分表的迁移，这些问题应该是头痛。当然，你越是麻烦，面试官就越喜欢讲究。所以，在这方面的技术处理上，一定要提前考虑各种可能，这样才能有更多的精力去应对各种刁钻的面试题。另外，笔者所从事的电商项目，也包含了秒杀部分的功能。虽然QPS不高，但也需要做好秒杀系统的常规处理，比如限流、高并发扣库存、保证不超卖等。从我个人的经验来看，有应对秒杀的高并发场景无外乎两种选择，要么同步，要么异步。实际操作无非是增加机器或者放入队列等待。高流量下的一切业务缺陷都会被无限放大。您需要针对各种异常情况采取预防措施，以及补偿机制。限于篇幅，这里不能过多解释，而且我对所有的场景处理经验都不熟悉，所以只能介绍几个思路，供大家思考，比如限流的策略是什么、如何防止大量恶意请求；哪里减库存直接减db库存数据，还是预减库存，如果是预减库存，redis减库存了，db没有减库存怎么办？秒杀过程中Redis等服务宕机了怎么办？流量突然变大，以至于某个商品的访问量超过Redis单机阈值??怎么办；如果引入一个消息队列作为调峰组件，那么消费太慢用户一直在等待，怎么处理等等。虽然我们在实践中基本没有机会遇到这么大的访问量，你无法阻止面试官是否会调查。因此，如果你的项目涉及到高并发场景，我建议你在这些方面的学习上下功夫做好准备。让我们谈谈采访吧。问完项目，基本没有技术问题。剩下的就是一些软实力的问题，比如你为什么要写博客？还有未来的职业规划之类的。这些问题也因人而异。虽然不难，但还是提前做好准备，帮助你在面试过程中顺利表达。所以，我也建议大家可以准备的软一些。实力问题。结语：八字文的题不多，更多的是project的题，还有一点软技能的题。总体来说还是有一些难度的，面试过程还是比较顺利的。过几天会通知面试通过。三面（2h）三面的面试官是欢聚的技术总监，也是视频面试。这边没有技术问题，更像是聊天。说实话，面试官真的很会聊天。整个面试过程持续两个小时。我小的时候，他一直在介绍YY的一些历史和我面试的部门的业务情况。他还对我以后的技术方向提出了一些建议，让我受益匪浅。总的来说，虽然在技术面试中收获不大，但是遇到这么热情的面试官还是很幸运的。在此万分感谢，可惜后面有更好的offer，没机会跟他做同事了。hr面试没什么好说的。我交换了我的职业情况和期望薪水，几天后，我在账单完成后发送了offer。总结一下，整个面试过程大致是这样的。我想对于大家来说，看完文章，收获的可能是一方面分享，另一方面分享。至于常规的面试检查点，我个人的话还是一样的，只要提前做好充分的准备，还是可以从容应对的。我的个人经历没什么可说的。毕竟整个过程还是比较顺利的，也没有出现什么刁钻的问题。后面会写几篇面试，介绍一下我在其他公司面试遇到的困难。我希望能帮助你。坑。好了，今天就到这里吧，下次再见。
