斐讯2017秋招Java笔试题复盘：从基础语法到JVM内存全覆盖

一晃眼到了2025年，Java校招笔试的题型变了不少，但有一个有意思的现象：每年还是有不少人翻出“斐讯2017秋招java笔试试卷”来刷。我当年也做过这套卷子，说实话，它没有哪些刁钻到离谱的题目，整体走的是“基础全覆盖＋少量工程素养考察”的路子。但恰恰是这种风格，特别适合用来检验一个人对Java基础的理解到底扎不扎实。如果你正在准备Java工程师岗位的笔试，或者想系统梳理一遍JavaSE的核心知识，这篇复盘值得认真看一看。我尽量还原我当时做题时的思考过程，把考点、答案背后的原理，以及机考环境中容易踩的坑一并讲清楚。

1. 先看整张卷子：题型分布与命题套路

当时收到斐讯的笔试邀请，我以为是线上OJ那种纯算法题，结果点开卷子发现是传统的“选择＋填空＋简答＋编程题”组合。整套卷子答题时间90分钟，题量不算大，但覆盖面很广，考完的最大感受是：它并不想难倒你，而是想看清楚你平时写代码到底关不关注细节。

1.1 选择题、填空题、编程题的比例与考察重心

我记得很清楚，斐讯这套卷子选择题占了40分左右，多是单选，少量多选。考察范围大致如下：

• Java基础语法：运算符优先级、标识符命名规则、基本数据类型转换
• 面向对象：继承、多态、重载与重写、static和final的用法
• 集合框架：ArrayList与LinkedList的区别、HashMap的底层结构
• 异常处理：checked异常与unchecked异常、try-catch-finally执行顺序
• 多线程：synchronized、volatile、线程生命周期
• JVM基础：堆、栈、方法区的基本概念

填空题大概是8到10道，考得很细，比如“HashMap的默认初始容量是______，负载因子是______”“volatile关键字保证了可见性和______”。这种题没有太多思考空间，纯粹看平时有没有背过、记过。

简答题我记得有“简述HashMap在JDK 1.7和JDK 1.8中的底层实现差异”“谈谈你对Java中重载和重写的理解”。编程题两道，一道是手写冒泡排序或快速排序，另一道是字符串相关的处理，比如统计单词出现次数。

从命题结构能看出来，这套卷子的设计思路是“基础知识占大头，算法只要求最经典的排序和简单数据处理”。所以如果你现在要拿这套卷子练手，不要一上来就刷动态规划、图论，先把JavaSE的基础知识点排查一遍更有效。

1.2 2017年的题目，为什么到今天还在被翻出来

有人可能会问：一套2017年的卷子，放在今天还有参考价值吗？我的答案是，有，而且比想象中大。Java这门语言的语法和核心类库演进速度并不快，尤其是JavaSE层面的知识点，比如集合、异常、面向对象、多线程，JDK 8到JDK 17这些年的变化主要集中在新增API和语法糖上，底层模型并没有发生颠覆性改变。

斐讯这套卷子恰好把面试官眼中“一个Java工程师必须具备的基础素养”完整地呈现了出来。换句话说，你刷的不是“斐讯的题”，而是“一套针对Java基础的高质量自测题”。哪怕这家公司后来经历了不少波折，这套卷子本身作为复习资料的价值仍然存在。

2. 基础语法和面向对象：丢分重灾区不在难题，在小细节

很多人在准备笔试时喜欢看源码、研究并发，结果反而在基础语法选择题上丢分。斐讯这套卷子的第一部分就是基础题，我做的时候就发现，题目本身不难，但每个选项都像一个“温柔的陷阱”。

2.1 equals与hashCode：选择题里的高频陷阱

卷子里有一道很经典的题：两个对象的equals方法返回true，那么它们的hashCode一定相同吗？反过来，hashCode相同，equals一定返回true吗？

正确答案是：equals相等，hashCode必然相等；hashCode相同，equals不一定相等。当时我身边不少同学在这道题上栽了跟头，因为他们记住了结论，却没有理解为什么。

