扫一扫
兄弟们！前两天刚面完B站Java岗，今天来和大家分享下我的面试经历和准备经验！说实话，面完感觉整个人都不好了，面试官太强了，问题环环相扣，差点没绷住😂 不过收获也很大，赶紧整理出来给大家参考参考！
一、Java基础部分 - 看似简单坑不少
面试官一上来就问：“Java基本数据类型有哪些？它们的包装类分别是什么？”
我当时心想：这么简单？是不是在放水？结果回答完他来了一句：“那Integer a = 127和Integer b = 127比较，a==b返回什么？如果是Integer a = 200和Integer b = 200呢？”
// 真相：
Integer a = 127;
Integer b = 127;
System.out.println(a == b); // true
Integer c = 200;
Integer d = 200;
System.out.println(c == d); // false，这里很多人答错了！
讲真，这个Integer缓存池的问题太经典了，-128到127之间的数会被缓存，超出范围就是新对象了。我差点就掉坑里了，还好前一天晚上刚好复习到了😅
HashMap那可真是B站面试的必考题！面试官问得特别细，我感觉他能把HashMap源码倒背如流！
我讲到JDK1.8中链表转红黑树的条件时，脑子一热说成"链表长度大于8就转红黑树"，面试官立马抓住我：“确定只要大于8就转吗？”
我瞬间意识到自己说漏了关键条件，赶紧补充：“不对不对，是链表长度大于8并且数组长度大于等于64才会转，否则只会扩容！”
面试官微微一笑：“还有印象，很好。”（妈呀，差点凉凉！）
二、多线程与并发 - 面试官最爱的"送命题"
聊到线程池时，我刚开始背了一遍七个核心参数，面试官突然打断我：
“别背书了，你们项目中用的什么线程池参数？为什么这么设置？”
这下子我心里一慌…平时确实没怎么关注过具体参数的设置原因。不过还好我们团队技术负责人之前分享过一次，我就把他讲的理由搬出来了：
“我们订单系统用的是IO密集型任务，核心线程数设置为CPU核数2，最大线程数是核心线程数4，队列用的有界LinkedBlockingQueue，长度设为1000…”
面试官接着问：“如果订单量突然暴增超过处理能力，你们用的什么拒绝策略？为什么？”
我：“CallerRunsPolicy，让调用者线程自己执行任务。因为我们希望降速而不是直接丢弃请求或抛异常，这样虽然系统变慢但至少请求不会丢失…”
这回答好像挺对胃口的，面试官点点头继续下一个问题。
哦对了，线程池千万别说用Executors创建的！我同学就因为说用了Executors.newFixedThreadPool而被面试官"教育"了一顿，说这是阿里Java开发手册明确禁止的😂
三、JVM - 真·送命题
JVM是真正能看出你技术功底的地方，面试官开始问我：“最近有没有遇到过OOM问题？怎么解决的？”
老天爷啊！真是问到了痛处！上个月我们生产环境确实发生过一次内存泄漏，半夜被电话叫醒紧急处理。
我就把这次经历老老实实分享了：
“有次上线新功能后，系统运行几小时就OOM了。我们先用jmap dump了堆内存，然后用MAT分析，发现有大量的ConnectionHolder对象没被释放。排查代码发现是数据库连接没有正确关闭，try-finally块里漏了close语句。临时解决是回滚代码，彻底解决就是规范使用连接池和try-with-resources…”
面试官好像很满意我的"惨痛教训"，笑着继续问了几个JVM调优的问题…
G1收集器我重点准备了一下，因为听说B站很多服务都在用。面试官果然问了：
“为什么从CMS迁移到G1？G1的优势在哪？”
我：“主要是为了降低延迟。CMS会产生浮动垃圾，Full GC时会STW，对我们的视频服务影响很大。G1的Region设计和可预测的停顿时间对用户体验更友好…”
四、Spring全家桶 - B站技术栈的日常
Spring部分面试官问得比较随意，但有个问题很有意思：
“说说你对Spring Bean生命周期的理解？”
我正要背那一堆步骤，突然想起面试官说的"别背书"，于是换了个思路：
“这个问题我理解的重点是Spring提供了哪些扩展点让我们介入Bean的生命周期。比如实现InitializingBean接口或者用@PostConstruct注解，可以在Bean初始化后做一些操作。我们项目里就用@PostConstruct来初始化本地缓存…”
面试官笑了：“很好，聊点实际的。你们用Spring Boot多久了？遇到过什么坑吗？”
我直接说了实话：“去年迁移老项目到Boot 2.x时踩过坑，比如自动配置和我们的自定义配置冲突导致启动失败，排查了好久才发现是@ConditionalOnMissingBean的条件判断出了问题…”
五、微服务和分布式 - B站的基础设施
聊到微服务，面试官没问太多理论，而是直接问：
“你们的服务间调用怎么保证高可用？”
这个问题很实际！我说了我们项目中的实践：
“首先是服务注册发现用的Nacos，客户端用Feign+Sentinel做熔断降级。关键请求还会设置不同优先级，核心链路的超时时间会短一些，非核心链路可以适当放宽。熔断策略也是根据业务重要性区分设置的…”
分布式事务问题简直是B站面试的杀手锏！可能因为他们业务场景复杂吧。
当时我说我们用的是"可靠消息+最终一致性"的方案，面试官立刻抓住一个点：“如果消息发送成功，但是消费失败怎么办？”
我：“我们的消息中间件支持重试机制，如果多次重试还是失败，会进入死信队列，然后有专门的补偿任务定时扫描处理…”
面试官又问：“那如果是分布式锁失效导致的并发问题呢？”
这个问题确实有点难度，我承认我们项目中也遇到过类似问题：
“确实遇到过Redis分布式锁在网络抖动时提前释放的情况，后来我们引入了Redisson的红锁（RedLock）机制，同时在数据库层面增加了乐观锁作为最后的防线…”
六、B站特色问题 - 直击业务痛点
面试官突然话锋一转：“如果让你设计B站的播放量统计系统，怎么做？”
这个问题我还真想过（毕竟平时刷B站嘛），我分享了我的想法：
“播放量统计最大的挑战是高并发写入和准确性平衡问题。我会用缓存+异步写入的方式，比如用Redis计数器先累积，再定时聚合写入数据库。为了防止刷量，需要结合用户行为分析，比如同一用户短时间内的重复播放只计一次，IP+设备信息也要作为判断依据…”
面试官似乎对我的回答挺满意，接着问：“那弹幕系统呢？”
我说：“弹幕系统核心是实时性和承载能力。前端可以用Canvas绘制弹幕，通过WebSocket实现实时推送。后端的话，热门视频的弹幕压力很大，可以用消息队列做削峰，同时基于视频时间轴做分片存储，只加载当前时间段附近的弹幕数据…”
面试官笑着说：“看来你是我们的重度用户啊！”
总结与血泪教训
面试完整个人都虚脱了！B站的技术面试真不是盖的，从基础到架构，从理论到实践，问得特别全面。
给大家几点我的血泪教训：
-
千万别装懂！ 不懂就是不懂，我有个问题答不上来直接承认了，反而聊起了我正在学习的方向，面试官好像更欣赏这种态度。
-
项目经验要有亮点！ 不需要有多高大上的项目，但一定要能说出你解决过的实际问题和思考过程。
-
基础一定要扎实！ HashMap、多线程、JVM这些老生常谈的东西每次都会考，而且会问得很深入。
-
要有自己的技术思考！ 面试官很反感背书式的回答，他们更想听到你对技术的独立见解。
-
了解B站的业务场景！ 提前想想视频网站可能会遇到哪些技术挑战，会加分不少。
啊对了，B站面试结束前还问了我最近关注的技术趋势…我提到了Java 17的新特性和Spring 6的变化，面试官好像挺意外我会关注这些。
总之，无论结果如何，这次面试让我学到了很多！希望我的分享对大家有帮助，如果有收获的话，点个赞呗！有什么问题也欢迎在评论区交流，毕竟大家一起进步才是真的！
想要获取更多面试真题，可关注我的公众号获取！
1144
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
