这两年秋招笔试我是真没少刷各大厂的卷子基本都见过一遍。途虎养车这套2023秋招Java笔试试卷B在牛客和脉脉上被讨论的频次不低。它不算那种硬核到劝退的题库但胜在覆盖面完整Java基础、JVM、并发、Spring生态、MySQL、Redis、算法编程甚至还有结合业务场景的设计题几乎把互联网公司后端Java岗的核心考点全部囊括进去了。不管你是准备投途虎还是想拿这套卷子当模拟题练手我都建议认真过一遍。这篇文章不打算逐题贴答案而是把试卷B背后真正想要考察的能力模型拆给你看顺便把答题时容易踩的坑、准备时容易被忽视的点都梳理出来希望能帮你少走弯路。1. 试卷B的定位途虎秋招笔试到底想筛什么样的人1.1 途虎的业务形态决定了考点方向先聊一个很多人忽略的问题为什么这套卷子的考点长这样途虎养车本质上是汽车后市场的在线服务平台线上有商城、预约、会员系统线下有大量直营和加盟门店背后还连着一整套供应链、库存、订单、支付、物流体系。这种业务形态决定了它招的Java工程师不是去写底层框架或中间件的而是做业务系统的——也就是大量订单流、库存流、会员流的高并发读写、数据一致性、缓存设计、消息异步处理。所以你看试卷B它不会考你怎么实现一个JVM、怎么从零写一个RPC框架而是重点考察这些内容Java基础是否扎实能不能写出健壮的代码有没有处理过并发、内存这类真实生产问题对Spring Boot这类主流框架的原理理解到不到位会不会用MySQL索引、事务、Redis缓存解决实际业务问题能不能在白板/在线编辑器里快速写出一道中等难度的算法题。说得直白点这套卷子筛选的是能干活、能扛事、基础没硬伤的后台业务开发而不是纯粹的算法竞赛选手或者框架调包侠。1.2 题量、题型与分值结构参考据我拿到试卷B的同学反馈和自己的刷题印象这套卷子的题型大致是题型大致占比考察内容单选题/多选题25%-35%Java语法、集合、异常、面向对象概念判断题5%-10%容易混淆的细节知识点简答题15%-20%JVM内存、垃圾回收、线程池、数据库事务等SQL/数据库题10%-15%索引设计、SQL编写、事务隔离级别编程题20%左右排序、链表、字符串处理、中等难度LeetCode场景设计题10%左右订单超时、库存扣减、缓存雪崩等业务问题这个结构有一个很现实的意义它决定你答不完也能过。笔试不是要求你拿满分而是考察你在有限时间里的取舍能力。选择题、判断题那种一眼能出的题尽量快速拿下简答题答到点子上、条理清楚编程题至少完整AC一道场景题把思路写清楚哪怕没写完整代码也有分。顺便说一句过了笔试之后这个成绩会同步到后续面试官那边的评估表里。笔试里暴露出来的薄弱点非常大概率会在一面二面中被追问。所以笔试不只是为了过更是为了摸清自己的短板再针对性准备。提示试卷B既然是B卷说明还有A卷甚至C卷。不同考场的题目并不相同但考点覆盖会被有意对齐。所以刷B卷的价值不是背原题而是覆盖考点。2. Java基础题集合、异常、语言特性的踩分点2.1 HashMap和ConcurrentHashMap必考中的必考在试卷B的选择题和简答题里HashMap相关的题目基本没有缺席过。它几乎是最能区分背过八股和真正理解的知识点。第一个高频考点HashMap的数据结构。JDK 8之后是数组加链表加红黑树。当链表的长度超过8并且数组长度达到64时链表会转成红黑树目的是把最坏情况下的查找复杂度从O(n)降到O(logn)。但树化不是常态节点数减少到6以下时又会退化成链表避免红黑树的自旋在数据量小时反而浪费性能。第二个高频考点put操作的完整流程。计算hash时先对key的hashCode做一次高16位与低16位的异或扰动目的是让高位也参与到数组下标的计算中减少冲突。然后用(n-1)hash计算桶下标JDK 8的公式不用取模运算而是用位运算前提是数组长度必须是2的幂。如果发生哈希冲突就尾插法追加到链表尾部注意JDK 7是头插法头插法在并发扩容时可能形成环这就是HashMap线程不安全的一个典型原因。当元素数量超过阈值loadFactor*capacity时触发扩容默认负载因子0.75容量翻倍。第三个高频考点为什么HashMap线程不安全。你只需要记住两个场景JDK 7并发扩容可能成环导致get死循环JDK 8虽然改成尾插法解决了成环问题但多线程put时可能出现数据覆盖因为put是check-then-act操作多个线程同时判断某个桶为空然后同时赋值后写的会覆盖先写的。ConcurrentHashMap则是另一个必考考点。JDK 7用Segment分段锁继承ReentrantLock理论上支持Segment数组大小的并发度。JDK 8放弃分段锁改用CAS加synchronized锁住桶的头节点并发粒度更细。它不允许key或value为null这一点和HashMap不同原因是为了避免并发场景下的二义性如果get返回null你没法判断是key不存在还是value本身是null在并发环境下这种不确定性是有隐患的。2.2 异常体系与try-with-resources异常相关的题在试卷B里通常是选择题但有一类比较坑给你一段代码问输出什么或者问finally里的代码是否一定执行。先理清基本概念。Java的异常是Throwable的两个分支Error和Exception。Error是JVM层面的严重错误比如OutOfMemoryError、StackOverflowError应用程序不应该去捕获。Exception下面又分受检异常和非受检异常。受检异常必须显式捕获或向上抛典型的是IOException、SQLException非受检异常继承RuntimeException可以不做处理典型的是NullPointerException、ArrayIndexOutOfBoundsException、ClassCastException。试卷里经常让你区分一个异常到底属于哪一类。关于finally有一道经典题的答案你必须背下来finally块中的代码并不是一定执行。以下情况不执行在try或catch中调用了System.exit()终止JVMJVM崩溃或断电等极端情况在try块中没有正常执行到finally之前比如陷入了死循环。另一种考察方式是finally中的return会覆盖try中的return。如果try里先返回一个值finally里又有一个return最终返回的是finally里的值。这个细节很容易被忽略我建议你最好自己写个例子跑一遍比死记结论要牢靠得多。try-with-resources是JDK 7引入的资源自动关闭机制凡是实现了AutoCloseable接口的类都可以放在try后面的圆括号里代码块执行完后资源会被自动关闭。它比传统的手动finally关闭更安全因为即使代码块内抛异常关闭资源时如果也抛异常原始的异常会被保留。笔试时如果出现资源关闭相关的代码优先考虑用try-with-resources。2.3 Lambda、Stream与枚举的冷门考点Lambda和Stream在试卷B里不会考得太深但经常以高频选择的形式出现。有一个容易错的知识点Lambda表达式实际上是对函数式接口的实例化。所谓函数式接口就是只包含一个抽象方法的接口比如Runnable、Comparator、Callable以及java.util.function包下的Function、Predicate、Supplier、Consumer。判断一个接口是不是函数式接口可以看它有没有加FunctionalInterface注解默认方法、静态方法不会破坏函数式接口的定义。Comparator.comparing这个用法在笔试编程题和简答题里出现过。它的核心逻辑是让你指定一个提取key的函数然后按照key对元素排序比如list.sort(Comparator.comparing(User::getAge))。如果你想把某个值排到最前面可以用Comparator.comparing(User::getAge).thenComparing(...)来实现多重排序规则或者用一些技巧把特殊的key映射为优先值。这里提醒一点排序如果是倒序注意null值的处理Java 8的Comparator默认对null不友好需要用到Comparator.nullsLast来处理。枚举也是高频考点。它可以定义字段、构造方法、抽象方法可以配合switch使用。有一个经典问题是为什么枚举能实现单例因为枚举类的构造器是私有的且JVM层面保证了每个枚举常量只会被实例化一次同时天然支持序列化不会因为反序列化创建新的实例。这一点比双重检查锁定的单例实现更安全笔试问最推荐的单例写法时答案就是枚举单例。Stream的常见操作里map、filter、collect、sorted是必会的基础。容易被考到的是peek与map的区别peek是中间操作接收Consumer不改变元素而map是转换操作。还有一个点是parallelStream它不是万能加速器对于共享可变状态的操作反而可能出错笔试如果问性能问题一定要提到线程安全因素的考量。3. JVM与并发内存溢出、GC与线程安全的组合拳3.1 各种OOM的成因区分别只会说内存不够关于JVM内存结构试卷B的简答题几乎必考。你需要把运行时数据区说得清清楚楚堆、虚拟机栈、本地方法栈、程序计数器、方法区JDK 8后是元空间。其中堆是对象分配的主要区域虚拟机栈是执行Java方法时创建栈帧程序计数器是当前线程执行的字节码行号指示器。试卷里经常出现一个很具体的报错比如最原始的题目可能是给你一段OutOfMemoryError相关日志问这个错误是什么原因。常见的OOM可以分成这么几类报错信息发生区域主要原因Java heap space堆对象太多或对象过大堆内存不足GC overhead limit exceeded堆GC频繁执行但回收效果差JVM自我保护Metaspace元空间加载的类过多或动态生成类膨胀unable to create new native thread操作系统层面线程数超过系统上限insufficient memory本地内存操作系统无法提供足够的内存给JVM特别注意insufficient memory这个报错。它不是常见的堆内存溢出而是JVM向操作系统申请本地内存失败。什么叫本地内存比如JVM需要分配线程栈、DirectByteBuffer对应的堆外内存、JIT编译器相关的内存、元空间这些都算。如果你看到java: OutOfMemoryError: insufficient memory优先怀疑几个方向物理内存本身不够、进程的虚拟内存地址空间耗尽、cgroup或容器限制导致的内存配额不足、以及换页空间不足。排查这类问题的思路先free -m看物理内存再top看JVM进程内存占用jmap -heap看堆内情况jstat -gcutil看GC压力。如果堆内存使用率不高但进程整体内存持续上涨就要怀疑堆外内存泄漏比如DirectByteBuffer没有释放。我见过一个网关服务频繁OOM的案例最后定位到是因为堆外缓存使用了大量DirectMemory又没有注意回收导致操作系统层面的内存被耗尽。3.2 线程池的核心参数与执行流程线程池的考察在途虎这类笔试中基本是必考的形式可能是简答题也可能是选择题。你至少要能准确说出ThreadPoolExecutor的7个核心参数外加解释阿里的规范不要用Executors创建线程池。7个参数corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。流程是这样的提交任务后如果当前线程数小于核心线程数创建新线程执行任务如果线程数大于等于核心线程数任务先进入阻塞队列如果队列满了继续创建线程直到达到最大线程数如果线程数已经达到最大值就触发拒绝策略。这里要强调的是队列选择对业务的影响。LinkedBlockingQueue无界队列会导致最大线程数形同虚设任务无限在队列里堆积SynchronousQueue不缓存任务来一个任务就必须创建一个新线程适合任务量小但要求快速响应的场景ArrayBlockingQueue有界队列是最常用的。另一个细节corePoolSize和maximumPoolSize之间的线程在空闲时间超过keepAliveTime后会被回收。4种拒绝策略AbortPolicy直接抛异常默认、CallerRunsPolicy由调用线程执行、DiscardPolicy丢弃任务、DiscardOldestPolicy丢弃队列中最旧的任务。如果在途虎这种秒杀活动场景下设计线程池建议用有界队列加CallerRunsPolicy因为抛异常会导致接口直接失败而由调用线程执行可以起到降级和限流的效果。阿里的规范为什么要禁掉Executors两个原因。Executors.newFixedThreadPool用的是无界的LinkedBlockingQueue任务堆积可能导致内存溢出newCachedThreadPool的maximumPoolSize是Integer.MAX_VALUE队列是SynchronousQueue并发量大时会创建大量线程同样会造成OOM或者线程资源耗尽。所以生产环境必须手动new ThreadPoolExecutor把参数暴露出来进行可控配比。3.3 synchronized、ReentrantLock、volatile与ThreadLocal并发编程部分的考点相对密集。synchronized和ReentrantLock的区别是每一家公司的笔试题里都有的常客。你能答出两者都是可重入的、都可以保证可见性和原子性已经很不错了。但答出以下差异就更加分synchronized是隐式锁自动获取和释放ReentrantLock是显式锁需要lock和unlock且unlock必须放在finally中。ReentrantLock支持公平锁和非公平锁synchronized只有非公平锁。ReentrantLock可以中断等待、可以设置超时tryLocksynchronized不能。ReentrantLock支持多个Conditionsynchronized只有一个监视器锁。JDK 6之后synchronized引入了偏向锁、轻量级锁、重量级锁的升级过程所以性能不见得比ReentrantLock差在低竞争环境下synchronized表现更优。volatile是一个高频考点。它保证两点可见性和有序性禁止指令重排序但不保证原子性。典型例子是volatile修饰的计数器在多线程下i仍然不安全因为i是读取-修改-写入三步操作。在场景设计题里你如果提出用volatile保证并发安全面试官很可能追问原子性问题这是一个容易暴露深浅的点。ThreadLocal的考点主要是两个每个线程都有独立的变量副本以及它的内存泄漏问题。ThreadLocalMap的Entry继承了WeakReferencekey是弱引用但value是强引用。如果ThreadLocal对象没有被显式remove而线程仍然存活那么key可以被回收但value无法被回收接下来key变成nullvalue却一直存在导致内存泄漏。正确的做法是在finally块里调用remove。在线程池场景下使用ThreadLocal尤其危险因为线程会被复用一个请求设置的值可能在另一个请求中被读到这就是跨请求数据串扰必须在使用完立即清理。死锁相关问题在试卷里一般是问你如何避免死锁。回答思路是破坏四个必要条件之一——互斥无法破坏锁本身就是为了互斥、持有并等待可以采用一次性申请所有锁、不可剥夺可以设置超时tryLock、循环等待可以保证加锁顺序一致。笔试写代码时最实用的手段就是所有线程都按照同一个顺序获取多个锁。4. 框架与中间件业务系统开发能力的试金石4.1 Spring Boot自动配置与MyBatis防注入试卷B在框架题上侧重的是主流实用型的考察Spring Boot的自动配置原理是我的建议重点。你要能说清楚Spring Boot通过EnableAutoConfiguration注解导入AutoConfigurationImportSelector利用SpringFactoriesLoader从META-INF/spring.factories或AutoConfiguration.imports文件中加载所有候选的自动配置类再通过ConditionalOnClass、ConditionalOnMissingBean这类条件注解决定哪些配置生效。简而言之自动配置就是根据classpath下的依赖和配置属性智能地组装Bean。MyBatis有一个经典问题#{}和${}的区别。前者是预编译占位符传入的值会被当作参数传给PreparedStatement由JDBC驱动进行转义能够有效防止SQL注入后者是字符串直接拼接相当于把变量内容直接拼进SQL语句里存在注入风险。凡是涉及order by、表名这类无法使用参数占位符的场景必须对传入内容做白名单校验更不应该直接把用户可控的字符串拼进SQL。除此以外MyBatis一级缓存是SqlSession级别的默认开启二级缓存是namespace级别的需要显式配置。在分布式环境下二级缓存可能出现数据一致性问题所以并没有无脑开启为佳。这些细节很可能出现在选择题或简答题的加分项里。4.2 MySQL索引与事务隔离级别MySQL在途虎这类重度依赖数据库存储的系统中是核心中的核心。订单要查、门店要查、库存要查、用户要查几乎所有业务都离不开查询所以索引相关题目必考。先理清B树索引的特性它是多路平衡搜索树非叶子节点只存索引键叶子节点存全量数据聚簇索引或主键值二级索引。这种结构天然适合范围查询、排序操作因为叶子节点之间用双向链表相连一次范围扫描不需要回根节点反复查找。聚簇索引和非聚簇索引的区别是InnoDB的主键索引就是聚簇索引数据行物理存储在叶子节点二级索引的叶子节点存储的是主键值所以通过二级索引查找数据时需要回表。这时候覆盖索引就能派上用场如果查询的列恰好都在二级索引里就不需要回表直接返回索引数据性能提升很明显。最左前缀原则说的是联合索引的匹配规则比如建立(a,b,c)联合索引查询条件里有a和b能用到索引只有b和c就用不上。事务隔离级别这块四个级别你必须背得滚瓜烂熟读未提交、读已提交、可重复读、串行化。InnoDB默认是可重复读。由此引入三个概念脏读读到未提交数据、不可重复读同一查询条件下第二次读到的数据被其他事务修改了但字段值一样、幻读第二次读到的行数变多了。MVCC机制用undo log版本链和readView实现一致性快照读使得在可重复读级别下同一个事务内多次查询能看到一致的数据快照。笔试常见的坑是可重复读级别下普通快照读不会出现幻读但当前读select ... for update、update、delete仍可能发生幻读。所以InnoDB引入了间隙锁和next-key lock来配合解决但这块在笔试里只要点到即可面试时才需要详细展开。4.3 Redis缓存与分布式锁的答题思路Redis相关题在试卷B里的存在感很强尤其是缓存穿透、缓存击穿、缓存雪崩这三个概念几乎是简答和场景题的钉子户。缓存穿透查询一个不存在的数据缓存里没有请求一直打到数据库。解决思路缓存空值为不存在的数据设置一个较短的过期时间或者使用布隆过滤器在缓存之前先判断key是否存在。缓存击穿某个热点key过期大量并发请求同时去打数据库。解决思路互斥锁让同一时刻只有一个线程去重建缓存或者逻辑过期让热点key的逻辑过期时间短暂延长后台异步刷新。缓存雪崩大量key同时失效或者Redis宕机导致数据库被打爆。解决思路过期时间加随机值避免key在同一时间过期做多级缓存Redis集群高可用方案限流降级。分布式锁怎么答一句话概括用Redis的SETNX加EXPIRE原子命令或者用Redisson看门狗机制实现可续期的锁。注意一个关键细节不能分两步执行SETNX和EXPIRE否则进程在设置锁之后、设置过期时间之前挂了锁就永远不会释放。应该是SET lockKey value NX PX 30000一条命令完成。释放锁时要用Lua脚本比较value是否一致再删除避免误删其他线程的锁。这个场景在途虎的营销活动、优惠券系统、订单状态更新中非常常见。4.4 API安全对接与ES异步写入的实务延伸从热搜词的观察来看Java Spring Boot的API Key安全对接、ES异步写入这类偏实战的问题也很常出现在面试追问里。API Key的通用方案是客户端调用服务端接口时header中带上AppId和Key服务端用拦截器HandlerInterceptor或过滤器OncePerRequestFilter校验。更安全的做法是加签名把业务参数和时间戳拼接成字符串用约定密钥做HMAC-SHA256签名服务端用同样的密钥重放签名并比对同一时间戳短时间内允许重复请求且过期时间校验通过就能防止重放攻击。ES的异步写入在Java里通常配合消息队列来实现业务数据先写入MySQL同时发送一条消息到Kafka/RabbitMQ消费者从MQ拉取消息后异步写入ES这样既不影响主链路时延也能在ES写入失败后重试。一旦写入失败重试次数达到上限可以丢进死信队列人工排查。这套思路在途虎这种既有结构化订单数据、又有大量日志/搜索需求门店搜索、商品搜索的场景里是很典型的通用方案。5. 算法编程题排序、链表与场景设计的实战节奏5.1 排序算法的边界条件与复杂度试卷B的编程题难度大概在LeetCode中等偏下不会出特别变态的题但这不意味着你可以轻视。最常见的排序题就是冒泡排序和快速排序。冒泡排序虽然简单但笔试时有个优化点某一轮遍历如果没有任何交换说明数组已经有序可以直接退出。加上这个标志位在接近有序的数组上可以降到接近O(n)的时间复杂度这是区分你有没有真实写过代码的细节。快速排序是另一个高频考点。它基于分治选一个基准元素把数组分成小于基准和大于基准两个部分再对子数组递归排序。最坏情况发生在每次基准都选到最大值或最小值时时间复杂度退化为O(n²)所以实际应用中常用三数取中法或者随机选取基准来避免这种情况。平均时间复杂度O(nlogn)。我贴一个笔试风格的快排实现注意边界条件public void quickSort(int[] arr, int left, int right) { if (left right) return; int pivot partition(arr, left, right); quickSort(arr, left, pivot - 1); quickSort(arr, pivot 1, right); } private int partition(int[] arr, int left, int right) { int pivotValue arr[left]; int i left, j right; while (i j) { while (i j arr[j] pivotValue) j--; arr[i] arr[j]; while (i j arr[i] pivotValue) i; arr[j] arr[i]; } arr[i] pivotValue; return i; }笔试里如果只要求排序先考虑Arrays.sort()能不能用如果要求手写排序快速排序和归并排序选一个练熟。归并排序还额外适合解决逆序对问题必要时可以用。5.2 链表和二分查找的代码注意事项链表相关的题在试卷里出现过多次最常见的是反转链表、环形链表检测、删除倒数第N个节点。反转链表用迭代法写最稳三个指针prev、curr、next每次把curr.next指向prev然后整体后移。边界条件是链表为空或只有一个节点。代码量很小但很多人会在最后忘记把头节点指向正确位置建议先在纸上画一遍指针变换。环形链表检测的标准解法是快慢指针fast每次走两步slow每次走一步如果存在环两者必然相遇如果fast走到null说明无环。这题的证明关键是环入口之前的路程加上环内步数存在模运算关系笔试不会让你严格证明但你要能表达清楚快慢指针在环内一定相遇。二分查找是笔试最常见的看似容易但容易写错的题目核心是循环条件left right以及每次收缩区间时mid的更新。经典写法int binarySearch(int[] nums, int target) { int left 0, right nums.length - 1; while (left right) { int mid left ((right - left) 1); if (nums[mid] target) { return mid; } else if (nums[mid] target) { left mid 1; } else { right mid - 1; } } return -1; }注意mid left ((right - left) 1)这个写法它可以防止leftright整数溢出笔试和面试中提到这一点会显得你考虑周全。还有就是边界条件的取值如果循环是left right通常配合的是区间左闭右开容易搞混建议全篇统一用左闭右闭减少心智负担。5.3 结合业务的场景设计题怎么答试卷B的场景设计题非常务实几乎都是围绕互联网业务系统的常见问题。比如如何设计一个订单超时自动关闭系统如何设计一个秒杀场景下的库存扣减方案途虎预约到店场景怎么避免同一个时间段被重复预约回答这类题有一个通用框架先明确核心诉求再说数据存储选型和关键流程最后补充异常和并发处理。以订单超时关闭为例。最简单的方案是起一个定时任务每隔一段时间扫描数据库中超时的订单批量更新状态。这个方案的优点是实现简单缺点是扫描范围大、对数据库有压力而且存在时间窗口误差。更优的方案是用延迟队列订单创建时把订单ID放到延时队列延迟时间到后消费者取出订单并判断是否已支付如果未支付则关闭订单。可以用RabbitMQ的延迟消息插件也可以用Redis的过期key配合监听或者直接用Redisson的延迟队列。答题时提到用延迟队列替代定时轮询这个优化方向通常能拿到不错的分数。库存扣减场景要注意两个点一是防止超卖二是防止数据库压力过大。超卖的经典解法是条件更新UPDATE stock SET count count - 1 WHERE goodsId ? AND count 0减少的话影响行数为0就说明库存不足。如果要缓解数据库压力可以先用Redis的incr/decr原子操作预扣减库存再异步同步到数据库。答题时把这两层讲清楚就比只写加乐观锁要翔实得多。预约时间冲突的场景本质是区间重叠判断。数据库层面可以在门店、时间段字段上建联合唯一索引也可以采用提前锁定时间段事务内检查唯一约束的双保险设计。笔试时能把思路说清楚比写出完整代码更得分。6. 笔试现场避坑环境配置、编译错误与时间分配6.1 本地环境与在线编译器的经典报错笔试过程中很多人不是挂在题目上而是挂在环境上这一点经常被忽略。几个实测概率很高的报错值得提前说道说道。Lombok相关报错编译时提示java: You arent using a compiler supported by lombok, so lombok will not work。这个报错通常在JDK版本和Lombok版本不匹配的时候出现。比如你本地用的JDK 21但项目依赖的Lombok还是1.16系列。解决方案升级Lombok版本到1.18.30以上或者降低JDK版本。在笔试在线环境中大概率不会遇到但如果用本地IDE写练习题这类问题很常见提前把环境调好能省下大把时间。另一个高频报错java: 警告: 源发行版 17 需要目标发行版 17或者反过来目标发行版低于源发行版。这说明编译器使用的JDK版本和项目target版本不一致。在IDEA里需要检查File - Project Structure - Project SDK和Modules里的Language Level在Maven项目里则需要检查pom.xml中maven.compiler.source和maven.compiler.target是否一致。最好在properties里统一配置properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target /properties这样Maven在编译时会沿用指定的源码和目标版本避免IDE默认配置覆盖引起混乱。还有就是数组越界异常我记得热搜词里也有这个。写代码时很多越界都发生在循环边界上比如for (int i 0; i arr.length; i)应该用i arr.length。笔试时尽量在循环条件里统一写成并且对数组访问前做空数组判断。这种边界错误在在线判题系统里会直接导致运行时错误AC不了题。6.2 答题时间分配的实战策略笔试时间通常在90到120分钟之间题量大概40到60道要合理分配时间我的建议是前10到15分钟快速做完选择题和判断题。遇到拿不准的题不要死磕先按直觉选一个并标记等后面有时间再回头。接着用20分钟左右做简答题。不用写长篇大论踩点作答分条列点写清楚。数据库和SQL题用15分钟左右注意审题尤其是多表关联和索引设计的细节。最后留出40到50分钟做编程题这是拿分大头。如果编程题不止一题先做自己最有把握的那道保证至少AC一道再考虑第二道。场景设计题如果留在最后至少要把思路和核心方案写出来不要留白。特别是编程题在线编程平台牛客、赛码网的输入输出格式有差异。有的平台要自己写Scanner解析标准输入有的平台是函数输入输出。我的建议是去牛客上练几道io练习题把Scanner和BufferedReader两种读法都提前跑一遍避免正式笔试时因为IO处理卡壳。另外在线判题平台对时间复杂度和空间复杂度有限制如果算法思路对了但还是超时考虑是否需要改用更高效的数据结构而不是死磕同一个算法。有一道题要特别注意如果输入规模在10^5级别以上O(n²)的暴力解法基本上会超时这时就得考虑二分、哈希表或者双指针优化。途虎这套试卷B还有一个特点题目题干往往比较长会先描述一个业务场景再问你实现方案。读题时先抓关键词并发一致性性能可用性这些词出现的位置决定了你答题的侧重点。不要被场景中的多余信息干扰本质上考点就在几个固定领域里。刷完这套卷我个人最大的感受是它不像一些大厂卷子那样追求偏题怪题而是在反复考察基础功底的深度和业务场景的敏感度。如果你在准备途虎的秋招或者把途虎笔试当练手建议把本文提到的几个重点模块——集合、并发、JVM内存、MySQL索引与事务、Redis缓存、线程池——逐项夯实每块都能说出原理且能上手写代码笔试通过的概率会高出很多。最后分享一个我自己用过的小技巧把每套试卷里做错的题整理成一份带错因分析的笔记考前只看笔记里的错题和对应的知识点导图比重新刷题效率高得多。 途虎2023秋招Java笔试试卷B核心考点解析与避坑指南
这两年秋招笔试我是真没少刷各大厂的卷子基本都见过一遍。途虎养车这套2023秋招Java笔试试卷B在牛客和脉脉上被讨论的频次不低。它不算那种硬核到劝退的题库但胜在覆盖面完整Java基础、JVM、并发、Spring生态、MySQL、Redis、算法编程甚至还有结合业务场景的设计题几乎把互联网公司后端Java岗的核心考点全部囊括进去了。不管你是准备投途虎还是想拿这套卷子当模拟题练手我都建议认真过一遍。这篇文章不打算逐题贴答案而是把试卷B背后真正想要考察的能力模型拆给你看顺便把答题时容易踩的坑、准备时容易被忽视的点都梳理出来希望能帮你少走弯路。1. 试卷B的定位途虎秋招笔试到底想筛什么样的人1.1 途虎的业务形态决定了考点方向先聊一个很多人忽略的问题为什么这套卷子的考点长这样途虎养车本质上是汽车后市场的在线服务平台线上有商城、预约、会员系统线下有大量直营和加盟门店背后还连着一整套供应链、库存、订单、支付、物流体系。这种业务形态决定了它招的Java工程师不是去写底层框架或中间件的而是做业务系统的——也就是大量订单流、库存流、会员流的高并发读写、数据一致性、缓存设计、消息异步处理。所以你看试卷B它不会考你怎么实现一个JVM、怎么从零写一个RPC框架而是重点考察这些内容Java基础是否扎实能不能写出健壮的代码有没有处理过并发、内存这类真实生产问题对Spring Boot这类主流框架的原理理解到不到位会不会用MySQL索引、事务、Redis缓存解决实际业务问题能不能在白板/在线编辑器里快速写出一道中等难度的算法题。说得直白点这套卷子筛选的是能干活、能扛事、基础没硬伤的后台业务开发而不是纯粹的算法竞赛选手或者框架调包侠。1.2 题量、题型与分值结构参考据我拿到试卷B的同学反馈和自己的刷题印象这套卷子的题型大致是题型大致占比考察内容单选题/多选题25%-35%Java语法、集合、异常、面向对象概念判断题5%-10%容易混淆的细节知识点简答题15%-20%JVM内存、垃圾回收、线程池、数据库事务等SQL/数据库题10%-15%索引设计、SQL编写、事务隔离级别编程题20%左右排序、链表、字符串处理、中等难度LeetCode场景设计题10%左右订单超时、库存扣减、缓存雪崩等业务问题这个结构有一个很现实的意义它决定你答不完也能过。笔试不是要求你拿满分而是考察你在有限时间里的取舍能力。选择题、判断题那种一眼能出的题尽量快速拿下简答题答到点子上、条理清楚编程题至少完整AC一道场景题把思路写清楚哪怕没写完整代码也有分。顺便说一句过了笔试之后这个成绩会同步到后续面试官那边的评估表里。笔试里暴露出来的薄弱点非常大概率会在一面二面中被追问。所以笔试不只是为了过更是为了摸清自己的短板再针对性准备。提示试卷B既然是B卷说明还有A卷甚至C卷。不同考场的题目并不相同但考点覆盖会被有意对齐。所以刷B卷的价值不是背原题而是覆盖考点。2. Java基础题集合、异常、语言特性的踩分点2.1 HashMap和ConcurrentHashMap必考中的必考在试卷B的选择题和简答题里HashMap相关的题目基本没有缺席过。它几乎是最能区分背过八股和真正理解的知识点。第一个高频考点HashMap的数据结构。JDK 8之后是数组加链表加红黑树。当链表的长度超过8并且数组长度达到64时链表会转成红黑树目的是把最坏情况下的查找复杂度从O(n)降到O(logn)。但树化不是常态节点数减少到6以下时又会退化成链表避免红黑树的自旋在数据量小时反而浪费性能。第二个高频考点put操作的完整流程。计算hash时先对key的hashCode做一次高16位与低16位的异或扰动目的是让高位也参与到数组下标的计算中减少冲突。然后用(n-1)hash计算桶下标JDK 8的公式不用取模运算而是用位运算前提是数组长度必须是2的幂。如果发生哈希冲突就尾插法追加到链表尾部注意JDK 7是头插法头插法在并发扩容时可能形成环这就是HashMap线程不安全的一个典型原因。当元素数量超过阈值loadFactor*capacity时触发扩容默认负载因子0.75容量翻倍。第三个高频考点为什么HashMap线程不安全。你只需要记住两个场景JDK 7并发扩容可能成环导致get死循环JDK 8虽然改成尾插法解决了成环问题但多线程put时可能出现数据覆盖因为put是check-then-act操作多个线程同时判断某个桶为空然后同时赋值后写的会覆盖先写的。ConcurrentHashMap则是另一个必考考点。JDK 7用Segment分段锁继承ReentrantLock理论上支持Segment数组大小的并发度。JDK 8放弃分段锁改用CAS加synchronized锁住桶的头节点并发粒度更细。它不允许key或value为null这一点和HashMap不同原因是为了避免并发场景下的二义性如果get返回null你没法判断是key不存在还是value本身是null在并发环境下这种不确定性是有隐患的。2.2 异常体系与try-with-resources异常相关的题在试卷B里通常是选择题但有一类比较坑给你一段代码问输出什么或者问finally里的代码是否一定执行。先理清基本概念。Java的异常是Throwable的两个分支Error和Exception。Error是JVM层面的严重错误比如OutOfMemoryError、StackOverflowError应用程序不应该去捕获。Exception下面又分受检异常和非受检异常。受检异常必须显式捕获或向上抛典型的是IOException、SQLException非受检异常继承RuntimeException可以不做处理典型的是NullPointerException、ArrayIndexOutOfBoundsException、ClassCastException。试卷里经常让你区分一个异常到底属于哪一类。关于finally有一道经典题的答案你必须背下来finally块中的代码并不是一定执行。以下情况不执行在try或catch中调用了System.exit()终止JVMJVM崩溃或断电等极端情况在try块中没有正常执行到finally之前比如陷入了死循环。另一种考察方式是finally中的return会覆盖try中的return。如果try里先返回一个值finally里又有一个return最终返回的是finally里的值。这个细节很容易被忽略我建议你最好自己写个例子跑一遍比死记结论要牢靠得多。try-with-resources是JDK 7引入的资源自动关闭机制凡是实现了AutoCloseable接口的类都可以放在try后面的圆括号里代码块执行完后资源会被自动关闭。它比传统的手动finally关闭更安全因为即使代码块内抛异常关闭资源时如果也抛异常原始的异常会被保留。笔试时如果出现资源关闭相关的代码优先考虑用try-with-resources。2.3 Lambda、Stream与枚举的冷门考点Lambda和Stream在试卷B里不会考得太深但经常以高频选择的形式出现。有一个容易错的知识点Lambda表达式实际上是对函数式接口的实例化。所谓函数式接口就是只包含一个抽象方法的接口比如Runnable、Comparator、Callable以及java.util.function包下的Function、Predicate、Supplier、Consumer。判断一个接口是不是函数式接口可以看它有没有加FunctionalInterface注解默认方法、静态方法不会破坏函数式接口的定义。Comparator.comparing这个用法在笔试编程题和简答题里出现过。它的核心逻辑是让你指定一个提取key的函数然后按照key对元素排序比如list.sort(Comparator.comparing(User::getAge))。如果你想把某个值排到最前面可以用Comparator.comparing(User::getAge).thenComparing(...)来实现多重排序规则或者用一些技巧把特殊的key映射为优先值。这里提醒一点排序如果是倒序注意null值的处理Java 8的Comparator默认对null不友好需要用到Comparator.nullsLast来处理。枚举也是高频考点。它可以定义字段、构造方法、抽象方法可以配合switch使用。有一个经典问题是为什么枚举能实现单例因为枚举类的构造器是私有的且JVM层面保证了每个枚举常量只会被实例化一次同时天然支持序列化不会因为反序列化创建新的实例。这一点比双重检查锁定的单例实现更安全笔试问最推荐的单例写法时答案就是枚举单例。Stream的常见操作里map、filter、collect、sorted是必会的基础。容易被考到的是peek与map的区别peek是中间操作接收Consumer不改变元素而map是转换操作。还有一个点是parallelStream它不是万能加速器对于共享可变状态的操作反而可能出错笔试如果问性能问题一定要提到线程安全因素的考量。3. JVM与并发内存溢出、GC与线程安全的组合拳3.1 各种OOM的成因区分别只会说内存不够关于JVM内存结构试卷B的简答题几乎必考。你需要把运行时数据区说得清清楚楚堆、虚拟机栈、本地方法栈、程序计数器、方法区JDK 8后是元空间。其中堆是对象分配的主要区域虚拟机栈是执行Java方法时创建栈帧程序计数器是当前线程执行的字节码行号指示器。试卷里经常出现一个很具体的报错比如最原始的题目可能是给你一段OutOfMemoryError相关日志问这个错误是什么原因。常见的OOM可以分成这么几类报错信息发生区域主要原因Java heap space堆对象太多或对象过大堆内存不足GC overhead limit exceeded堆GC频繁执行但回收效果差JVM自我保护Metaspace元空间加载的类过多或动态生成类膨胀unable to create new native thread操作系统层面线程数超过系统上限insufficient memory本地内存操作系统无法提供足够的内存给JVM特别注意insufficient memory这个报错。它不是常见的堆内存溢出而是JVM向操作系统申请本地内存失败。什么叫本地内存比如JVM需要分配线程栈、DirectByteBuffer对应的堆外内存、JIT编译器相关的内存、元空间这些都算。如果你看到java: OutOfMemoryError: insufficient memory优先怀疑几个方向物理内存本身不够、进程的虚拟内存地址空间耗尽、cgroup或容器限制导致的内存配额不足、以及换页空间不足。排查这类问题的思路先free -m看物理内存再top看JVM进程内存占用jmap -heap看堆内情况jstat -gcutil看GC压力。如果堆内存使用率不高但进程整体内存持续上涨就要怀疑堆外内存泄漏比如DirectByteBuffer没有释放。我见过一个网关服务频繁OOM的案例最后定位到是因为堆外缓存使用了大量DirectMemory又没有注意回收导致操作系统层面的内存被耗尽。3.2 线程池的核心参数与执行流程线程池的考察在途虎这类笔试中基本是必考的形式可能是简答题也可能是选择题。你至少要能准确说出ThreadPoolExecutor的7个核心参数外加解释阿里的规范不要用Executors创建线程池。7个参数corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。流程是这样的提交任务后如果当前线程数小于核心线程数创建新线程执行任务如果线程数大于等于核心线程数任务先进入阻塞队列如果队列满了继续创建线程直到达到最大线程数如果线程数已经达到最大值就触发拒绝策略。这里要强调的是队列选择对业务的影响。LinkedBlockingQueue无界队列会导致最大线程数形同虚设任务无限在队列里堆积SynchronousQueue不缓存任务来一个任务就必须创建一个新线程适合任务量小但要求快速响应的场景ArrayBlockingQueue有界队列是最常用的。另一个细节corePoolSize和maximumPoolSize之间的线程在空闲时间超过keepAliveTime后会被回收。4种拒绝策略AbortPolicy直接抛异常默认、CallerRunsPolicy由调用线程执行、DiscardPolicy丢弃任务、DiscardOldestPolicy丢弃队列中最旧的任务。如果在途虎这种秒杀活动场景下设计线程池建议用有界队列加CallerRunsPolicy因为抛异常会导致接口直接失败而由调用线程执行可以起到降级和限流的效果。阿里的规范为什么要禁掉Executors两个原因。Executors.newFixedThreadPool用的是无界的LinkedBlockingQueue任务堆积可能导致内存溢出newCachedThreadPool的maximumPoolSize是Integer.MAX_VALUE队列是SynchronousQueue并发量大时会创建大量线程同样会造成OOM或者线程资源耗尽。所以生产环境必须手动new ThreadPoolExecutor把参数暴露出来进行可控配比。3.3 synchronized、ReentrantLock、volatile与ThreadLocal并发编程部分的考点相对密集。synchronized和ReentrantLock的区别是每一家公司的笔试题里都有的常客。你能答出两者都是可重入的、都可以保证可见性和原子性已经很不错了。但答出以下差异就更加分synchronized是隐式锁自动获取和释放ReentrantLock是显式锁需要lock和unlock且unlock必须放在finally中。ReentrantLock支持公平锁和非公平锁synchronized只有非公平锁。ReentrantLock可以中断等待、可以设置超时tryLocksynchronized不能。ReentrantLock支持多个Conditionsynchronized只有一个监视器锁。JDK 6之后synchronized引入了偏向锁、轻量级锁、重量级锁的升级过程所以性能不见得比ReentrantLock差在低竞争环境下synchronized表现更优。volatile是一个高频考点。它保证两点可见性和有序性禁止指令重排序但不保证原子性。典型例子是volatile修饰的计数器在多线程下i仍然不安全因为i是读取-修改-写入三步操作。在场景设计题里你如果提出用volatile保证并发安全面试官很可能追问原子性问题这是一个容易暴露深浅的点。ThreadLocal的考点主要是两个每个线程都有独立的变量副本以及它的内存泄漏问题。ThreadLocalMap的Entry继承了WeakReferencekey是弱引用但value是强引用。如果ThreadLocal对象没有被显式remove而线程仍然存活那么key可以被回收但value无法被回收接下来key变成nullvalue却一直存在导致内存泄漏。正确的做法是在finally块里调用remove。在线程池场景下使用ThreadLocal尤其危险因为线程会被复用一个请求设置的值可能在另一个请求中被读到这就是跨请求数据串扰必须在使用完立即清理。死锁相关问题在试卷里一般是问你如何避免死锁。回答思路是破坏四个必要条件之一——互斥无法破坏锁本身就是为了互斥、持有并等待可以采用一次性申请所有锁、不可剥夺可以设置超时tryLock、循环等待可以保证加锁顺序一致。笔试写代码时最实用的手段就是所有线程都按照同一个顺序获取多个锁。4. 框架与中间件业务系统开发能力的试金石4.1 Spring Boot自动配置与MyBatis防注入试卷B在框架题上侧重的是主流实用型的考察Spring Boot的自动配置原理是我的建议重点。你要能说清楚Spring Boot通过EnableAutoConfiguration注解导入AutoConfigurationImportSelector利用SpringFactoriesLoader从META-INF/spring.factories或AutoConfiguration.imports文件中加载所有候选的自动配置类再通过ConditionalOnClass、ConditionalOnMissingBean这类条件注解决定哪些配置生效。简而言之自动配置就是根据classpath下的依赖和配置属性智能地组装Bean。MyBatis有一个经典问题#{}和${}的区别。前者是预编译占位符传入的值会被当作参数传给PreparedStatement由JDBC驱动进行转义能够有效防止SQL注入后者是字符串直接拼接相当于把变量内容直接拼进SQL语句里存在注入风险。凡是涉及order by、表名这类无法使用参数占位符的场景必须对传入内容做白名单校验更不应该直接把用户可控的字符串拼进SQL。除此以外MyBatis一级缓存是SqlSession级别的默认开启二级缓存是namespace级别的需要显式配置。在分布式环境下二级缓存可能出现数据一致性问题所以并没有无脑开启为佳。这些细节很可能出现在选择题或简答题的加分项里。4.2 MySQL索引与事务隔离级别MySQL在途虎这类重度依赖数据库存储的系统中是核心中的核心。订单要查、门店要查、库存要查、用户要查几乎所有业务都离不开查询所以索引相关题目必考。先理清B树索引的特性它是多路平衡搜索树非叶子节点只存索引键叶子节点存全量数据聚簇索引或主键值二级索引。这种结构天然适合范围查询、排序操作因为叶子节点之间用双向链表相连一次范围扫描不需要回根节点反复查找。聚簇索引和非聚簇索引的区别是InnoDB的主键索引就是聚簇索引数据行物理存储在叶子节点二级索引的叶子节点存储的是主键值所以通过二级索引查找数据时需要回表。这时候覆盖索引就能派上用场如果查询的列恰好都在二级索引里就不需要回表直接返回索引数据性能提升很明显。最左前缀原则说的是联合索引的匹配规则比如建立(a,b,c)联合索引查询条件里有a和b能用到索引只有b和c就用不上。事务隔离级别这块四个级别你必须背得滚瓜烂熟读未提交、读已提交、可重复读、串行化。InnoDB默认是可重复读。由此引入三个概念脏读读到未提交数据、不可重复读同一查询条件下第二次读到的数据被其他事务修改了但字段值一样、幻读第二次读到的行数变多了。MVCC机制用undo log版本链和readView实现一致性快照读使得在可重复读级别下同一个事务内多次查询能看到一致的数据快照。笔试常见的坑是可重复读级别下普通快照读不会出现幻读但当前读select ... for update、update、delete仍可能发生幻读。所以InnoDB引入了间隙锁和next-key lock来配合解决但这块在笔试里只要点到即可面试时才需要详细展开。4.3 Redis缓存与分布式锁的答题思路Redis相关题在试卷B里的存在感很强尤其是缓存穿透、缓存击穿、缓存雪崩这三个概念几乎是简答和场景题的钉子户。缓存穿透查询一个不存在的数据缓存里没有请求一直打到数据库。解决思路缓存空值为不存在的数据设置一个较短的过期时间或者使用布隆过滤器在缓存之前先判断key是否存在。缓存击穿某个热点key过期大量并发请求同时去打数据库。解决思路互斥锁让同一时刻只有一个线程去重建缓存或者逻辑过期让热点key的逻辑过期时间短暂延长后台异步刷新。缓存雪崩大量key同时失效或者Redis宕机导致数据库被打爆。解决思路过期时间加随机值避免key在同一时间过期做多级缓存Redis集群高可用方案限流降级。分布式锁怎么答一句话概括用Redis的SETNX加EXPIRE原子命令或者用Redisson看门狗机制实现可续期的锁。注意一个关键细节不能分两步执行SETNX和EXPIRE否则进程在设置锁之后、设置过期时间之前挂了锁就永远不会释放。应该是SET lockKey value NX PX 30000一条命令完成。释放锁时要用Lua脚本比较value是否一致再删除避免误删其他线程的锁。这个场景在途虎的营销活动、优惠券系统、订单状态更新中非常常见。4.4 API安全对接与ES异步写入的实务延伸从热搜词的观察来看Java Spring Boot的API Key安全对接、ES异步写入这类偏实战的问题也很常出现在面试追问里。API Key的通用方案是客户端调用服务端接口时header中带上AppId和Key服务端用拦截器HandlerInterceptor或过滤器OncePerRequestFilter校验。更安全的做法是加签名把业务参数和时间戳拼接成字符串用约定密钥做HMAC-SHA256签名服务端用同样的密钥重放签名并比对同一时间戳短时间内允许重复请求且过期时间校验通过就能防止重放攻击。ES的异步写入在Java里通常配合消息队列来实现业务数据先写入MySQL同时发送一条消息到Kafka/RabbitMQ消费者从MQ拉取消息后异步写入ES这样既不影响主链路时延也能在ES写入失败后重试。一旦写入失败重试次数达到上限可以丢进死信队列人工排查。这套思路在途虎这种既有结构化订单数据、又有大量日志/搜索需求门店搜索、商品搜索的场景里是很典型的通用方案。5. 算法编程题排序、链表与场景设计的实战节奏5.1 排序算法的边界条件与复杂度试卷B的编程题难度大概在LeetCode中等偏下不会出特别变态的题但这不意味着你可以轻视。最常见的排序题就是冒泡排序和快速排序。冒泡排序虽然简单但笔试时有个优化点某一轮遍历如果没有任何交换说明数组已经有序可以直接退出。加上这个标志位在接近有序的数组上可以降到接近O(n)的时间复杂度这是区分你有没有真实写过代码的细节。快速排序是另一个高频考点。它基于分治选一个基准元素把数组分成小于基准和大于基准两个部分再对子数组递归排序。最坏情况发生在每次基准都选到最大值或最小值时时间复杂度退化为O(n²)所以实际应用中常用三数取中法或者随机选取基准来避免这种情况。平均时间复杂度O(nlogn)。我贴一个笔试风格的快排实现注意边界条件public void quickSort(int[] arr, int left, int right) { if (left right) return; int pivot partition(arr, left, right); quickSort(arr, left, pivot - 1); quickSort(arr, pivot 1, right); } private int partition(int[] arr, int left, int right) { int pivotValue arr[left]; int i left, j right; while (i j) { while (i j arr[j] pivotValue) j--; arr[i] arr[j]; while (i j arr[i] pivotValue) i; arr[j] arr[i]; } arr[i] pivotValue; return i; }笔试里如果只要求排序先考虑Arrays.sort()能不能用如果要求手写排序快速排序和归并排序选一个练熟。归并排序还额外适合解决逆序对问题必要时可以用。5.2 链表和二分查找的代码注意事项链表相关的题在试卷里出现过多次最常见的是反转链表、环形链表检测、删除倒数第N个节点。反转链表用迭代法写最稳三个指针prev、curr、next每次把curr.next指向prev然后整体后移。边界条件是链表为空或只有一个节点。代码量很小但很多人会在最后忘记把头节点指向正确位置建议先在纸上画一遍指针变换。环形链表检测的标准解法是快慢指针fast每次走两步slow每次走一步如果存在环两者必然相遇如果fast走到null说明无环。这题的证明关键是环入口之前的路程加上环内步数存在模运算关系笔试不会让你严格证明但你要能表达清楚快慢指针在环内一定相遇。二分查找是笔试最常见的看似容易但容易写错的题目核心是循环条件left right以及每次收缩区间时mid的更新。经典写法int binarySearch(int[] nums, int target) { int left 0, right nums.length - 1; while (left right) { int mid left ((right - left) 1); if (nums[mid] target) { return mid; } else if (nums[mid] target) { left mid 1; } else { right mid - 1; } } return -1; }注意mid left ((right - left) 1)这个写法它可以防止leftright整数溢出笔试和面试中提到这一点会显得你考虑周全。还有就是边界条件的取值如果循环是left right通常配合的是区间左闭右开容易搞混建议全篇统一用左闭右闭减少心智负担。5.3 结合业务的场景设计题怎么答试卷B的场景设计题非常务实几乎都是围绕互联网业务系统的常见问题。比如如何设计一个订单超时自动关闭系统如何设计一个秒杀场景下的库存扣减方案途虎预约到店场景怎么避免同一个时间段被重复预约回答这类题有一个通用框架先明确核心诉求再说数据存储选型和关键流程最后补充异常和并发处理。以订单超时关闭为例。最简单的方案是起一个定时任务每隔一段时间扫描数据库中超时的订单批量更新状态。这个方案的优点是实现简单缺点是扫描范围大、对数据库有压力而且存在时间窗口误差。更优的方案是用延迟队列订单创建时把订单ID放到延时队列延迟时间到后消费者取出订单并判断是否已支付如果未支付则关闭订单。可以用RabbitMQ的延迟消息插件也可以用Redis的过期key配合监听或者直接用Redisson的延迟队列。答题时提到用延迟队列替代定时轮询这个优化方向通常能拿到不错的分数。库存扣减场景要注意两个点一是防止超卖二是防止数据库压力过大。超卖的经典解法是条件更新UPDATE stock SET count count - 1 WHERE goodsId ? AND count 0减少的话影响行数为0就说明库存不足。如果要缓解数据库压力可以先用Redis的incr/decr原子操作预扣减库存再异步同步到数据库。答题时把这两层讲清楚就比只写加乐观锁要翔实得多。预约时间冲突的场景本质是区间重叠判断。数据库层面可以在门店、时间段字段上建联合唯一索引也可以采用提前锁定时间段事务内检查唯一约束的双保险设计。笔试时能把思路说清楚比写出完整代码更得分。6. 笔试现场避坑环境配置、编译错误与时间分配6.1 本地环境与在线编译器的经典报错笔试过程中很多人不是挂在题目上而是挂在环境上这一点经常被忽略。几个实测概率很高的报错值得提前说道说道。Lombok相关报错编译时提示java: You arent using a compiler supported by lombok, so lombok will not work。这个报错通常在JDK版本和Lombok版本不匹配的时候出现。比如你本地用的JDK 21但项目依赖的Lombok还是1.16系列。解决方案升级Lombok版本到1.18.30以上或者降低JDK版本。在笔试在线环境中大概率不会遇到但如果用本地IDE写练习题这类问题很常见提前把环境调好能省下大把时间。另一个高频报错java: 警告: 源发行版 17 需要目标发行版 17或者反过来目标发行版低于源发行版。这说明编译器使用的JDK版本和项目target版本不一致。在IDEA里需要检查File - Project Structure - Project SDK和Modules里的Language Level在Maven项目里则需要检查pom.xml中maven.compiler.source和maven.compiler.target是否一致。最好在properties里统一配置properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target /properties这样Maven在编译时会沿用指定的源码和目标版本避免IDE默认配置覆盖引起混乱。还有就是数组越界异常我记得热搜词里也有这个。写代码时很多越界都发生在循环边界上比如for (int i 0; i arr.length; i)应该用i arr.length。笔试时尽量在循环条件里统一写成并且对数组访问前做空数组判断。这种边界错误在在线判题系统里会直接导致运行时错误AC不了题。6.2 答题时间分配的实战策略笔试时间通常在90到120分钟之间题量大概40到60道要合理分配时间我的建议是前10到15分钟快速做完选择题和判断题。遇到拿不准的题不要死磕先按直觉选一个并标记等后面有时间再回头。接着用20分钟左右做简答题。不用写长篇大论踩点作答分条列点写清楚。数据库和SQL题用15分钟左右注意审题尤其是多表关联和索引设计的细节。最后留出40到50分钟做编程题这是拿分大头。如果编程题不止一题先做自己最有把握的那道保证至少AC一道再考虑第二道。场景设计题如果留在最后至少要把思路和核心方案写出来不要留白。特别是编程题在线编程平台牛客、赛码网的输入输出格式有差异。有的平台要自己写Scanner解析标准输入有的平台是函数输入输出。我的建议是去牛客上练几道io练习题把Scanner和BufferedReader两种读法都提前跑一遍避免正式笔试时因为IO处理卡壳。另外在线判题平台对时间复杂度和空间复杂度有限制如果算法思路对了但还是超时考虑是否需要改用更高效的数据结构而不是死磕同一个算法。有一道题要特别注意如果输入规模在10^5级别以上O(n²)的暴力解法基本上会超时这时就得考虑二分、哈希表或者双指针优化。途虎这套试卷B还有一个特点题目题干往往比较长会先描述一个业务场景再问你实现方案。读题时先抓关键词并发一致性性能可用性这些词出现的位置决定了你答题的侧重点。不要被场景中的多余信息干扰本质上考点就在几个固定领域里。刷完这套卷我个人最大的感受是它不像一些大厂卷子那样追求偏题怪题而是在反复考察基础功底的深度和业务场景的敏感度。如果你在准备途虎的秋招或者把途虎笔试当练手建议把本文提到的几个重点模块——集合、并发、JVM内存、MySQL索引与事务、Redis缓存、线程池——逐项夯实每块都能说出原理且能上手写代码笔试通过的概率会高出很多。最后分享一个我自己用过的小技巧把每套试卷里做错的题整理成一份带错因分析的笔记考前只看笔记里的错题和对应的知识点导图比重新刷题效率高得多。