hashCode的作用是为散列集合服务的，比如HashMap、HashSet。当我们往HashMap里put一个键值对时，它会先用key的hashCode定位到对应的桶（数组下标），然后再用equals判断桶里有没有相同的key。如果两个对象equals相等但hashCode不同，它们在散列集合里就会被分到不同的桶，HashMap就会认为这是两个不同的key，导致相同的数据被存进去两次。所以Java官方约定：重写equals时必须重写hashCode，保证相等的对象有相同的散列值。

打一个生活化的比方：图书馆的书如果按书名首字母分类，两本书书名完全相同，它们必然分到同一个字母区间；但如果两本书分到同一个字母区间，不代表它们是同一本书。hashCode是分类索引，equals是精确比对。

面试官出这道题，表面考的是equals/hashCode的契约，实则是在考察你是否理解散列集合的工作机制。如果能顺手答出“HashMap在put时先比较hashCode定位桶，再比较equals确定是否覆盖”，这题就稳稳拿分了。

2.2 重载、重写、静态绑定与动态绑定

面向对象模块的题基本绕不开重载（Overload）和重写（Override）的区别。斐讯卷子里有一道选择题，给出一段代码，问输出结果。代码大致是这样的：

class Animal { public void eat() { System.out.println("Animal eat"); } } class Dog extends Animal { @Override public void eat() { System.out.println("Dog eat"); } public void bark() { System.out.println("Dog bark"); } } public class Test { public static void main(String[] args) { Animal a = new Dog(); a.eat(); } }

输出结果是“Dog eat”。原因在于，a的编译时类型是Animal，但运行时类型是Dog，eat方法被子类重写，JVM在运行时根据实际对象类型来决定调用哪个方法，这就是动态绑定。而方法重载走的是静态绑定，编译器在编译阶段就根据参数的静态类型决定调用哪个重载版本。

把这两者对比着理解就不会乱了：重载是“同一个类里，方法名相同，参数列表不同，编译器决定”，重写是“子类重新实现父类方法，参数列表和返回类型兼容，运行期决定”。

这类题的核心价值在于，它考察的是你对“编译期”和“运行期”两个阶段的理解。很多写了两三年Java的人，天天用@Override注解，却说不清动态绑定的原理，这在笔试里是很吃亏的。

2.3 枚举、lambda与运算符优先级这类“半个基础题”

2017年Java 8已经发布多年，斐讯的卷子里也出现了一些偏“新特性”的题目。比如枚举类型的使用，问枚举能不能定义抽象方法、能不能实现接口。答案是：枚举可以定义抽象方法，每个枚举常量分别实现；枚举也可以实现接口。因为枚举本质上是一个继承自java.lang.Enum的类，只是编译器帮我们做了语法糖。

lambda表达式也考了一道题，问下面代码是否能编译通过：

Runnable r = () -> System.out.println("hello");

答案是能，因为Runnable接口只有一个抽象方法run，符合函数式接口的定义。如果接口里有多个抽象方法，lambda表达式就无法匹配。这里有个容易忽略的小细节：Runnable和Callable都是函数式接口，但前者run()没有返回值，后者call()有返回值，用lambda写法时需要注意表达式体的类型。

运算符优先级和表达式求值题几乎是必考的。常见坑点包括：

• int a = 5; int b = a++ + ++a;结果是12，不是11
• String s = 1 + 2 + "3";结果是"33"，不是"123"
• 短路运算符&&和||，左操作数决定结果时右操作数不执行

这套卷子用这些细节提示你：字节码层面JVM怎么执行、编译器怎么解析表达式，其实比单纯背结论更重要。在准备这类题时，我建议用javap -c反汇编一下字节码，看几个例子之后，运算符和赋值顺序这块基本不会再错。

3. 集合框架：HashMap、泛型与fail-fast的经典考法

集合框架是Java笔试的必考区域，斐讯这套卷子也不例外。我记得它出了不少关于集合的题目，难度不大，但覆盖面比较细，从底层结构到使用场景都有涉及。

3.1 HashMap的扩容与链表转红黑树，怎么答才完整

