网易Java实习生笔试题深度拆解：HashMap、并发与JVM实战

2018年网易实习生招聘Java开发实习生（云音乐）的这套笔试题，我印象很深。那时候网易云音乐正处在用户量和功能迭代的高速增长期，笔试环节既要筛掉只会背八股文的选手，又要在短时间内看出一个人有没有真实的工程思维。整套题下来，核心就五个字：基础加实战。无论你是在准备校招、社招跳槽，还是单纯想验证自己的Java基本功，这类题目都值得认真过一遍。下面我就以这套题为样本，把考察逻辑、核心考点、答题思路和踩坑经验完整拆一遍。

先说结论：这套题没有偏难怪，但它很会“变着花样考基础”。比如同样是对着HashMap，简单点考你底层结构，难一点就让你说说并发环境下为什么不安全，再难一点直接给一段多线程操作Map的代码问你哪里有问题。如果你只是背过答案，没见过背后代码长什么样，大概率会在第二层就卡住。所以这篇文章不打算只罗列题目，而是把每一类考点背后的思维链路都捋清楚。

1. 试题定位：网易云音乐Java实习生的考核逻辑

1.1 为什么是云音乐，不是别的产品线

先聊一个很多人忽略的背景：网易云音乐这个业务场景，决定了它招的Java实习生需要什么样的能力。

网易云音乐在2018年前后处于什么状态？曲库在扩大、个性化推荐在做、评论社区和歌单生态已经成了产品壁垒，UGC内容量非常大。这意味着后台系统要处理的不是普通的增删改查，而是“海量用户行为数据”和“高并发请求”的组合。比如一首热门歌曲的评论区，某个活动上线瞬间的请求量，足以让一个没有并发意识的系统直接卡死。

所以你会看到，云音乐线的Java笔试题从来不是单纯考察Java语法，而是带着业务影子去出题。出题人真正想筛选的人，是那种“懂Java基础、能理解业务场景、还能把两者结合起来设计方案”的实习生。换句话说，如果你能把题目里的知识点讲清楚，并顺带说一句“这个知识点在遇到热点流量时应该怎么处理”，那在面试官眼里就已经赢了一大半。

1.2 整套题的考察结构推演

根据这套题目的脉络，我把考察内容拆成四个层次，这也是互联网公司Java实习笔试通用的分层思路：

• 第一层：Java语言基础。面向对象特征、集合框架、异常机制、常用类库。这一层考察的是你有没有系统学过Java，还是只靠复制粘贴在写代码。
• 第二层：数据结构与算法。排序、查找、链表、字符串处理，以及少量动态规划和二叉树问题。这一层考察的是计算机基本功，尤其在笔试环节，手写代码是跑不掉的。
• 第三层：JVM与并发。内存区域划分、垃圾回收、线程安全、锁机制。这一层考察的是对Java运行机制的理解深度，也是区分“只会用”和“懂原理”的关键。
• 第四层：工程实践。包括环境配置、编译报错、日志异常、依赖管理等场景问题。这一层没有固定答案，但非常能看出一个实习生的实际动手能力。

这四个层次并不是孤立的。很多题目会刻意把两层内容揉在一起，比如让你设计一个线程安全的缓存，既涉及数据结构，又涉及并发控制，还涉及设计模式。我在后面的第三、四部分会专门展开这类综合题的答法。

1.3 笔试评分里那些“看不见的加分项”

很多同学以为笔试就是“答案对不对”，其实在阅卷人眼里，代码之外的细节同样重要。我根据多次参与校招面试的经验，给你列几个隐藏加分项，这是常规面经里很少写到的：

• 变量命名是否规范。一个方法叫getUserById还是单个字母，第一眼就能拉开差距。
• 边界条件是否考虑到位。反转链表时链表为空怎么办，数组排序时元素相等怎么办，这些测试用例思维很加分。
• 时间复杂度和空间复杂度的分析。答完算法题顺手写上O(n)或者O(log n)，会让阅卷人觉得你有复杂度意识。
• 注释是否恰当。不是让你写一堆废话注释，而是在关键算法步骤处说清楚思路。

当然，这些只能锦上添花，前提是核心答案正确。但反过来，如果你的核心代码写得乱糟糟，哪怕结果对了，面试官也会质疑你后续在团队里的协作成本。

2. Java基础考点拆解：八股文也得融会贯通

2.1 面向对象特征：不是背定义，而是讲场景

面向对象三大特征——封装、继承、多态，几乎是每年必考。但网易这类大厂早就不满足于“什么是多态”这种背书题了。它更可能换一个问法：请你设计一个音乐播放器相关的类结构，体现封装、继承、多态。

