秋招季的Java笔试题，很多同学都在找往年真题练手，尤其是途虎养车这种“互联网+汽车后市场”赛道的头部公司，它的笔试题目很能代表一类中等偏上体量互联网企业的出题风格和水准。我拿到了2023秋招Java笔试试卷B的完整回忆版本，结合自己多年Java开发和面试官经验，把这张卷子里埋的考点、坑点、踩分点逐题拆一遍。这篇文章不是简单对答案，而是讲清楚每道题背后考官到底想考什么、怎么答才能拿高分、哪些地方最容易翻车。
每年都有大量候选人挂在看起来“很基础”的题目上，不是因为不会，而是因为只背了结论、没懂原理。途虎这套试卷B整体难度中等偏上，考察面覆盖Java基础、集合源码、并发编程、JVM、Spring Boot、MySQL、Redis、分布式场景，风格上非常典型：基础题考深度、框架题考原理、场景题考设计思路。如果你正在准备秋招，或者打算跳槽到电商、出行、汽车后市场这类业务型互联网公司，这套题值得认真过一遍。
1. 试卷整体画像：不从题海战术出发，先看懂出题人的技术底牌
1.1 从题型分布反推考察重点
途虎的试卷B整体分为四个部分：单选与判断题、多选题、编程题、场景设计题。前两部分覆盖的知识点极为密集，几乎每个Java核心模块都露了一面；编程题以数据结构和算法为主，难度约等于LeetCode中等偏下；场景设计题则直接对标途虎的“线上下单+线下门店服务”业务模型，考察候选人在真实业务里做技术选型和架构设计的能力。
这里有一个很有意思的信号：整套卷子里几乎没有出现“背概念”式的题目，比如“什么是面向对象”这种开放式问题，而是全部换成了“给一段代码判断输出”“给一个场景选择最优方案”这类需要现场推理的题目。这说明出题人默认你已经掌握了基本概念，他要考察的是你在有干扰项、有约束条件时能不能做对技术判断。这个思路和阿里、美团、京东的校招笔试是一脉相承的。
1.2 途虎技术栈画像：为什么考这些不考那些
结合途虎养车的业务特点来分析考点选择，会发现一条清晰的逻辑线。途虎的核心业务是汽车养护电商平台，涉及商品交易、订单履约、库存调度、门店匹配、物流追踪，底层还需要处理海量的车辆数据和用户行为数据。因此它的后端技术栈大概率是标准的Spring Cloud或Dubbo微服务体系，配上MySQL、Redis、RocketMQ或Kafka、ElasticSearch这套组合。
明白了这一点，再来回看试卷B的考点分布，就很容易理解出题人的意图了：集合框架考的是你的日常编码功底；并发编程考的是你在高并发订单场景下能不能写出线程安全的代码；JVM考的是你遇到线上内存溢出时有没有排查思路；Spring Boot考的是你对框架原理有没有深入到底层，而不是只会用注解；MySQL和Redis则直接对应途虎订单、库存、缓存这几条核心链路。
所以准备这套试卷，刷题只是最表层的工作。真正有效的复习方式，是把每一道题都映射回一个真实业务场景，问自己“如果我在途虎负责订单服务，这个问题会以什么形式出现在线上”，这样理解深度完全不同。
2. Java基础模块：送分题与送命题之间只差一个“为什么”
2.1 面向对象与语法糖：考官真正在意的三个细节
试卷B的基础部分有一道典型的面向对象题目，给出一段涉及继承、静态方法重写、构造器执行顺序的代码，要求判断输出结果。这类题考察的不是“你知不知道Java支持单继承”，而是三个容易忽略的细节：静态方法属于类不属于实例，因此不存在重写只有隐藏；子类构造器会隐式调用父类无参构造器，除非显式用super指定；字段的初始化顺序是父类静态块、子类静态块、父类实例块、父类构造器、子类实例块、子类构造器。
还有一道关于Lambda表达式的题目，看起来是在考语法，实际上考的是“变量捕获”（variable capture）。题目问下面的代码能否编译通过：
int count = 0; Runnable r = () -> System.out.println(count); count++;答案是不能编译。原因是Lambda表达式捕获的局部变量必须是final或等效final的，因为Java设计者为了保证线程安全，不允许Lambda及其外部作用域同时修改同一个局部变量。很多同学在这里丢分，不是不知道这个规定，而是没有意识到count++已经让变量不再“等效final”了。
试卷中还考了枚举类型（Enum）的使用，不要以为枚举只是用来定义常量的。真实的考点在于：枚举可以拥有成员变量、构造器和抽象方法；枚举的构造器默认是private的；枚举可以实现接口但不能继承类。如果题目再深挖一层，可能会问EnumMap和EnumSet为什么在性能上优于HashMap和HashSet——答案在于枚举的ordinal值可以直接作为数组下标或位向量索引，省去了哈希计算的开销。
2.2 集合框架：从“用对API”到“读得懂源码”
集合这部分的题目分量很重，覆盖了ArrayList、HashMap、ConcurrentHashMap、TreeMap和链表相关操作，每一道都值得认真拆解。
关于HashMap，试卷B至少出了两题，一题考扩容机制，一题考put流程。很多同学能背出“默认容量16，负载因子0.75，树化阈值8”，但题目一旦拐个弯就懵了。比如这道：HashMap<String, Integer> map = new HashMap<>(10);实际创建的容量是多少？答案不是10，而是16。因为HashMap会调用tableSizeFor方法，把传入的初始容量向上取整为2的幂次方，10会变成16。这道题考察的就是你对源码细节是否真正读过，而不是只看过面经里的结论。
还有一个高频变体题：如果自定义对象作为HashMap的key，会发生什么？标准答案是要重写equals和hashCode，但考官的进阶问题往往是：只重写equals不重写hashCode会怎样？答案是两个相等的对象会落到不同的桶里，get的时候永远查不到——因为get会用key的hashCode定位桶。那反过来只重写hashCode不重写equals呢？会定位到同一个桶，但比较时equals返回false，导致该key无法命中已有value。这两个方向都要理解透彻。
集合部分还有一道关于fail-fast机制的题，考察ConcurrentModificationException的产生原理。面试官想听的不是“不要在遍历时修改集合”这个结论，而是modCount字段的存在意义——它是ArrayList、HashMap等集合内部用来记录结构性修改次数的标记，迭代器每次调用next()都会校验modCount是否和预期值一致，不一致就抛异常。但有趣的是，如果你用iterator.remove()而不是list.remove()来删除元素，就不会触发这个异常，因为迭代器内部的remove会同步更新expectedModCount。
2.3 异常与OutOfMemoryError：把内存问题讲出排查思路才算过关
试卷B在异常处理这块考了一道很贴近实战的题，围绕OutOfMemoryError展开，热词搜索里也出现了java: outofmemoryerror: insufficient memory这个关键字，说明这是很多同学实际编码中踩过的坑。OOM在Java里面是一个Error而不是Exception，它表示JVM内存资源已经耗尽，程序通常无法自主恢复。
题目可能会这样问：下列哪种情况不会抛出OutOfMemoryError？备选项包括堆内存不足、栈溢出、元空间不足、线程过多导致无法创建本地线程。这里有一个经典误区：StackOverflowError和OutOfMemoryError虽然都是VirtualMachineError的子类，但产生机制完全不同。栈溢出是递归调用过深导致的，OOM是内存分配不出来导致的，不能混为一谈。
更高阶的考法，是给出一段代码问“以下哪种方式可以解决这个OOM”，选项包括加大堆内存、减少对象创建、检查是否有内存泄漏、改用软引用缓存。这道题没有标准答案，因为OOM的“解法”完全看场景。正确的答题思路是先分类：如果是堆内存OOM，优先排查是否存在内存泄漏，用MAT或JProfiler分析堆转储文件；如果确认没有泄漏，才考虑增大-Xmx参数；如果是大量缓存导致的OOM，可以考虑把强引用改成软引用或弱引用。
我在实际面试中见过太多候选人把“处理OOM”笼统地说成“调大堆内存”，这本质上暴露了两个问题：一是没有线上排查OOM的实际经验，二是对垃圾回收机制的理解停留在表面。调大堆内存只是临时止血，如果对象本身无法被回收，你调多大都没有用，反而可能因为GC停顿时间过长导致更严重的服务不可用。
3. 并发编程与JVM：笔试中的分水岭，拉开差距的关键战场
3.1 线程池与AQS：七个参数背后的设计哲学
并发部分最核心的题目仍集中在ThreadPoolExecutor上。试卷B出了一道参数计算题：核心线程数设置多少合适？对于CPU密集型任务和IO密集型任务，业界推荐的参考值分别是CPU核心数+1和CPU核心数 * 2（或者CPU核数 / (1 - 阻塞系数)），但题目往往不会直接考公式，而是给一段配置让你判断哪个参数配错了。比如核心线程数设置为0，会发生什么？答案是线程池在任务到达后先放入队列，队列满后再创建线程执行任务，这会导致任务延迟明显增加。
另一个高频考点是拒绝策略。AbortPolicy、CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy四种策略的适用场景要烂熟于心。试卷B大概率会考CallerRunsPolicy——当线程池和队列都满了，新任务不会丢弃，而是提交任务的线程自己来运行任务。这种策略保证了任务不丢失，但代价是提交任务的入口线程会被阻塞，进而反向压上游，形成天然的背压机制。这在设计MQ消费者或异步批处理场景时非常实用。
AQS（AbstractQueuedSynchronizer）是Java并发包的基石，也是大厂笔试的常客。如果题目问“ReentrantLock和synchronized的区别”，很多同学能列出十点不同，但如果限定“从AQS的角度解释ReentrantLock如何实现公平锁和非公平锁”，就考验真功夫了。非公平锁的lock()会先执行一次compareAndSetState(0, 1)，如果成功就直接拿到锁，区别于公平锁必须先查看AQS等待队列中是否有前驱节点，有则排队。这个“先插队，插队失败再排队”的机制，正是公平与非公平的本质差异。
3.2 JVM内存区域与GC：两道经典题必须形成肌肉记忆
JVM部分，试卷B考察了运行时数据区域划分和垃圾回收算法。运行时数据区域这道题很经典：程序计数器、虚拟机栈、本地方法栈、堆、方法区（元空间）各存什么。很多同学把方法区的“存类信息、常量、静态变量”和堆的“存实例对象”背得很熟，却忽略了一个高频易错点：字符串常量池在JDK 7以后已经移到了堆中。如果在老版本中学习过，必须更新这个认知，JDK 8取消了永久代，方法区改由元空间实现，而元空间使用的是本地内存。
GC算法的题目通常会和实际调优场景绑定。卷子里有一道关于Minor GC和Full GC的判断题：什么时候会触发Full GC？答案是老年代空间不足、元空间不足、System.gc()显式调用、大对象直接进入老年代导致晋升失败等。但考官通常不会只问触发条件，还会延伸问“CMS和G1有什么区别，为什么G1能控制停顿时间”。这里要答到G1通过将堆划分为多个Region，并维护一个可预测的停顿时间模型，在回收时优先回收价值最大的Region，而不是像CMS那样全堆扫描。
我还想强调一个容易被忽略的考点：内存屏障与JMM（Java内存模型）。如果试卷里出现“volatile能保证什么，不能保证什么”，标准答案是保证可见性和有序性，不保证原子性。但如果你想拿高分，一定要补充：volatile通过插入内存屏障指令（LoadLoad、LoadStore、StoreLoad、StoreStore）来禁止指令重排序，从而保证其在单次读写场景下的线程安全。这里可以顺带提一句“DCL（双重检查锁）单例为什么需要用volatile修饰instance字段”，因为instance = new Singleton()不是一个原子操作，可能发生指令重排导致另一个线程拿到未初始化完成的对象。
4. Spring Boot与MySQL：项目经验在这里被“验货”
4.1 Spring Boot自动装配：从“跑通demo”到“看懂启动流程”
Spring Boot部分的考题，基本绕不开自动装配和启动流程。试卷B常考的一题是@SpringBootApplication注解由哪几个注解组合而成，答案是@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan，前两个又分别由@Configuration和@Import(AutoConfigurationImportSelector.class)派生。
考官真正的进阶问题，是让你解释AutoConfigurationImportSelector是如何工作的。完整的回答链路是：Spring Boot启动时，@EnableAutoConfiguration会导入AutoConfigurationImportSelector；这个Selector会扫描所有jar包下的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件（新版本路径，老版本是spring.factories）；然后通过@Conditional系列注解做条件装配，比如@ConditionalOnClass判断类是否存在、@ConditionalOnMissingBean判断容器中是否已有Bean。整套机制的核心思想是“约定大于配置”，把繁琐的配置工作交给框架自动完成。
试卷B还有一道关于Spring Bean作用域的题：singleton、prototype、request、session四种作用域的区别。难点在于结合Spring MVC的实际情况分析：controller默认是单例的，在多线程高并发环境下会不会有线程安全问题？答案是如果controller中定义了可变的成员变量，就会有并发问题，因此无状态的Bean在单例模式下是线程安全的，有状态的Bean需要谨慎处理。最佳实践是将依赖注入为成员变量，但把业务变量放在方法内部，避免跨线程共享。
4.2 MySQL索引与事务隔离级别：一道题问出五个层次
数据库是途虎这类业务型公司笔试的重中之重。试卷B关于索引的选择题非常典型：在(user_id, order_time, status)这个复合索引下，查询条件为where status = 'PAID' and user_id = 123，是否能走索引？如果能走，走的是哪个部分？这里的关键知识点是复合索引的“最左前缀原则”，索引从最左列开始匹配，查询条件中包含user_id就能命中索引，匹配的索引列是user_id这一列，status虽然也在查询条件里，但由于复合索引的匹配顺序，需要中间列order_time连续不断档，status才能参与索引匹配。
再深入一点，考官还会问覆盖索引和回表的区别。如果查询的列恰好都包含在索引列中，就不需要回表，直接返回索引中的数据即可，这是覆盖索引；如果需要查询索引中没有的列，就要通过主键回表查询，多一次磁盘IO。为了优化这类查询，通常会使用“索引下推”（Index Condition Pushdown），在存储引擎层直接过滤掉不符合条件的记录，减少回表次数。
事务隔离级别也是一定会考的。读未提交、读已提交、可重复读、串行化四级隔离级别层层递进，MySQL默认是可重复读。题目大概率会问：为什么MySQL选择可重复读作为默认级别？在RR级别下，InnoDB如何通过MVCC解决幻读问题？答案是REPEATABLE READ配合next-key lock（记录锁+间隙锁），在RR级别下就已经能解决绝大多数幻读场景。MySQL之所以默认用RR，是因为其主从复制在statement格式下依赖RR的间隙锁才能保证数据一致性，而在Oracle中默认是RC级别。这个细节很少被教科书提到，但面试官很喜欢听。
事务的ACID属性是送分题，但部分同学会混淆“持久性”和“原子性”。原子性是“要么全做，要么全不做”，持久性是“事务一旦提交，结果永久有效”。如果题目问“InnoDB如何保证持久性”，答案是redo log（重做日志），在事务提交时将redo log刷盘（可以通过innodb_flush_log_at_trx_commit参数控制刷盘策略），即使数据库崩溃，重启后也能通过重放redo log恢复已提交事务的数据。
5. Redis与分布式场景：从“会用”到“会设计”的跨越
5.1 缓存穿透、击穿、雪崩：不只背方案，还要理解取舍
Redis部分的考题高度集中在缓存三大经典问题上：缓存穿透、缓存击穿、缓存雪崩。试卷B很可能以选择题形式出现，要求为每个场景匹配正确的解决方案，但你必须准备好应对多选甚至扩展题。
缓存穿透是查询一个根本不存在的数据，请求直接打到数据库，此时缓存中也没有这个key，所以每次都要查库。一个典型的防御方案是布隆过滤器，在缓存前加一道过滤，将可能存在的数据key写入布隆过滤器，不存在的key直接被拦截。但布隆过滤器有误判率，且不支持删除操作，更简单的方案是“缓存空值”，将不存在的key也缓存起来，设置较短的过期时间，比如30到60秒。两种方案各有取舍：布隆过滤器节省内存但复杂，缓存空值简单但可能存储大量无效key。
缓存击穿是某一个热点key在过期瞬间，大量请求同时打到数据库。解决方案有两个方向：一是用互斥锁（SETNX）保证只有一个线程去重建缓存，其他线程等待；二是过期时间不设置固定值，而是在value中写入逻辑过期时间，后台异步任务刷新缓存。前者实现简单但会有短暂阻塞，后者性能好但实现复杂。实际项目中，我更推荐先评估热点key的数量级，如果热点key不多，用互斥锁完全够用。
缓存雪崩是指大量key同时失效，或者Redis节点宕机，导致请求全部打到数据库。应对方案包括给过期时间加随机值，打散失效时间；使用Redis哨兵或集群模式保证高可用；对数据库做限流降级，比如使用Sentinel或Hystrix做熔断保护。这里有一个容易被忽视的点：即使Redis挂了，也不能让数据库裸奔。好的设计是缓存与数据库之间有多层保护，比如本地缓存（Caffeine）做一级缓存，Redis做二级缓存，数据库做最后一道防线。
5.2 分布式锁与消息队列：场景题里最亮的考点
分布式锁是微服务面试的必修课，也是途虎这类订单系统的刚需。试卷B场景题很可能会这样出：下单时要对用户ID加锁，防止重复提交订单，如何实现？最朴素的答案是synchronized，但它在多实例部署下完全无效，因为锁是JVM级别的。正确思路是用Redis的SET key value NX EX命令实现分布式锁，key是用户ID，value是请求唯一标识，NX保证同一时刻只有一个请求能拿到锁，EX设置锁的超时时间，避免死锁。
但只答到这个深度还不够。优秀的候选人会主动补充两个细节：锁的value必须设为一个唯一标识，释放锁时用Lua脚本先比较value再删除key，防止误删其他线程的锁；锁的超时时间需要根据业务执行时间来设置，同时可以在一个异步线程中做锁续期（看门狗机制），防止业务还没执行完锁就过期释放了。如果现场时间允许，还可以提一句Redisson，它是Redis官方推荐的Java客户端，其内置的RLock已经实现了自动续期。
消息队列部分，途虎这种电商属性强的公司，必然考察Kafka或RocketMQ的可靠性与顺序性。题目常问：如何保证消息不丢失？要从三个角色维度回答——生产者端通过acks=all确认消息全部写入副本才算成功；Broker端通过min.insync.replicas参数确保至少有一个副本写入成功；消费者端在处理完业务逻辑后再手动提交偏移量，禁止自动提交。三者缺一不可。
6. 算法与场景设计题：笔试收尾的拉分项
6.1 高频算法题的保守打法
试卷B的编程题部分，按照经验大概率会覆盖字符串处理、链表操作和排序算法。冒泡排序、快速排序这类基础排序是搜索热词里的高频关联词，说明不少同学还在用它们入门。但笔试中纯考排序的概率不高，更常见的是考“变体”，比如“按照出现频率对字符排序”或“对两个有序链表合并”这类需要你灵活运用排序思想的题目。
快速排序是必须刻进肌肉记忆的算法。它采用分治思想，选择一个基准元素，将数组分成小于基准和大于基准的两部分，然后递归处理左右子数组。在Java中，Arrays.sort()对基本类型使用的是双轴快速排序（Dual-Pivot QuickSort），对引用类型使用的是TimSort。如果你能在笔试中解释清楚快排的最坏时间复杂度是O(n²)、平均是O(n log n)，以及如何通过随机化基准元素避免最坏情况，就已经比大多数候选人高出一档了。
题量方面，途虎的编程题一般不止一道，需要合理分配时间。我建议先做有把握的暴力解法，保证正确性，再在剩余时间内优化。比如看到“数组中的第K个最大元素”，最直接的解法是排序后取下标，时间O(n log n)；进一步可以用小顶堆，时间O(n log K)；再进一步可以用快速选择算法，平均O(n)。考场上能写出哪种写法就拿哪种分，没有AC但思路正确的代码，面试官也会给分。
6.2 场景设计题的答题框架：不靠灵光乍现，靠结构化表达
场景设计题是试卷B中区分度最高的一部分，也是我最建议认真准备的部分。往年真题方向包括“如何设计一个保养订单状态流转系统”“如何实现门店库存的实时扣减”“如何设计一个用户爱车档案系统”，这类题目没有标准答案，但有一个通用的答题框架可以套用。
第一步，澄清需求。不要急着写代码，先和出题人在脑中对话：这个系统的核心流程是什么？数据量级多大？对实时性的要求如何？比如抽奖系统，一台车的保养记录可能有几百条，但订单状态变更的并发量可能高峰上千QPS，这些关键指标决定了后续的技术选型。
第二步，数据模型设计。用最少的表描述清楚核心实体和关系。比如订单状态流转系统，核心表就三张：订单表、订单状态变更流水表、状态机配置表。流水表记录每一次状态变更的轨迹，状态机配置表定义“当前状态+事件=下个状态”的映射关系，这比在代码里写一大堆if-else清晰得多。
第三步，接口设计。定义关键接口的输入输出，以及核心流程的交互时序。比如“用户下单”接口内部要依次完成：查询门店可预约时间、锁定库存、创建订单、发送MQ消息、通知门店小程序等，每一步都要说清楚是同步还是异步，失败如何补偿。
第四步，可用性与一致性保障。这一步是拿分关键。强调通过事务保证订单主流程的一致性；通过本地消息表实现最终一致性；通过Redis分布式锁防重；通过设置状态机表防止非法跳转。整段答题过程中，始终使用途虎的业务场景来举例，会显得非常扎实且贴合。
7. 复盘与实战建议：考完试，真正的学习才刚刚开始
7.1 无论分数如何，先做一份考点自查表
做完试卷B之后，我强烈建议你拿出一张纸，把卷子里出现过的知识点全部列出来，然后逐个标注“掌握”“模糊”“不会”三档。我帮你回忆一下这套卷子的核心考点清单，以方便对照：Java基础部分，包括面向对象、Lambda、枚举、异常、泛型；集合部分，包括HashMap、ArrayList、迭代器fail-fast机制；并发部分，包括ThreadPoolExecutor、AQS、volatile、synchronized；JVM部分，包括内存区域、GC算法、OOM排查；Spring Boot部分，包括自动装配、Bean生命周期、事务注解；MySQL部分，包括索引、事务隔离级别、redo log、间隙锁；Redis部分，包括缓存穿透/击穿/雪崩、分布式锁、过期策略；消息队列部分，包括可靠性、顺序性、幂等。
表格上标注“模糊”的，就是接下来一周的优先级最高的复习对象。不要贪多，一天解决一个模糊点，比一天刷100道题有效得多。我见过太多候选人收藏了一堆面试题汇总，到最后都是收藏夹里吃灰，真正内化的知识少得可怜。
7.2 三个备考方向上的细节建议
第一，代码填空题要动手敲。笔试中经常出现“补全代码”的题目，比如让你实现一个线程安全的单例、写一个二分查找。很多同学眼睛看会了，一动手就各种语法错误。我的建议是备考期间不要用IDE的自动补全，直接在力扣的模拟环境或简单文本编辑器里练，模拟笔试现场的手感。
第二，八股文不能只背结论。针对“Java面试八股文”这类资料，必须做到每个结论能讲出“为什么”。比如“HashMap线程不安全”，你要能说出线程不安全具体体现在哪里：并发put可能导致数据覆盖，扩容期间可能出现环形链表（JDK 7），在JDK 8中可能造成数据丢失。只会背结论而不知道原因，面试官一旦追问就会露馅。
第三，多关注汽车后市场领域的业务特点。如果你投的是途虎，笔试之后大概率还有技术面。面试官很可能会问：保养订单和普通电商订单有什么区别？这时候可以提前准备几个角度：订单生命周期更长，可能跨越数月；涉及线下服务履约，需要预约和门店调度；商品与SKU绑定复杂，比如不同车型对应不同机油滤芯；售后流程重，需要追溯车辆档案。能把这些业务理解融入到技术方案中的人，面试评价会明显不一样。
最后，我自己在带校招生和做面试官的时候有一个观察：笔试成绩好的人，不一定是刷题最多的人，但一定是善于归类、善于总结、善于把知识串成网络的人。途虎试卷B考的这些点，没有一个是超纲的，但每个点都可以无限深挖。你能挖到第几层，决定了你在候选人中的位置。