HashMap几乎是Java面试的代名词。斐讯的选择题里有一道考默认参数的：HashMap默认初始容量是16，默认负载因子是0.75，扩容时容量变为原来的两倍。当链表长度达到8且数组长度达到64时，链表会转成红黑树；如果数组长度没到64，会优先扩容而不是转树。

这些数值在很多人看来是死记硬背，其实背后有工程考量。负载因子0.75意味着在空间利用率和查询效率之间取一个平衡。负载因子越大，比如1.0，空间利用率高了，但哈希冲突概率增大，链表变长，查询效率下降；负载因子越小，比如0.5，冲突少了，但数组很多位置空着，浪费内存。0.75在统计上是一个比较合理的折中值。

这里我建议答题时多说一句“为什么”，不要只背参数。面试官或阅卷人看到你能答出“扩容的目的是减少哈希冲突，提高存取效率”和“链表转红黑树是为了防止极端情况下哈希冲突过多导致查询退化成O(n)”，对你的基础扎实度会有一个明显更高的评价。

3.2 ArrayList与LinkedList的适用场景判断

斐讯卷子里有一道老生常谈的题：ArrayList和LinkedList有什么区别，分别在什么场景下使用？

答案并不复杂，但想答得完整需要从底层数据结构出发：

• ArrayList基于动态数组，随机访问时间复杂度O(1)，尾部插入和删除也是O(1)均摊；但头部和中部的插入删除需要移动元素，时间复杂度O(n)
• LinkedList基于双向链表，头部和尾部的插入删除是O(1)，但随机访问需要从头或尾遍历，时间复杂度O(n)

做题时容易掉进的误区是“LinkedList插入快，所以插入操作用LinkedList一定更好”。实际上，如果插入位置在列表中间，LinkedList仍然需要先遍历到指定位置，遍历成本是O(n)，最终时间未必比ArrayList快。笔试里如果题干说的是“频繁在头部插入和删除”，LinkedList是合适的选择；如果题干只说“频繁插入删除”而没有指明位置，需要看具体实现才能判断。

这类题的价值在于提醒你：不要记“XX类适合XXX”这种简单结论，而是要能从底层数据结构推导出性能特征。推导出来的结论不仅记得牢，面试时也能应对追问。

3.3 Comparator与Comparable：也是笔试里的熟面孔

排序是集合框架的常见考点。Comparable和Comparator的区别在斐讯的卷子中出现过，简答或填空：

• Comparable是“类自身实现”的比较接口，一个类实现了Comparable，就意味着它自己有了默认排序规则
• Comparator是“外部比较器”，不修改被比较的类，可以随时定义多种排序规则

在Java 8之后，Comparator可以用lambda表达式和链式调用写出非常简洁的代码，比如Comparator.comparing(Person::getAge).thenComparing(Person::getName)。2017年的卷子还不太考这些链式写法，但今天复习时完全可以多写一步，因为现在的面试官很吃这一套，能看出你对Java 8新特性的掌握程度。

4. JVM与内存异常：OutOfMemoryError这题答好了很加分

斐讯这套卷子涉及JVM的题目不多，但很有代表性。它不考调优参数，不考GC算法的细节，而是考最基础的内存区域划分和异常类型判断。但正因为题目基础，反而很多人答得不够准确。

4.1 堆、栈、方法区的基本功

JVM运行时数据区按线程共享和线程私有可以分成两类：

• 线程共享：堆、方法区
• 线程私有：虚拟机栈、本地方法栈、程序计数器

笔试常考的点是：对象实例存在堆里，方法局部变量存在虚拟机栈里，方法区存的是类信息、常量、静态变量，JDK 8之后方法区被元空间（Metaspace）取代，元空间使用本地内存。

最容易出错的地方在于“引用和对象本身”的区别。Person p = new Person()这行代码，如果出现在方法内部，p这个引用变量存放在虚拟机栈的局部变量表中，而new Person()这个对象存放在堆里。如果p是成员变量，那p这个引用就存放在堆里的对象内部。很多人只记得“引用在栈上”，忽略了这个场景区分，答题时就被扣分了。

4.2 从“insufficient memory”看异常信息的阅读方式

