1. 一场让我差点绷不住的面试开场先交代一下背景。我在某互联网公司做Java方向的技术面试官做了差不多五年面过的人数没有一千也有八百。按公司流程面试分两轮第一轮通常是基础技术考察我常年负责这一轮。我给自己定的风格是——开场先给压力让候选人尽快进入状态所以全程表情管理基本是零不笑、不接梗、不看候选人脸色只盯技术点和解题路径。那天下午的候选人简历写得很漂亮三年Java后端经验项目栏里挂着两个高并发电商相关项目技能清单里罗列了并发编程、JVM调优、消息队列、分库分表这些关键词。我照例先让他做了个自我介绍结果他开口第一句就说了句让我完全没想到的话面试官您好我提前声明一下我这个人比较搞笑但代码不搞笑。我当时表情没动心里已经有点想笑。这种话从候选人嘴里说出来一般有两种情况一是真的活跃型选手技术底子靠得住用幽默化解紧张二是纯嘴皮子选手答不上来就靠打岔混过去。我决定用一道经典并发题来试探深浅。volatile关键字你平时在项目里怎么用为什么它能保证可见性他几乎没有犹豫张口就来volatile就是给变量加了个广播效果。一个线程改了值其他线程马上能收到通知。就像宿舍里一个人喊了句楼下查寝了整层楼都听见了没人还在那闷头打游戏。我愣了一下。这个类比粗是粗了点但方向是对的。我没有表态接着追问那它能保证原子性吗他摇摇头不能。它就是个大喇叭负责通知不负责站岗。真要保证原子性得让synchronized或者Atomic类上。我点了点头。这个开场让我隐约感觉到今天这场面试可能真会往一个不太常规的方向走。我决定不按部就班地出基础题而是直接往上强度看看他这层搞笑外壳底下技术深度到底能扛到哪一级。2. volatile的广播类比底层原理与面试官真正想听的答案2.1 从宿舍广播到内存屏障说实话广播这个类比在我面试过的候选人里算贴切的但作为面试官光有类比是不够的。我需要确认他是真懂底层还是只是背了个段子。于是我把问题往深了带。好你说volatile是个大喇叭。那我想知道它广播的时候底层到底发生了什么JVM是怎么实现这个通知的他想了想回答得比我想象中更扎实volatile变量在编译后会多出一个lock前缀指令。这个指令的作用是把当前处理器缓存行的数据写回主内存而且这个写回操作会触发其他处理器核心里缓存了同一地址数据的失效。别的线程再读这个变量的时候发现自己的缓存行失效了就会重新从主内存拉最新值。我内心是满意的。这个回答已经把Java内存模型、缓存一致性协议、指令层实现串起来了。我继续追问那你说的失效具体依赖的是什么机制缓存一致性协议比如MESI那一类。每个缓存行有状态标记Modified、Exclusive、Shared、Invalid。volatile的写操作会让其他核心里的副本变成Invalid状态下次读的时候就触发cache miss从主存重新加载。到这里我已经能基本判断这个人的并发基础是过关的。但作为面试官我还要考察另一个维度——他是否真的在项目里用过volatile还是只是面试前背了一堆八股。2.2 项目里的真实使用场景双重检查锁的单例你刚才说你在电商项目里用过volatile具体是哪个场景单例模式双重检查锁。他回答得很干脆对象创建不是原子的new关键字在底层有三步分配内存、初始化对象、把引用指向内存。如果第二步和第三步被重排序另一个线程就可能拿到一个半初始化的对象。所以单例的实例字段要加volatile禁止重排序。我追问能不能跟我描述一下你当时是怎么定位到这个问题的是理论推导还是线上出了事故他这次没有立刻回答顿了一下说线上出过一次事故。一个活动服务在高峰期偶尔会出现读取到空配置的情况。那个配置对象就是懒加载的单例。我们一开始以为是网络问题后来抓了线程快照排查了很久才发现是对象发布的时候出现了重排序。加了volatile之后问题消失。我没有继续往下挖这个事故的细节因为从面试节奏来说我需要在一个问题上控制时间。但这个回答让我心里给他加了分——他不仅知道volatile还知道它解决的是安全发布问题而不是单纯拿它当性能优化手段。很多候选人会把volatile当成更快版本的synchronized这是完全错误的理解。2.3 面试官视角这个考点究竟在筛什么我在面试里问volatile核心想考察三件事第一候选人是否理解Java内存模型中的主内存与工作内存概念第二是否知道可见性和原子性的区别会不会把volatile和synchronized混为一谈第三是否在真实项目中用过用的场景是不是合理。很多候选人挂在第二点上上来就说volatile能保证原子性或者volatile比synchronized快所以用它替代锁这类回答在我这里基本当场判负。而这位候选人不但分得清还知道禁止指令重排序这个隐藏考点属于超出预期。我当时的判断是这个人应该不是纯背题选手他大概率有真实的并发编程经验。但Java面试远远不止并发我决定把战场拉到集合框架看看他在最基础的HashMap上会不会翻车。3. HashMap的传奇家庭关系从搞笑比喻到红黑树原理3.1 当候选人说HashMap是校长时那我们聊聊HashMap。你知道JDK 7和JDK 8的HashMap有哪些区别吗他清了清嗓子用一种说书人的语气开始讲面试官我把HashMap比作我们村的学校。JDK 7的时候学校只有一个校长办公室出了问题大家都往办公室门口挤挤成一排查谁的问题就得从头挨个问效率低JDK 8之后学校扩建了办公室里装了分诊台人太多的时候分诊台会把队伍重新整理成一棵二叉树找人快多了。我花了三秒钟才把这个比喻映射回技术概念。校长办公室是哈希桶挤成一排是链表分诊台整理成二叉树是链表转红黑树。我点点头没有纠正他因为他说的二叉树严格来说应该是红黑树但方向对了。我决定往细节里问。那你能说说链表转红黑树的条件是什么为什么是8和64这两个阈值3.2 为什么是8和64从泊松分布到工程权衡这次他答得没有那么快我先看到他在纸上画了几下然后抬起头说链表长度超过8并且数组长度超过64的时候链表会转成红黑树。为什么是8我记得源码注释里提到过泊松分布在负载因子0.75的情况下哈希桶内链表长度达到8的概率大约是千万分之六也就是约一亿次里面才可能出现6次。这个概率已经足够低如果还出现说明哈希函数可能出了问题这时候用树化来兜底。我追问为什么还要要求数组长度达到64因为如果数组长度太小说明是容量不够导致桶里堆积这时候应该优先扩容而不是树化。扩容能让元素重新分布链表自然缩短。树化反而会增加维护成本红黑树的插入和删除要做旋转和变色节点又比普通链表节点占用更多内存。这个回答完全在我的预期答案范围之内甚至比很多工作五六年的人说得都完整。他连千万分之六这个概率都记得说明他是真的翻过源码注释而不是只看了一篇博客。我决定再考一个HashMap的高频坑点——并发环境下的问题。3.3 并发下的HashMapJDK 7死循环与JDK 8数据覆盖HashMap不是线程安全的这个你知道。那我问你JDK 7里并发put可能会导致死循环JDK 8里还有这个死循环问题吗JDK 7的死循环主要发生在扩容时transfer方法把头插法把链表节点迁移到新数组并发情况下可能形成环形链表get的时候就会死循环。JDK 8改成了尾插法环形链表的问题基本解决但并发put仍然会有数据覆盖的问题。两个线程同时计算到同一个桶位置都执行插入后写的会覆盖先写的丢失更新。而且JDK 8的扩容逻辑在并发情况下也可能丢数据。我没有纠正他因为他的回答技术上是对的。头插法改尾插法确实是JDK 8的调整之一环形链表问题确实在JDK 8下不再出现但并发安全问题依然存在。这说明他对HashMap的演进有跟踪不是停留在背某个版本的结论上。3.4 这个环节的面试经验别拿底层是数组链表这种答案糊弄人我面过太多候选人问HashMap底层得到的回答永远是数组加链表。你再追问一句为什么数组长度总是2的n次幂很多人就卡住了。这里我一般会带一句话提醒候选人hash值对数组长度取模用的是(n - 1) hash因为n是2的幂次时这个位运算等价于取模但性能更好。如果再深入一点还要知道hash方法为什么要高16位异或低16位——因为这样能让高位信息也参与路由减少冲突。这位候选人显然不需要我提醒因为我还没开口他就主动说了HashMap的hash方法就是把key的hashCode右移16位再异或让高位也参与定位降低碰撞概率。取模用的(n - 1) hash这个位运算。他连这个都主动说了。我在面试记录上写下了集合优秀三个字然后带他进入了今天最关键的一个环节——线程池。线程池这道题在我的面试体系里属于定生死级别的问题因为它的考察维度横跨参数理解、任务执行流程、底层队列、拒绝策略、源码级实现还特别容易从里面延伸出场景设计题。4. 线程池的银行网点理论一场教科书级别的场景推演4.1 开场就是一道场景题你开了一个银行网点我问他假设你开了一个银行网点三个柜台窗口一个等待区。现在客户越来越多你怎么设计这个网点的接待策略他愣了一下然后笑了面试官你这是让我现场设计一个线程池啊。可以这么说。你按照你的理解来设计。他清了清嗓子真的开始讲三个柜台窗口就是核心线程数corePoolSize等于3。等待区就是阻塞队列BlockingQueue。网点如果人多柜台先上三个窗口也就是核心线程满负荷。如果三个窗口都忙着新来的客户就去等待区排队。我点了点头示意他继续。但等待区也不能没有上限。如果等待区满了就得加开窗口——这就是maximumPoolSize。提交任务时如果核心线程满了、队列也满了线程池就会创建新线程直到达到最大线程数。到了最大线程数还是不够用就得有拒绝策略了。4.2 细节追问核心线程数、队列类型与拒绝策略怎么选我决定把他的设计往深处追问。我问了两个关键问题。第一个问题corePoolSize、maximumPoolSize、workQueue这三者之间线程池创建新线程的时机到底是怎样的很多人搞混一个点——是先填队列还是先开新线程他答得很稳提交任务时先判断核心线程是否都在忙。是的话任务进队列。队列满了才会判断是否还能创建非核心线程。也就是说线程池的设计思路是优先让核心线程干活多余的先排队排不下了再扩张线程。跟很多人的直觉相反不是核心线程一忙就立刻开新线程而是先塞队列。第二个问题你刚才的银行网点模型里等待区用的队列你会选哪种有界还是无界为什么我会选有界队列。ArrayBlockingQueue是有界的可以明确知道最多积压多少任务。如果选无界的LinkedBlockingQueue队列可以无限增长maxPoolSize参数就形同虚设了——因为队列永远都不会满线程池永远不会创建非核心线程。一旦流量洪峰过去这些积压任务慢慢消费但也没有弹性扩容的能力系统吞吐会被卡死。这个回答完全在我的预期里面。更让我欣赏的是他接下来的一个补充如果业务允许丢弃一部分请求也可以用SynchronousQueue这个队列不存任务来了就交给线程线程不够就立刻创建新线程。配合CallerRunsPolicy之外的策略使用适合那种追求低延迟、可丢弃的短任务场景。4.3 从设计回到参数ThreadPoolExecutor的核心参数速查到这里我基本上已经确定这个人的线程池理解不是背的是真能用的。面试记录上我在线程池这一栏打了高分。这里我顺便把ThreadPoolExecutor的核心参数整理成了一个速查表格方便读者直接背下来用于面试或项目复盘。参数作用设置建议corePoolSize常驻线程数量即使空闲也不会被回收根据业务类型设置IO密集型建议偏大CPU密集型建议接近CPU核心数maximumPoolSize线程池允许的最大线程数必须考虑系统资源上限不建议无限大keepAliveTime非核心线程空闲存活时间根据任务到达间隔和资源成本权衡workQueue任务等待队列默认选有界队列明确容量上限threadFactory线程工厂必须自定义设置线程名方便排查问题handler拒绝策略默认AbortPolicy会抛异常线上常用CallerRunsPolicy我特别想强调一点自定义线程工厂这件事很多候选人会在简历上写使用线程池但问到他线程池里的线程叫什么名字怎么排查线程池引发的故障时就完全答不上来。线程池在生产环境出现瓶颈时如果没有自定义线程名你抓线程快照看到的全是pool-1-thread-1这种名字排查起来会非常痛苦。你平时线上线程池会做监控吗我补了一个问题。会。我一般用ThreadPoolExecutor暴露的几个指标getActiveCount看活跃线程数getQueue看一下队列积压情况getCompletedTaskCount看完成任务总数。之前做过一个小工具定期采这些指标推到监控系统队列积压超过阈值就告警。好线程池这一关他过了。我看了一下时间已经过了三十分钟我决定进入今天的最后一个技术高地——JVM。如果JVM也能顺利过关这场面试的综合评价基本就是Offer级别了。5. JVM终极对决从类加载是找女朋友到GC与线上事故实战5.1 双亲委派机制一个让我差点破功的比喻我问他JVM的类加载机制双亲委派你怎么理解他想了想说面试官你听过一句话叫有问题找爸妈吗类加载器就是这样。一个类加载器接收到加载请求时不会自己先加载而是先把请求派给父加载器。父加载器再往上派一直派到最顶层的Bootstrap ClassLoader。只有父加载器说自己加载不了子加载器才会自己去尝试。那你觉得这个机制的意义是什么防止类被重复加载更重要的防止核心类库被篡改。比如你自己写一个java.lang.String如果没有双亲委派这个类可能就被你自己的类加载器加载了整个JVM的类型体系就乱了。双亲委派保证了Java核心类库的加载都是从Bootstrap开始的保证类型安全。我点点头又问了一句那如果父加载器加载不到子加载器也会加载失败吗不一定。父加载器抛ClassNotFoundException子加载器会自己尝试加载。这就像爸妈说这个我不会那你只能自己去学。Tomcat的WebAppClassLoader就是这么干的它打破了双亲委派优先自己加载Web应用下的类这样才能实现不同应用之间的类隔离。这个打破双亲委派的知识点不是所有人都能答出来的。Tomcat的做法是Common类加载器加载公共类WebApp类加载器优先加载WEB-INF/classes下的类这样同一个Tomcat里部署两个应用即使它们依赖了不同版本的同一个类库也不会互相冲突。我确认他是真的理解了这个机制的灵活性和应用场景。5.2 GC根可达性与线上事故现场排查思路还原最后一题我把难度拉到了线上实战级别假设你的线上服务突然CPU飙升到100%并且频繁Full GC。你只有一台机器的访问权限你怎么排查他几乎没有停顿直接给出了一个非常标准的排查链路第一步先执行top命令找到CPU占用异常的Java进程拿到PID。然后top -p PID -H看一下这个进程里面哪个线程在疯狂消耗CPU拿到线程的十六进制线程ID。第二步执行jstack PID thread_dump.txt把线程快照导出来用刚才的十六进制线程ID去线程快照里搜找到对应的线程看它停在哪个方法上。是GC线程还是业务线程。第三步如果是GC线程导致CPU飙升再用jstat -gcutil PID看看各代内存使用情况确认是不是老年代涨满了。如果是再配上jmap -dump:formatb,fileheap.hprof导出堆快照用MAT分析哪个对象占用了大量内存。常规情况下要么是大对象分配问题要么是内存泄漏要么是某个并发集合无限增长。找到引用链基本就能定位到业务代码的哪一行。我看着他心里已经决定这场面试可以结束了。他的排查链路完整、操作命令准确、分析思路清晰这已经不是背题能出来的水平而是真的动手处理过线上问题的人。我最后问了一个开放性问题你觉得自己刚才回答搞笑吗他笑了面试官我说实话我这个人说话是有点贫但我写代码很严肃。我知道面试是看技术的不是看段子的所以我回答问题的时候尽量用生活里的例子帮自己理思路但技术和结论不敢瞎编。我在面试记录上写下了通过两个大字。6. 面试官复盘搞笑外壳下的技术硬实力才是真正的对决6.1 这位候选人为什么能通过面试结束之后我复盘了整个面试过程。说实话搞笑程序员这个标签在面试里天然有优势也有风险。优势是有记忆点容易让面试官在后续讨论中想起他风险是如果技术底子不够厚搞笑就变成油腻和回避。这位候选人之所以能在严肃面试官与搞笑程序员的对决中胜出核心原因有四个第一他的幽默是辅助理解的工具而不是逃避问题的掩护。他每次抛出一个比喻之后都会快速跟进一段严谨的技术原理描述。比喻吸引注意力原理证明实力两者缺一不可。第二他的技术深度是线性的不是孤立的。从volatile讲到内存屏障从HashMap讲到红黑树和泊松分布从线程池讲到拒绝策略和监控指标。每个知识点都能向下延展至少三层。第三他有真实的实战经验做底。双重检查锁的线上事故、线程池队列积压监控、GC排查的操作命令这些问题如果不是真的处理过很容易在追问环节露出破绽。第四他面对压力不慌张。我全程严肃不给他任何正面反馈但这种高压环境反而让他发挥得更好。这本身就是大厂业务场景下非常需要的能力。6.2 给候选人的几条面试实操建议作为面试官我见过太多优秀的候选人因为表达问题错失Offer也见过很多技术平平的人因为沟通能力强加了印象分。关于面试风格这件事我有几条比较真实的建议不要刻意搞笑。如果你本身不是幽默的人强行讲段子只会让场面尴尬。这位候选人能搞笑是因为他平时就是这样思考和表达的是他的自然状态。面试官要的是真实的你不是你没演好的别人。比喻可以用但必须紧跟技术细节。一个宿舍广播校长办公室这样的类比如果只用来说概念但说不清背后的MESI协议、lock前缀指令、泊松分布面试官会认为你是在用段子掩盖无知。技术深度比广度更值钱。与其把数十个知识点都背个皮毛不如把核心高频考点并发、集合、JVM、Spring研究透。每一轮追问都是机会能接住两三层追问的人和只能接住一层的人面试评价完全不同。线上经验一定要准备真实案例。面试官问你遇到过什么问题、怎么排查、怎么解决不是为了听你讲结果而是为了看你的排查思路、工具链熟练度、问题拆解能力。哪怕是小问题只要能讲清楚来龙去脉都比背一个别人写的复杂案例强。6.3 关于严肃面试官我为什么全程不笑最后我聊一点我个人的面试习惯。很多人觉得面试官严肃是故意给压力、或者面试官本身性格冷。严肃对我的意义只有一个尽量减少对候选人的暗示确保我看到的是他真实的技术水平而不是被我表情引导出来的表演。一个全程不笑的面试官实际上给了候选人最大的空间。你可以选择被这个气场压倒也可以像这位候选人一样用自己的节奏和风格来接节奏。技术面试的本质不是看谁背得多而是看你在一个不舒适的场景下能不能依然保持逻辑清晰、表达准确、遇乱不慌。这场对决最终的结局我已经给了Offer。严肃面试官依然严肃但他在面试记录里写的是候选人沟通风格独特技术基础扎实解决了多个线上实际问题建议录用。搞笑程序员也没有改掉他的说话方式他后来入职以后据说在周会上讲技术方案的时候还是满嘴比喻。但所有人都承认他写的代码和他在周会上讲段子的水平一样都是真实力。