我当时看到这类题的第一反应是别急着写代码，先把类的继承层次画出来。比如可以设计一个抽象类MediaPlayer，封装播放状态和音量等字段；然后派生AudioPlayer和VideoPlayer两个子类，分别重写play方法；再用一个PlayerManager来统一管理播放器实例。这样不仅展示了三大特征，还顺带用了抽象类和接口两个知识点。

这里有个容易被忽略的细节：多态的前提是继承和方法重写，而你调用父类引用指向子类对象时，编译期看左边，运行期看右边。这种机制在笔试里经常以“输出结果”的形式出现，比如判断一段代码最终打印的是什么。如果对静态分派和动态分派不熟，很容易在这种题上丢分。

提示：准备面试时不要只背“封装是隐藏实现细节”这类一句话定义。试着拿一个熟悉的业务场景，比如播放器、订单、用户体系，去完整设计一次类结构，效果比刷十道选择题都强。

2.2 集合框架高频题：HashMap原理和并发问题

集合框架里最高频的绝对是HashMap。从笔试到面试，HashMap相关问题能占到集合类题目的三分之一以上。2018年那个时间点，JDK 8已经普及，所以重点要掌握：

• JDK 8中HashMap的底层结构是数组加链表加红黑树。链表长度超过8且数组长度超过64时，链表会转成红黑树。
• 哈希冲突的解决方式是链地址法，也就是在数组每个桶上挂链表或者红黑树。
• 扩容机制是当元素个数超过负载因子乘以数组长度时，数组扩容为原来的两倍，并重新计算元素位置。
• HashMap为什么线程不安全。重点是头插法导致的循环链表问题在JDK 8里改成了尾插法，但依然存在丢失更新、size计算不准确等并发问题。

笔试里常考的变形题包括：给定一组key，问你它们会落在哪个桶上；或者问你HashMap在JDK 7和JDK 8之间的区别。这种题就是要你真正走一遍hash和indexFor的过程，而不能只背结论。

另外，String作为key时要注意它的hashCode实现是基于字符内容的，这也是为什么String适合做Map的key。但如果你用自定义对象做key，就必须同时重写equals和hashCode，否则会因为hashCode不同导致同一个逻辑key被当成两个不同key，这是很经典的隐藏坑。

2.3 异常机制与常用类：笔试题里的“送分”与“送命”

异常机制在笔试里看起来是送分题，实际上翻车率很高。主要原因在于很多应届生分不清受检异常和运行时异常的区别，也不知道finally块里return的优先级。

举个例子，下面这段代码的输出是什么：

try { return 1; } finally { return 2; }

答案是返回2。因为finally块会在return执行前执行，如果finally里有return，它会覆盖try里的返回值。这个知识点在笔试选择题里出现过很多次，你要是没踩过这个坑，很容易凭直觉选错。

常用类方面，String、StringBuilder、StringBuffer的对比也是高频题。简单说：String不可变，每次拼接都会产生新对象；StringBuilder可变但线程不安全；StringBuffer可变且线程安全，但因为有同步开销，性能略低。笔试里常考察“以下哪种拼接方式效率最高”这类题，答案基本都是StringBuilder。

还有一个容易被忽视的点是包装类的自动装箱和拆箱。比如Integer在-128到127之间有缓存，所以Integer a = 100; Integer b = 100; a == b的结果是true，但换成200就是false。这种题在笔试里属于典型的“一看就会，一写就错”，建议大家专门整理一下。

2.4 Java 8特性：Lambda与枚举的笔试常见问法

很多人复习Java基础时容易漏掉Java 8带来的新特性，但2018年的校招笔试其实已经开始考Lambda表达式了。要理解Lambda，核心是搞清楚函数式接口：只有一个抽象方法的接口，比如Runnable、Comparator，都可以用Lambda来简化匿名内部类的写法。

举个笔试里常出现的例子，给一个List排序，传统写法是：

list.sort(new Comparator<Integer>() { @Override public int compare(Integer a, Integer b) { return a - b; } });

用Lambda写就是一行：

list.sort((a, b) -> a - b);

如果题目再进一步，问你list.sort(Integer::compareTo)这种方法引用的写法是否等价，那就要理解方法引用的本质是Lambda的一种简化形式。这类题在选择题里出现频率很高，只要能把匿名内部类、Lambda、方法引用三层关系捋顺，基本不会丢分。

枚举类型也是容易被小看的考点。笔试常问的是：枚举可以定义构造方法、字段、抽象方法吗？答案是可以。实际开发中用枚举管理常量状态，比如播放器的播放、暂停、停止状态，比用int常量更安全、可读性也更好。笔试如果让你设计状态流转，用枚举往往是加分答案。