现在热词里有一条是java: outofmemoryerror: insufficient memory，很多人在运行某些工具时看到这段报错就懵了。其实这里的关键是，OutOfMemoryError后面的提示信息五花八门，每一种对应不同的内存区域和解决方案：

• Java heap space：堆内存耗尽，对象太多或存在对象泄漏
• GC overhead limit exceeded：GC频繁回收但回收效果差，通常也指向堆内存配置不足
• Metaspace：元空间不足，加载的类太多
• Unable to create new native thread：创建线程时本地内存不足
• insufficient memory：这个信息通常不是JVM标准堆溢出的提示，而更像某个外部进程或JNI层在申请内存失败时打印的，需要结合具体上下文判断

笔试题如果考OOM，往往不会只问“什么是OutOfMemoryError”，而是会给你一段代码，问“这段代码是否会抛出OOM？是哪种OOM？”比如无限循环里不断new对象，很快堆就满了，抛java.lang.OutOfMemoryError: Java heap space。

4.3 内存问题在笔试题里的三种出法

我在整理这套卷子时总结了JVM内存相关的三种常见出题方式：

1. 概念题：直接问运行时数据区包含哪些部分，各自存什么
2. 判断题：给一段代码，判断对象创建在堆还是栈、方法区，或者变量引用存放在哪里
3. 排查题：给出OOM的日志，要求选出合适的排查工具，比如jmap导出堆转储、jstat查看GC情况、jvisualvm监控内存

把这三种题型都准备一遍，JVM部分的笔试基本能覆盖到位。

5. 多线程与并发：考的不是源码，是概念清晰度

多线程几乎是Java笔试的压轴模块。斐讯的卷子在这个部分的题目风格偏“概念辨析”，不像大厂那样一上来就深入AQS和并发源码，但基础概念必须说得清清楚楚。

5.1 volatile可见性与synchronized锁的定位

volatile是老演员了，几乎每套Java笔试题都有它的身影。核心考点有三个：

• volatile保证可见性，一个线程修改了共享变量的值，其他线程能立即看到
• volatile禁止指令重排，可以防止一些因为乱序执行导致的问题，比如单例模式的双重检查锁定就需要用volatile修饰instance
• volatile不保证原子性，count++这种复合操作即使在volatile变量上执行，依然是线程不安全的

很多同学只记住了前两条，忽略了第三条。笔试如果出“volatile修饰的int变量，多个线程同时对它执行自增，最终结果是否是10000”，正确答案是“不一定”，因为自增操作包含了读取、加一、写回三步，volatile只保证了写回后其他线程能看到，但没有保证这三步的原子性。

synchronized的考点则集中在锁的性质上：可重入、非公平（synchronized锁默认非公平，ReentrantLock可以指定公平性）、Java 6之后有偏向锁、轻量级锁、重量级锁的升级过程。笔试常问“synchronized和Lock的区别”，可以从锁的获取释放方式、是否可中断、是否可设置超时时间、是否支持多个条件变量等几个维度展开。

5.2 线程池参数与任务提交逻辑

斐讯卷子里有一道填空题，考的是ThreadPoolExecutor的核心参数。标准的七个参数分别是：

• corePoolSize：核心线程数
• maximumPoolSize：最大线程数
• keepAliveTime：非核心线程空闲存活时间
• unit：时间单位
• workQueue：任务队列
• threadFactory：线程工厂
• handler：拒绝策略

笔试常配一道计算题来考察任务提交流程，比如：核心线程数5，最大线程数10，队列容量100，现在提交150个任务，会发生什么？

答案是：先创建5个核心线程执行前5个任务，接下来100个任务进入队列，队列满后创建额外的5个非核心线程（5到10），再执行新任务，当线程数达到10且队列已满时，剩余任务触发拒绝策略。

这里最容易答错的是“队列满之后是先创建新线程还是先拒绝任务”。正确逻辑是：核心线程数满了，任务进队列；队列满了，创建非核心线程直到最大线程数；最大线程数也满了，队列也满了，才执行拒绝策略。如果把顺序记混，分就丢了。

5.3 死锁题的标准解法

死锁题目出得也比较多。死锁产生的四个必要条件是：

