2026年Java面试高频知识点图谱集合多线程

PAGE2026年Java面试高频知识点图谱：集合/多线程/

去年春天，我第一次在一场自认为稳拿的面试里被问懵。面试官让讲讲HashMap的扩容和并发场景，我脑子里只有“0.75”和“2倍扩容”。你可能也有这种感觉：题都见过，真上场就卡壳，尤其是“Java面试高频”里的集合和多线程。一、起因：一次Java面试高频题崩盘的清晨去年四月的一个阴天，北京知春路，我提前了20分钟到公司楼下。电梯里只有我和一个背着黑色双肩包的小伙，他刷了下工牌看了我一眼，我居然紧张得按错了楼层。那时我做了8年后端，自以为把集合与并发翻烂了，手机里拉了一个“Java面试高频”清单，64个条目，我能背出超过80%。我太自信了。真的。场景还原很具体。上午10点03分，会议室B302，面试官姓陆，三十多岁，戴细框眼镜，一口气抛出三个问题：HashMap在并发下为什么会链表成环，ArrayList的扩容触发条件是什么，线程池的拒绝策略有哪几种以及业务怎么选。我开局还算顺利，提到了负载因子0.75、阈值threshold、size超过阈值触发resize，我甚至说出了JDK8引入红黑树把超过8的链表转树减轻冲突。然后他接着问：那为什么说JDK7下并发put会造成链表环，能讲讲迁移过程中的头插吗。空气忽然稠了。心里空白。要点我不是没背，只是没和场景打通。要点是HashMap的数组下标用扰动函数hash^(hash>>>16)降低碰撞，扩容resize时JDK7会rehash并采用头插法迁移，多个线程同时迁移会出现环链；JDK8改成尾插并引入树化阈值和退化阈值（大于8树化，小于6退化），并发下仍不安全。这个知识点，我背了三遍。却没画过迁移的指针图。例题当时就摆在桌面。面试官把白板笔递给我：“现在两个线程同时触发resize，旧表某个桶里有A→B→C的链，能画出可能的环吗？”我握笔心跳到每分钟110，手心冒汗。我画了一个A新桶位置，再画B，然后停了。我没把next指向的时序说清。尴尬。解题思路应该是把迁移的伪流程口述并在白板上标注时间线：线程1读到A.next指向B，把A头插到新桶，A.next指向新桶原头；线程2几乎同时操作B，也改写了B.next指向，并把B插到了新桶的头，如果此时线程1还在用旧的B.next，可能让某个节点next指回自身或前驱，最终形成环。加一句补充：JDK8避免了这个问题，但仍不保证线程安全。点要说到位。要靠图。那天的第二个坑是ArrayList。他说：“扩容是不是往往1.5倍？”我条件反射地说是。他摇头：“准确说不是1.5固定倍数，而是old+(old>>1)，在小容量时还有最小容量和ensureCapacity的影响。”我脸有点热。又问：“fail-fast在什么情况下触发？”我说“多线程修改”，他又摇头：“单线程remove也可能触发，关键是modCount的结构修改。”我当场愣住。没辩解。最后一个连环问题是线程池。面试官给了一个场景：服务QPS在3000，任务执行时间50ms，瞬时突刺到6000，现在线程池core8max16，队列是LinkedBlockingQueue无界，拒绝策略默认。问我会出什么问题。我说“可能OOM”，他点头让细化数据。我没算队列积压。我的大脑短了线。尴尬到能听到空调声。那天用了37分钟，我回答率勉强60%，过了午饭才从会议室出来，手机里记了9个问题，7个和集合与多线程直接相关。我知道问题不在记忆，而在脑子里缺一张“知识点到场景”的地图。那就是我要做的“Java面试高频知识点图谱”。我给自己定了21天。时间卡死。操作上我当天就给自己定了三个小步骤。1.把失败的问题逐条还原成可执行的白板演示，画图，记录时间点。2.在本地写三个最小复现实验：HashMap并发put，ArrayList扩容边界，线程池队列积压。3.对每个问题给出一个数字化结论，比如触发阈值、扩容后的容量、拒绝策略触发的百分比。我想把抽象变实物。必须做。二、经过：我把集合与并发拆成面试高频图谱回去的那周很忙，但我把地铁上的48分钟全用来搭骨架。电脑里开了两份源码，一份是JDK8的HashMap和ArrayList，一份是ConcurrentHashMap，我边看边用手画箭头，把“概念点”换成“问答点”，每个点后面加一条“可以现场构造的例题”。这不是学习方法论，是临时救火时的拆题清单。很笨。却有效。我先把集合线拉齐。书上说的fail-fast，我把它换成：“modCount变更不等于迭代器快照expectedModCount，下一次next或remove就抛ConcurrentModificationException。”我又把fail-safe用CopyOnWriteArrayList的场景举了出来：晚上22点，我们监控面板的标签页列表需要在展示时动态增删，读远多于写，我让同事小张把原来的SynchronizedList改为CopyOnWriteArrayList，读延迟下降了35%，写操作变慢但每分钟写不到20次，完全可接受。那晚我给他买了两瓶气泡水。便宜的奖赏。开心。要点我写成了三行一段的口供。比如HashMap的树化阈值是8，退化阈值是6，数组容量不小于64才会发生树化；HashMap容量始终是2的幂，扩容新容量是旧容量的两倍；负载因子默认0.75，它和容量共同决定阈值threshold。例题自然跟着来：“面试官问：为什么容量要是2的幂，给我一个冲突降低的例子。”解题思路是把hash的低位分布不均说清楚，再加上位运算的优化，把n-1与hash做与的好处讲出来，顺手画一行16桶的二进制，说明非2的幂会导致高位参与更少，冲突增大。我在纸上算了3次。手不抖了。我又把LinkedHashMap写成LRU的“面试友好题”。要点是accessOrder构造参数为true时，get会挪到尾部，从而形成访问顺序；重写removeEldestEntry可以实现固定容量下的最近最少使用淘汰。例题我选了一个小功能：缓存最近100个用户的头像URL，在10秒内命中率目标80%，如何设置结构和大小。解题思路是在构造函数传入初始容量128、防止频繁扩容，并发场景下用Collections.synchronizedMap包一层或者换成Caffeine；同时把命中率和实际用户访问分布关联，给出“上午10-11点高峰时段82%命中”的数字。数字有说服力。这一点很多人不信，但确实如此。并发线更硬一些。我把synchronized的锁升级路径画了一遍：偏向锁、轻量级、自旋、重量级，通过对象头的MarkWord状态位和Monitor入队来理解争用。我在纸上记了一个细节：JIT会做锁粗化与锁消除，当连续的小同步块围绕一个对象时，可能被合并到更大的范围。例题是：“for循环里每次newStringBuilder并同步追加，是否可能被优化？”解题思路：在没有逃逸的情况下，JIT可能把同步消除，局部变量在线程栈中，线程安全；如果对象逃逸到堆，消除就无从谈起，建议用ThreadLocal或直接复用一个StringBuilder。讲完再补一句：准确说不是“JVM总会优化”，而是“在逃逸分析判定为不逃逸时，优化才可能发生”。这话严谨。重要。线程池是我重新梳理的重点。我不再只背四种拒绝策略名字。我按数字拆开：corePoolSize8，maximumPoolSize16，队列长度1000，任务耗时50ms，在QPS3000的突刺里，一秒内最多进来3000个任务，core线程能执行8×(1000ms/50ms)=160个，其他进入队列，1000个队列0.33秒就打满，然后开始扩到16个线程，额外8个线程每秒也就再处理160个，仍然挡不住突刺，0.5秒后拒绝策略触发，触发概率大约30%左右。这个算式在白板上用5行就能写清。我还画了两条直线表示积压与释放。直观看懂。落地。为了让自己记住，我每个知识点都配了一个“面试版例题”。比如CompletableFuture。要点写的是supplyAsync的线程池默认用ForkJoinPmonPool，CompletableFuture.allOf会在所有子任务完成后汇聚；当其中一个任务异常时，allOf本身不抛异常，异常会在join或get时抛出，需要handle或exceptionally处理；如果要保证限流，最好自己传入有界线程池。例题是“并行拉取5个下游服务，每个80ms平均，目标200ms内返回，失败一个是否降级”。解题思路：用自定义ThreadPoolExecutor，队列用LinkedBlockingQueue100，超时用orTimeout，降级策略在anyOf上挂exceptionally，并且用allOf控制整体超时200ms，超过则返回兜底。这个场景里，我拿出了一次线上数据：去年双十一凌晨1点40分，5个服务里有1个抖动300ms，我们提前加了orTimeout200ms，整体成功率保持在99.93%。具体数字最有力量。别害怕给出。每个阶段我都强迫自己有一个可执行动作。那周的操作步骤，我做了如下三点。1.在IDE里对HashMap和ConcurrentHashMap设置断点，触发resize和treeifyBin，记录每一行执行的时间，统计10次平均的耗时差。2.在JMH里测一下AtomicLong和LongAdder在16、64、256线程下的吞吐，给出每种线程数的ops/s，至少跑3轮预热2秒，测量5秒。3.写一个小工具方法，输入QPS和平均耗时，输出线程池推荐参数和队列长度，给出2个拒绝策略模拟结果。这些动作都能在两小时内完成。很具体。三、踩坑：里那些阴沟翻船真正的坑在路上。一个周五的晚上，我把CopyOnWriteArrayList用到了错误的地方，第二天凌晨就被报警电话吵醒。手机显示02:17。杭州余杭的数据机房，监控服务的接口95线超过800ms，平时是120ms左右。我和同事小陈连夜排查，定位到我们引入CopyOnWriteArrayList的那段代码每次修改都复制数组，凌晨2点半，批量任务集中触发，10分钟内发生了312次写。我原以为写很少。错估了1个数量级。我挨了领导一记白眼。心虚。这是一个教训，也是一个面试里的高频陷阱。要点是CopyOnWriteArrayList读快写慢，且迭代器不受写影响，是弱一致性；但在需要频繁写或者对象很大时，会造成大量内存复制和短时停顿。例题改成了面试版：“一个读多写少的配置表，可能在某些时段写会集中爆发，适不适合用COW，怎么规避？”解题思路是用AtomicReference+不可变对象或基于Map的版本切换来避免全量复制；或者在并发不高情况下用读写锁ReentrantReadWriteLock，读锁共享写锁独占；再不济也可以把写合并，批量更新。最后加一个数据判断：如果每分钟写超过50次且数组大小超过10000，COW就不合适。我当时没有这个判断。吃亏了。另一个坑来自double-checkedlocking。很多人会说“加volatile就好了”。我在一个配置单例里真的这么干了。半年后，在8台机器里有1台偶发NPE，发生概率大概0.2%，每次都在凌晨部署后的5分钟内。我们排查了两天，最后定位是另一个字段没有在构造里初始化完全，被另一个线程看到一个“部分构造”的对象。准确说不是“没加volatile”，而是“构造逃逸与发布时机导致的可见性问题”。面试里如果只背“volatile有序性与可见性”，很容易说空话。要用例子说服人。我学到了。要点我总结成“happens-before清单”。像锁的解锁先行发生于同一锁的后续加锁，volatile的写先行于读，线程启动先行于线程中的操作，线程终止先行于join返回。这些句子我在纸上写了8条。例题是：“为什么双重校验要把INSTANCE设为volatile，能不能只把constructor内的字段设为volatile？”解题思路是从指令重排与可见性说起，解释new的三个步骤：分配内存、初始化、引用赋值，重排会把引用赋值提前，另一个线程可能读到未初始化完全的实例，volatile阻止了这一步的重排，但不能保证构造内部的发布安全，所以构造里不要泄露this。最后建议把复杂初始化放到静态内部类的Holder或者用枚举单例。这比背定义有用。更靠谱。还有线程池踩过的坑。我曾经用CallerRunsPolicy作为拒绝策略，觉得“被拒绝了就让调用线程执行，能自然限流”。结果线上一个接口P99从120ms飙到了1.2s，业务线程被迫干了本不该干的活，整个请求链拉长，级联放大。那次复盘我写了一行话：“拒绝策略不是性能工具，是最后一道安全阀。”这句话后来也出现在我面试时的回答里，面试官听到后笑了一下。我心里也笑了。侥幸。多线程的幽灵还藏在falsesharing。我们有个热点计数器用到了AtomicLong数组，32个线程同时加一，吞吐卡在70万ops/s上不去。我把结构换成了LongAdder，吞吐到了180万ops/s，又加了缓存行填充（用Contended或手工填充），到了220万ops/s。提升超过200%。我把这个数据写进了我的“故事本”，因为这类“数字+动作”的答案，面试官一般爱听。它具体。它可信。我也记录了一次失败案例，到今天还历历在目。去年7月23日下午，深圳南山科技园3号楼14层，面试一个岗，面试官姓林，戴着黑色运动表，问我：“ConcurrentHashMap的size操作是否准确，JDK8怎么做？”我脱口而出“baseCount+CounterCells求和，近似值”，他说“那在并发很高时会不会偏差很大？”我说“不至于”，他让举数字。我说“应该在5%以内吧”。他摇头，说“我们线上见过12%的偏差，在128线程夸张情境下”。我无言。那天我挂了。我回酒店写了一行感想：“少见不代表不存在。”这句后来成了我改答案时的提醒。为了不再翻车，我给每个坑配了操作步骤。1.对CopyOnWriteArrayList这类结构，预估写入频次和对象大小，超过某阈值立即换策略，阈值有两个：每分钟写超过50次、单个元素超过4KB。2.对double-checked，禁止构造函数里调用可被重写的方法，禁止把this传给外部；尽量用Holder或枚举单例。3.对线程池的拒绝策略，先在压测里模拟1.5倍、2倍流量，统计P95和P99的变化，再决定选哪个策略，不凭感觉。这些都是“可执行”的，写在日历里就能做。四、解决：把高频知识点练成手感与数据那次面试之后的第三周，我开始把每个“Java面试高频”的题目变成手上的肌肉。我决定做一个小而完整的复现项目，从集合到并发，一套一套地过，像练琴一样。每天90分钟。定时器一响就收工。简单。我先把“面试三连”的集合题打磨成三段话和三幅图。第一段讲ArrayList的扩容。要点是初始容量为10（JDK8里第一次add才分配），扩容策略是newCapacity=old+(old>>1)，当newCapacity小于minCapacity时取minCapacity，确保容纳；ensureCapacity可以提前扩大，减少扩容次数。例题我把它改成一道“算数题”：初始容量10，按顺序add100个元素，中途发生几次扩容，每次的容量变更是多少。解题思路是按10、15、22、33、49、73、109……写出来，用3行公式演示扩容点和确保机制，最后给出次数大约是7次。再补一句“对于小集合，最好提前指定容量，减少扩容”。这一段我能在面试里用不到60秒讲清。速度够快。第二段讲HashMap的寻址和树化。要点我压缩成两句话：哈希扰动降低碰撞，索引定位是(n-1)&hash；当链表长度超过8且数组容量至少64时树化，低于6时退化。例题我挑了“碰撞演示”：给出两个key，它们的hashcode不同，但扰动后落在同一桶，如何构造。解题思路是自己写一个Key类型，重写hashCode返回一个固定值，比如42，再补充equals区分不同key，从而演示碰撞与树化触发条件，顺便谈谈红黑树的左旋右旋对查找的影响近似O(logn)。面试官爱看这种“手写key的恶作剧”。有趣。好记。第三段是LinkedHashMap的LRU。要点我交代清楚：accessOrder=true的时候，访问会改变双向链表的顺序；重写removeEldestEntry可以在put后判断是否淘汰，返回true则删除头部元素。例题是“固定1000容量的LRU缓存，命中率目标85%，访问分布80/20”，给出构造参数初始容量设置为1280，负载因子用0.75，保证阈值大于1000，避免频繁resize，最后在put后按规则移除。解题思路除了代码，还补充了一个数据：我们线上7天滚动数据里，命中率从76%提高到了86%，接口平均耗时从23ms降到了17ms，日均节省18%的下游调用。数字落地。心里踏实。多线程部分，我挑了四个杠杆点。要点一是ThreadPoolExecutor的参数联动。例题还是那个“QPS突刺”，但我把解题变成“先算后选”。解题思路：1.先估算并行度N=QPS×RT≈3000×0.05=150，保守用0.8系数，120左右。2.用corePoolSize取16或32，最大线程根据CPU和阻塞程度调高到64，队列设置为200或500，拒绝用DiscardOldestPolicy，以去掉旧请求。3.用压测数据验证3组参数，记录被拒绝比例、P95、CPU利用率，选择被拒绝低于3%且P95不超过2倍基线的一组。这不是拍脑袋，是算和测。我后来在面试里直接把150这个数字写在白板上，面试官很满意。看得懂。要点二是CompletableFuture的组合陷阱。例题是“5个子任务里有2个异常，allOf会不会立刻失败，如何最快返回成功的一个”。解题思路是anyOf可以最快返回一个，但如果要汇聚结果，需要对每个future调用handle并捕捉异常，最后汇总成功的那部分；allOf的异常需要在join时统一爆出，或者用whenComplete记录异常信息，不能指望allOf直接抛。再讲一个数字：在8线程池下，每个80ms的任务，5个并行，allOf总时间在85-100ms之间，异常的两个不会拖慢整体；如果用单线程，时间就到400ms以上。直观。要点三是锁的公平性与可重入性。例题是“用ReentrantLock做限流，为什么不建议开公平锁？”解题思路：公平锁会让线程排队，吞吐下降，性能在32线程下可能低10-20%，而且容易造成上下文切换增加；非公平锁可以插队，提高吞吐但可能造成个别线程饥饿，实际业务常选非公平，再用超时tryLock和近期等待做兜底。讲完我给了一个线上数字：去年9月我们把公平锁换成非公平锁，P99降了18%，上下文切换从每秒4.2万降到2.7万。我给面试官看了截图。他点头。要点四是LongAdder和AtomicLong的适用面。例题是“统计QPS，用哪个更合适，为什么？”解题思路：LongAdder在高并发下有更高吞吐，通过分段累加减少竞争，但读取是分段求和，瞬时读可能有轻微延迟；AtomicLongCAS在高竞争下自旋失败率高，吞吐下降。用JMH给数据：在64线程，AtomicLong增加吞吐大约60万ops/s，LongAdder有180万ops/s；在4线程，差距不大。我准备了一个小图表，面试时只口述数字。足够了。我还做了一个小实验来解决“fail-fast与fail-safe”的口播卡壳问题。把ArrayList遍历时add放入口，立刻抛ConcurrentModificationException；把CopyOnWriteArrayList做同样操作，遍历不抛，但新元素不出现在当前迭代中。这个对比实验我跑了5次，每次都在10ms内看到相同行为。我把这句话练了十遍，保证能在30秒内说清。练到顺。有效。那一周，我给自己定的操作步骤如下。1.每天背两个“要点+例题+解题思路”的三件套，晚上用手机录音，自测不超过90秒能讲完。2.每天跑一个最小实验，把数据写在卡片上，比如“队列1000时，拒绝比例27%”。3.每天给一个同事复述一个知识点，接受他打断提问至少2次，晚上复盘补漏。这些步骤有点笨，但我发现命中率从60%提到85%。质变来自量变。真是这样。五、复盘：把变成日常习惯三个月后，也就是今年一月，我又去面了两家。第一家在上海张江，会议室玻璃擦得很干净，我被问到了“HashMap树化的边界”和“线程池队列为什么不建议用无界”。我在白板上用了2分钟把树化阈值和数组容量64的条件讲了，把一段并发下链表和树的插入时序画清楚；又用了1分钟把线程池的积压模型算了一遍，给了“在6000QPS的突刺里，队列1000半秒打满”的数字。面试官点点头，说“我们这边更看重能把数据说出来的人”。这句话我抄在了本子上。很受用。第二家的问题更偏实战。问我“ConcurrentHashMapsize的准确性”和“ForkJoinPool的工作窃取机制”。我回答size的近似性，提到了baseCount与cells的合计，提到了一次在128线程下12%的偏差案例，就那个我在深圳被教育过的数字；又用一个8行的口述解释了工作窃取：每个工作队列是双端队列，其他线程从队尾窃取任务，减少竞争，适合递归分治。最后给了公平性不是强保证，以及窃取也有代价的补充。这个回答让我拿到了offer。据说是因为我提了“12%”这个数字。细节救命。回头看，我觉得最难的不是知识的多少，而是把它们和真实场景绑在一起，用数字验证，用步骤实现。那种“说人话”的面试表达，说的不是术语，是“这件事在23点10分发生了18次，每次300ms，原因是队列打满导致CallerRunsPolicy牵连”。面试官听得懂。你也能讲得出去。你别怕。有人问我“你是不是背了很多答案”。我说：“有，但不只是背。”我把每个答案都过了一遍手上的实验和数字，至少2组数据，至少1次白板演示，至少1次被同事打断。最后我把这些东西合成了一份图谱。图谱像地铁图一样，从集合出发，分出HashMap、ArrayList、LinkedHashMap、ConcurrentHashMap的站，再向并发延伸出synchronized、ReentrantLock、ThreadPoolExecutor、CompletableFuture、LongAdder的线路，交汇点就是那些“Java面试高频”的口子。站点之间有换乘。路线清晰。这里我把我最后的“复盘题库”再示范几条，依然是要点、例题与思路，方便你今晚开始动手。集合方向的复盘题之一。要点是HashMap的扩容条件与负载因子交互。例题：“容量16，负载因子0.75，什么时候触发扩容，扩到多少。”解题思路：threshold=16×0.75=12，插入第13个元素时触发扩容，新容量32，新阈值24；若提前ensureCapacity(100)，则直接调整容量，避免多次扩容。给一个操作建议：不确定元素数量时，按预估大小的1.5倍作为初始容量。集合方向的复盘题之二。要点是ConcurrentHashMap