3. 算法题实操思路：从冒泡到快排的代码审美

3.1 排序算法横向对比：为什么笔试爱考快速排序

算法部分，排序几乎是绕不开的。从热词里能看到，大家搜索量最高的就是“冒泡排序java”和“快速排序java实现”，可见这是多少人的心头痛。

我建议把冒泡排序、选择排序、插入排序、归并排序、快速排序这五种放在一起对比着记。先记住核心思想：冒泡是相邻比较交换，选择是每次找最小，插入是往有序序列里插，归并是分而治之再加合并，快排是选基准再分区。然后记住时间复杂度和空间复杂度，尤其是快排的平均时间复杂度是O(n log n)，最坏是O(n²)，但通过随机选择基准或者三数取中可以把最坏情况概率降到很低。

先看大家最常写的冒泡排序，这个版本的代码几乎人人都会：

public void bubbleSort(int[] arr) { for (int i = 0; i < arr.length - 1; i++) { for (int j = 0; j < arr.length - 1 - i; j++) { if (arr[j] > arr[j + 1]) { swap(arr, j, j + 1); } } } }

但笔试如果只让你写冒泡，通常还会追一个问题：如果数组已经有序，这个版本还能优化吗？答案就是加一个标记位，当某一轮完全没有发生交换，说明排序已经完成，直接跳出循环。很多人在准备时只背了基本版本，没想过优化点，在面试官追问时就会露怯。所以准备排序题，最好是“基本实现 + 复杂度分析 + 可能的优化”三个层面一起准备。

笔试手写快速排序时，最容易出错的地方不是主逻辑，而是递归边界。我之前写过一版快排，在递归调用时忘了判断左指针是否小于右指针，结果在数组有序时直接栈溢出。后来养成了习惯：任何涉及递归的排序算法，先想清楚递归终止条件再动手。

这里给你一个能直接用的快排模板：

public void quickSort(int[] arr, int left, int right) { if (left >= right) { return; } int pivotIndex = partition(arr, left, right); quickSort(arr, left, pivotIndex - 1); quickSort(arr, pivotIndex + 1, right); } private int partition(int[] arr, int left, int right) { int pivot = arr[right]; int i = left - 1; for (int j = left; j < right; j++) { if (arr[j] <= pivot) { i++; swap(arr, i, j); } } swap(arr, i + 1, right); return i + 1; }

这个写法用的是“选择最右元素作为基准 + 双指针分区”的思路，逻辑清晰，边界不容易乱。笔试时如果时间不够，把上面这套模板默写下来，基本就能拿分。

注意：面试官让你手写排序，通常还会追问一句“这个排序稳定吗？”“在什么场景下不适合用？”快排是不稳定排序；如果要求稳定且在乎最坏复杂度，应该选归并排序。

3.2 链表操作手写：边界条件才是真正的考点

链表题在笔试里出现频率很高，因为它写起来短，但特别考验边界意识。最常见的三道题是：反转单链表、判断链表是否有环、找链表倒数第K个节点。

以反转单链表为例，主流解法是迭代法，用三个指针pre、cur、next来维护。代码如下：

public ListNode reverseList(ListNode head) { ListNode prev = null; ListNode cur = head; while (cur != null) { ListNode next = cur.next; cur.next = prev; prev = cur; cur = next; } return prev; }

这段代码的核心是：先保存下一个节点，再把当前节点的next指向前一个节点。很多人在写的时候会漏掉保存next这一步，导致指针丢失、链表断掉。还有就是while的终止条件是cur为null，不是cur.next为null，这个边界一旦错了，反转的结果就会少一个节点。

判断链表是否有环推荐快慢指针，一个走一步一个走两步，如果相遇就说明有环，如果走到null说明无环。这里有个小细节：快指针每次走两步的写法要注意空指针，所以在循环里要同时判断fast和fast.next不为空。笔试现场能把这些细节写清楚，代码风格会非常加分。

3.3 字符串与数组常见变形题

除了排序和链表，字符串和数组的题目也占了算法部分相当大的比重。高频的有：字符串反转、判断回文、最长公共前缀、两数之和、数组去重、移动零。

这些题目看起来不难，但考察的其实是“有没有掌握更优解”。比如两数之和，暴力解是两层循环O(n²)，但要达到O(n)就得用HashMap记录已访问的元素。笔试阅卷人看到你写O(n)解和写O(n²)解，打分完全是两个档次。

我建议准备算法时，不要只满足于“能做出来”，而是每道题都问自己三个问题：解法的时间复杂度是多少？空间复杂度是多少？如果数据量变大，这个解法还可行吗？养成这个习惯后，笔试遇到变形题也不慌。