• 互斥：资源同一时刻只能被一个线程占用
• 持有并等待：线程持有资源的同时还在等待其他资源
• 不可抢占：资源只能由持有者主动释放
• 循环等待：多个线程形成环形等待链

笔试题如果让“写出一个死锁的例子”，最简单的方式是开两个线程，分别持有两把锁，然后互相等待对方释放。如果是简答题让“如何避免死锁”，最实用的办法是破坏循环等待，比如所有线程按固定顺序加锁；或者用tryLock设置超时时间，获取不到就释放已持有的锁。

多线程这部分的准备思路，我建议不要只看理论的“八股文”，而是动手写几个小Demo：volatile自增实验、死锁Demo、线程池提交任务观察队列变化。写过一遍之后，笔试遇到这些概念会非常有底气。

6. 手写算法题：从冒泡排序到快速排序的考场安全版

2017年的校招Java笔试，手写代码题不卷，斐讯给了两道题，一道排序、一道字符串处理。但哪怕是这种难度，也有人在考场上为了追求“高端写法”翻车。我的建议是：考场写算法题，求稳不求骚。

6.1 冒泡排序的“最稳版本”

冒泡排序是最容易拿到满分的排序算法，前提是把边界写对。标准写法如下：

public static void bubbleSort(int[] arr) { if (arr == null || arr.length < 2) { return; } for (int i = 0; i < arr.length - 1; i++) { boolean swapped = false; for (int j = 0; j < arr.length - 1 - i; j++) { if (arr[j] > arr[j + 1]) { int temp = arr[j]; arr[j] = arr[j + 1]; arr[j + 1] = temp; swapped = true; } } // 如果一轮下来没有交换，说明已经有序，提前结束 if (!swapped) { break; } } }

这里两个容易丢分的地方：一是内层循环的边界是arr.length - 1 - i，不是arr.length - 1，这样可以避免对已经排好的尾部元素做无用比较；二是加一个swapped标记做优化，这属于细节亮点，阅卷人看到会认为你了解算法的优化空间。

6.2 快速排序的考场实现

快速排序在笔试中出现频率也很高，但考场上写挂的概率比冒泡高得多。最经典的实现是递归加partition：

public static 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 static int partition(int[] arr, int left, int right) { int pivot = arr[left]; int i = left; int j = right; while (i < j) { while (i < j && arr[j] >= pivot) { j--; } while (i < j && arr[i] <= pivot) { i++; } if (i < j) { int temp = arr[i]; arr[i] = arr[j]; arr[j] = temp; } } arr[left] = arr[i]; arr[i] = pivot; return i; }

关键点在基准值的选择和扫描顺序。上面的写法选取最左边的元素作为基准值，扫描时必须先从右往左找小于基准值的元素，再从左往右找大于基准值的元素。顺序颠倒会导致最终交换的基准位置不正确。如果觉得这个逻辑容易记混，也有另一个更简洁的写法：直接倒序遍历把小于基准的元素往前放，配合一个partitionIndex标记。写的时候不管用哪种思路，先在草稿纸上跑一个简单数组{3, 1, 2, 5, 4}演算一遍，确认没问题再抄到答题区，能避免大部分边界错误。

6.3 二分查找与数组越界

斐讯的另一道编程题虽然不是二分查找，但二分查找是各类Java笔试题中的常客，值得一并准备。最常见的问题是边界条件写错：

public static int binarySearch(int[] arr, int target) { int left = 0; int right = arr.length - 1; while (left <= right) { int mid = left + (right - left) / 2; if (arr[mid] == target) { return mid; } else if (arr[mid] < target) { left = mid + 1; } else { right = mid - 1; } } return -1; }

mid的写法，用left + (right - left) / 2可以避免left + right直接溢出，这是个容易被忽视的优化点。数组越界异常（ArrayIndexOutOfBoundsException）在这类手写题里是最常见的扣分项，一是循环边界多写一个等于号，二是没有对空数组和单元素数组做处理。在试卷上写代码时，养成“先判空，再处理边界”的习惯，能减少很多低级错误。

7. 机考环境的坑：环境变量、乱码和版本警告

笔试不只是做题，环境问题往往比题目本身更影响心态。当时很多同学在本地IDE里写得好好的，一到机考环境就各种报错。这一节聊几个和Java环境相关的高频坑，虽然在2017年就存在，到今天依然有不少人在牛客网、vscode等场景里遇到。

7.1 JAVA_HOME与PATH配置的真正含义

如果笔试现场需要自己配Java环境，最常见的操作是配JAVA_HOME和PATH。但很多人只知其一不知其二：

• JAVA_HOME指向JDK的安装目录，一般配到bin目录的上一级，比如C:\Program Files\Java\jdk-17
• PATH里加入%JAVA_HOME%\bin，让操作系统能找到java和javac命令
• classpath变量在现代JDK中一般不需要手动配置，早期教程里配classpath的方式已经不推荐

配置完成后，在命令行里执行java -version和javac -version检查是否生效。有一个常见的坑：明明配了最新JDK，执行java -version却显示旧的版本号。原因多半是PATH变量里旧JDK路径排在前面，比如C:\Program Files\Common Files\Oracle\Java\javapath在前。解决办法是把自己的JDK路径挪到最前面，或者直接删掉那个自动生成的Oracle Java路径。

这类问题在笔试现场极其浪费时间，所以建议提前把环境变量在本地虚拟机或测试机里完整演练一遍。

7.2 “源发行版17需要目标发行版17”是什么问题

现在很多同学用IDEA或vscode写Java时，会遇到这么一条编译警告：java: 警告: 源发行版 17 需要目标发行版 17。它的本质是编译器的source和target版本不一致。代码里用的是Java 17的语法特性，或者项目配置里设置了source为17，但target还停留在旧版本，编译器就会提示需要匹配的目标版本。

出现这个警告通常是因为工具有多个JDK版本，或者Maven的maven.compiler.source和maven.compiler.target配置不一致。解决办法是在pom.xml里统一设置：

<properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

或者使用<release>17</release>，这是更推荐的写法，因为它能同时控制source和target，也能避免误用了JDK 17内部API却被source/target配置绕过的问题。

7.3 vscode运行Java报错乱码的排查思路

热词里有“vscode运行java报错乱码”，这也是机考和日常开发中让人头疼的问题。核心原因是编码不一致。Java源码文件是UTF-8编码，但Windows控制台默认使用GBK编码，输出中文时就会乱码；或者反过来，源码文件是GBK，编译器按UTF-8读取，直接编译报错。

排查步骤很简单：

1. 先确认源码文件本身的编码，vscode右下角可以查看和切换
2. 确认编译器读取编码，javac -encoding UTF-8可以显式指定
3. 确认终端输出编码，在vscode的settings.json里设置"java.debug.settings.consoleEncoding": "UTF-8"或调整terminal.integrated.profiles.windows的编码参数

这套“三端对齐法”可以解决绝大多数乱码问题。实际笔试时遇到乱码，不要慌，先看是不是控制台输出编码的问题，再检查源码编码，十有八九是这两者没对上。

8. 这套卷子留给我的复习方法论

最后说点我自己的体会。斐讯2017秋招Java笔试试卷，放在今天来看已经不算难，但它的考点分布其实给了一条很清晰的复习主线：先吃透JavaSE基础语法和面向对象，再把集合、异常、多线程、JVM这几块核心知识梳理成体系，最后配上排序、查找这类经典算法的手写能力。

我当时做完这套卷子之后，给自己定了一个复习计划：每个考点都要求自己“能用自己的话解释原理”，而不是背结论。比如HashMap为什么默认容量是16，为什么负载因子是0.75，volatile为什么不能保证原子性，这些都要能脱离书本讲出逻辑链条。笔试并不可怕，它本质上是在帮你找出知识体系里的盲区。

如果你现在也在准备Java笔试，我的建议是：拿这套卷子做一次自测，做完之后把每一道题涉及的知识点都列出来，逐个在IDE里写Demo验证一遍。尤其是环境变量、编码、版本配置这类容易被忽略的细节，提前练到形成肌肉记忆。真正到了考场上，你会发现，大多数题目考的不是智商，而是你有没有认真准备过。