4. JVM与并发：云音乐场景下的高频追问

4.1 JVM内存区域与OutOfMemoryError排查

JVM相关考点里，内存区域划分是必考中的必考。Java运行时数据区分为程序计数器、虚拟机栈、本地方法栈、堆和方法区。JDK 8之后方法区被元空间替代，使用的是本地内存，这一点在笔试选择题里经常出现。

为什么云音乐这类业务会格外关注JVM内存？因为用户行为上报、歌单推荐计算、评论内容缓存，都涉及大量对象的创建与回收。一旦堆内存设置不合理，或者代码里有对象泄漏，很容易出现OutOfMemoryError。热词里那条java: outofmemoryerror: insufficient memory，就是很多人在本地跑IDE时遇到过的报错，原因是程序请求的内存超过了JVM可用内存限制。

遇到OOM，正确的排查思路是三步走：

1. 先看报错类型：是堆内存溢出（java.lang.OutOfMemoryError: Java heap space），还是栈溢出（StackOverflowError），还是元空间溢出。
2. 如果是堆溢出，用jmap或者MAT工具生成堆转储文件，分析哪些对象占用内存最多。
3. 定位到代码层面，看是不是有集合持有大量对象一直不释放，或者有缓存无限增长。

在笔试里，这类题不一定让你真去排查线上故障，但会让你分析一段代码是否存在内存泄漏风险。典型的例子就是静态集合一直add对象，导致对象无法被回收。这个意识，实习生如果能说清楚，相当加分。

4.2 垃圾回收基础：从引用类型到GC算法

垃圾回收方面，重点掌握可达性分析、引用类型、分代收集三个层次。可达性分析就是从GC Roots出发，向下搜索引用链，没有引用链的对象会被判定为可回收。GC Roots包括虚拟机栈中的引用对象、静态变量引用、常量引用等。

引用类型在JDK里分为强引用、软引用、弱引用和虚引用。笔试常考的是软引用和弱引用的区别：软引用在内存不足时才回收，适合做缓存；弱引用在下一次GC时就会回收，适合做类似WeakHashMap的键。云音乐这种有大量图片缓存和歌单缓存的场景，理论上就特别适合用软引用做内存敏感的缓存设计，这类“把知识点对应到业务”的思考，在面试里非常加分。

分代收集是指堆内存分成新生代和老年代，新生代又分为Eden区和两个Survivor区。大部分对象在Eden区被创建，Minor GC后存活的对象被移入Survivor区，经过多次回收仍然存活的对象最终晋升到老年代。笔试可能会让你画出对象分配流程，或者问垃圾回收器的区别，比如CMS和G1的特点。

提示：不要试图背下所有垃圾回收器的参数，笔试和实习面试更看重“你知道为什么需要分代”“对象在什么时候进入老年代”这两个核心逻辑。

4.3 线程安全与并发工具：从HashMap到ConcurrentHashMap

并发部分的考察重点，在于你能否说清线程安全问题的根源，以及用什么手段解决。很多笔试选择题会给出多个容器类，问你哪个是线程安全的。答案里通常会出现Hashtable、Vector、ConcurrentHashMap，这时候你要清楚：Hashtable和Vector虽然线程安全，但采用的是整体加锁，并发效率很低；ConcurrentHashMap采用分段锁（JDK 7）或CAS加synchronized（JDK 8），并发性能明显更好。

synchronized和ReentrantLock的对比也是高频题。简单说：synchronized是JVM层面的关键字，使用简单，JDK 6之后引入了锁升级机制，性能已大幅提升；ReentrantLock是JDK层面的API，支持可中断获取锁、公平锁、超时等待等更灵活的特性。笔试如果问“什么时候选ReentrantLock”，答案通常是有超时等待或公平性要求的时候。

还有volatile关键字，它保证可见性和有序性，但不保证原子性。笔试里经典的题目就是count++不是原子操作，哪怕用volatile修饰也做不到线程安全，因为这是读改写三步操作。如果要用原子操作，得用AtomicInteger或者加锁。

我建议在准备并发时，把“可见性、原子性、有序性”这三个问题自己各找两个例子讲清楚，再记忆锁机制和并发容器的演进，基本上就能覆盖云音乐线笔试题里的并发部分。

5. 工程能力与调试经验：笔试之外的隐藏分

5.1 Lombok编译失败：环境问题背后的原理

很多人以为大厂笔试题只会考JDK语法，其实工程实践的坑也会出现在题里，尤其是线上编译报错类的问题。热词里有一条特别典型的：java: you aren't using a compiler supported by lombok, so lombok will not work。

这个报错的本质是Lombok通过注解处理器在编译期生成getter、setter等方法，但如果你用的JDK版本过新，而Lombok版本太旧，两者的编译接口不匹配，Lombok就会拒绝工作。解决办法也很简单：升级Lombok版本到与JDK兼容的版本，或者检查IDE里的注解处理选项有没有打开。

从笔试和面试角度来看，这类问题不是为了考你Lombok怎么配，而是看你在遇到陌生报错时有没有排查思路。标准流程是：先读懂报错信息，再确认环境版本，最后查官方文档或搜索引擎定位兼容性要求。能把这套方法论说出来，比背任何命令行都有用。

5.2 Java环境变量配置与版本不匹配

环境配置类问题在笔试和非技术面试里也经常出现，尤其是JAVA_HOME配置错误、source 版本 17 需要 target 版本 17这类编译版本不匹配的报错。

JAVA_HOME的正确配置思路是：指向JDK的安装根目录，而不是bin目录；然后在PATH里加上%JAVA_HOME%\bin。很多人配错就是因为直接把bin目录写成了JAVA_HOME，导致后续所有依赖JAVA_HOME的工具全部找不到JDK。

编译版本不匹配的报错，本质是javac在编译时默认用当前运行版本的特性，但target目标版本没有对应设置。解决方案是在pom.xml里统一配置maven.compiler.source和maven.compiler.target，或者在使用javac -source 17 -target 17时保证两个参数一致。这个坑在本地开发中非常常见，理解了原理后基本一次就能解决。

另外，如果你平时用vscode写Java，遇到控制台中文乱码，先别急着改代码。乱码的根源一般是项目文件编码（比如UTF-8）和控制台输出编码（比如GBK）不一致。在vscode里可以通过设置java.debug.settings.consoleEncoding和终端编码来统一，或者直接检查.vscode/settings.json里的file.encoding配置。这个问题的解决思路和笔试里的“阅读报错信息”是相通的：先定位信息从哪个环节产生，再针对性调整。

5.3 从笔试错题反推工程落地教训

我复盘这套笔试时有一个很深的体会：笔试里的很多“错题”，并不是因为你不会某个知识点，而是平时写代码时没有养成规范意识。比如IDE报错乱码，很多时候是项目文件编码和IDE默认编码不一致导致的。在遇到这类问题时，第一步不是盲目改代码，而是确认文件编码、IDE编码、控制台编码三方是否统一。

再比如数组越界异常ArrayIndexOutOfBoundsException，虽然属于运行时异常，但如果在算法题里出现，往往就是循环边界写错了。归根结底，笔试考察的工程素养，和你日常写代码的严谨程度高度相关。从这个角度说，平时写代码多用debug、多关注异常堆栈、多保持代码整洁，这些习惯都会在笔试考场上体现出来。

6. 备考复盘与避坑指南

6.1 常见问题速查表

我把这套笔试题延伸出来的高频问题和易踩的坑整理成一个速查表，方便你复习时对照自查：

这张表基本覆盖了我在准备这类笔试时反复复习的核心内容。

6.2 我踩过的坑和备考建议

最后分享几个我实际备考时踩过的坑，希望能帮你少走弯路。

第一个坑是只刷选择题，不手写代码。前几年Java笔试中，选择题占了一部分，但算法题和设计题比例并不低。如果只在脑内做题，到了要手写快速排序、反转链表的时候，你会发现自己写字速度完全跟不上思路。所以从备考第一天起，就打开IDE，或者直接在纸上、白板上手写代码，每天至少保证两道算法题的实操量。

第二个坑是忽视复杂度分析。很多题我会解，但从来没想过为什么用这个解法。直到有一次复盘才发现，如果面试官追问“你这个解法在最坏情况下表现如何”，我大概率答不上来。建议每道题做完之后，在代码旁边标注时间复杂度和空间复杂度，形成条件反射。

第三个坑是死记硬背Lombok、环境变量这类工具问题的答案，而没有理解底层原理。这类工程问题虽然不常出现在算法题里，但笔试后面的面试环节非常喜欢问。与其背答案，不如自己搭一个项目，故意把版本调乱、把编码改乱，亲自动手排查一遍。踩过一遍坑，下次遇到再也不会慌。

从2018年网易云音乐这套Java实习生笔试题来看，整体并没有超出常规Java知识体系的范围。真正决定你能不能拿offer的，不是你知道多少冷门技巧，而是你能不能把最基础的知识理解到位，并且在写代码时展现清晰的工程思维。把这个逻辑想明白，再去准备任何一家大厂的Java实习笔试，都会从容很多。