企业官网建设流程全解析

2018年秋招季，我在做用友的Java笔试题时印象最深的一点是：这家公司的卷子不怎么考偏题怪题，但越是你以为简单的题，坑越深。用友是国内老牌的企业服务软件厂商，ERP、财务软件、云服务是它的主战场，后端大量依赖Java技术栈，所以笔试环节对Java基础功的考察非常细，细到你平时写代码根本不会注意的那种程度。

这套“用友2018秋招Java笔试题（七）”整体风格是典型的“基础为纲、原理为本”：不会让你手写红黑树，也不会让你默写GC参数，但会把Java基础语法、集合框架、JVM内存、并发机制这些最核心的知识点揉进看似简单的小题目里，专门考验你对底层原理的理解是否扎实。对于正在准备Java笔试和面试的朋友来说，这类题的价值不在于“背答案”，而在于通过每道题反推出自己知识体系里的缺口。

我从这套题里挑出了一些高频考点，并结合实际做题时的思考过程做了详细拆解。内容按题型板块组织，每道题都会讲清楚正确解题思路、背后的原理，以及当时踩过的坑。

1. 这套笔试题的出题逻辑与考察布局

1.1 题型结构与时间分配策略

用友这套题大约持续90分钟，整体结构大概是：单选20题左右、多选10题左右、简答3题左右，外加一道或多个小的编程题。从题量上看并不算特别大，但真正做起来会发现时间很紧，因为很多选择题一眼看上去会，真要确定答案却要反复推演。

我做完复盘时总结出一个经验：单选题里至少有60%是“原理型”题目，不是考你API怎么调，而是考你“底层是怎么实现的”。比如集合部分，不问你HashMap怎么put，而是问你“当链表长度超过多少时转为红黑树”“为什么默认负载因子是0.75”这种。这类题的难点在于，如果你平时只停留在“能用就行”的层面，看到选项会觉得每个都像对的。

时间分配上，我的建议是：单选和多选控制在40分钟内，简答控制在30分钟内，编程题留至少20分钟。编程题通常不难，但容易因为前面选择题纠结太久而没时间写。我当时就犯过这个错误，在一道关于字符串比较的选择题上花了将近5分钟，导致后面编程题写得比较赶。笔试题的分数分布通常是均匀的，不要为了一道1分的选择题牺牲后面10分的大题。

1.2 题目背后考察的核心能力

用友作为一家做企业级软件的公司，对Java开发者的核心要求有两个：第一，扎实的语言基础，因为企业级应用的业务逻辑复杂，底层基础不牢会出现各种难以排查的线上问题；第二，对JVM和并发有真实理解，因为ERP这类系统通常要处理大量并发请求和数据流转，JVM调优和线程安全是日常工作中躲不开的话题。

所以整套题覆盖的知识板块基本可以归纳为：基础语法与运算符、面向对象与字符串机制、集合框架与泛型、JVM内存与异常处理、并发编程、Java新特性。以下内容就按这个顺序展开，每一类挑出最具代表性的题目来拆解。

2. 基础语法题：自增、类型提升与字符串比较

2.1 自增运算符的连续运算陷阱

当时第一道让我纠结的题目是这样的：

public class Test { public static void main(String[] args) { int i = 0; int j = i++ + ++i + i--; System.out.println(j); } }

问输出结果是什么。这道题本质上考察的是一条语句里多个自增自减表达式混合执行时，变量值的实时变化。我当时的分析过程是这样的：

先看第一个i++，它表示先返回i的当前值0，然后i自增变成1。注意，这里返回的是0，但i本身已经变成1了。再看中间的++i，前缀自增是先让i加1再返回，所以i从1变成2，返回2。最后是i--，后缀自减先返回i当前的2，然后i减成1。所以整个表达式的结果是0 + 2 + 2 = 4。

提示：这种题考察的核心是“后缀先使用后自增”“前缀先自增后使用”的语义，以及运算符在单条表达式内从左到右依次求值的执行顺序。

这类题在真实笔试里出现频率很高，因为能很直接地区分“背过语法”和“真正理解执行过程”的人。我一个朋友当时选的是3，他把i++和++i混在一起算了，以为两个自增互相抵消。实际上只要记住一点：每个子表达式求值时，都要先看当前i的实时值，再根据前缀/后缀决定返回值和自增顺序，就不会错。

2.2 基本类型自动提升：short加short到底行不行

还有一道题问的是：

short a = 1; short b = 2; short c = a + b; // 这里会编译报错吗？

当时有相当一部分人选了“不会报错”，理由是short范围足够存下3。但实际答案是：编译报错。原因是Java语言规范规定，short、byte、char在参与算术运算时，会自动提升为int类型再计算，所以a + b的结果类型是int，直接赋值给short变量属于窄化转换，必须显式强转。

short c = (short) (a + b); // 这样才能编译通过

为什么Java要这样设计？核心是避免运算过程中溢出。short范围是-32768到32767，如果两个short相加的结果超过这个范围，不提升到int就会静默溢出。提升到int做运算，至少保证了中间结果不容易溢出，这也是C语言和Java在整数运算上的一个重要区别。

做题时的延伸思考：既然short做运算会提升为int，那代码里大量使用short其实不会省内存，反而会引入强转的麻烦。在真实企业级应用里，业务代码很少用short，基本都是int起步。但笔试题考这个，是因为它能测试出你是否真正理解Java类型系统的设计逻辑，而不是停留在“能跑就行”的层面。

2.3 字符串比较：==和equals背后的存储机制

字符串相关的题目几乎是所有Java笔试的必考题，用友这套也不例外。其中有道题是这样的：

String s1 = "hello"; String s2 = "hel" + "lo"; String s3 = new String("hello"); String s4 = s3.intern(); System.out.println(s1 == s2); // 第1行 System.out.println(s1 == s3); // 第2行 System.out.println(s1 == s4); // 第3行 System.out.println(s3 == s4); // 第4行

这道题我做的时候没有犹豫，因为它是字符串常量池的经典考法。先说结论：第1行输出true，第2行输出false，第3行输出true，第4行输出false。

逐行解释一下。s1 = "hello"，字符串字面量在类加载时会被放入运行时常量池，s1指向常量池中的“hello”。s2 = "hel" + "lo"，由于“hel”和“lo”都是编译期常量，编译器会在编译阶段直接拼接成“hello”，所以s2也指向常量池里的同一个对象，因此第1行是true。

s3 = new String("hello")，关键字new强制在堆中创建一个新的String对象，它和常量池中的“hello”是两个不同对象，所以第2行是false。s4 = s3.intern()，intern方法会检查常量池中是否已有内容相同的字符串，如果有，返回常量池中的引用，所以s4和s1指向同一个对象，第3行是true。而s3是堆里的对象，s4是常量池的对象，两者不同，第4行是false。

注意：从JDK 7开始，字符串常量池从方法区移到了堆中，但“常量池对象”和“普通堆对象”仍然是两个对象。intern返回的是常量池中的引用，这个语义一直没变过。

这道题给我们的启发是：判断两个String是否相等，永远用equals，别用==。笔试题考==只是为了让你理解JVM层面的对象存储机制，真实项目中用==比较String几乎是必出bug的节奏。

3. 面向对象与字符串机制：封装、继承和多态的深度考点

3.1 静态方法没有多态性

用友这套卷子继承部分有道题，我当时差点选错：

class Parent { public static void say() { System.out.println("Parent"); } } class Child extends Parent { public static void say() { System.out.println("Child"); } } public class Demo { public static void main(String[] args) { Parent p = new Child(); p.say(); } }

问输出结果。答案是“Parent”。这里的关键点是：静态方法属于类，不属于实例对象，不参与多态。p.say()虽然在代码形式上是通过对象调用，但实际是在编译期间根据引用类型Parent来决定调用哪个方法，所以输出Parent。

这个知识点很多人会混淆，因为实例方法在相同场景下会输出“Child”，这是动态绑定/重写的效果。而静态方法本质上是“隐藏”而不是“重写”，子类定义同名静态方法只是把父类的隐藏了。Java官方文档里也明确说，static方法不能重写，只能隐藏。

当时的做题心得：看到“static + 继承”组合时，要立刻切换到“编译期绑定”的思维模式。只要引用类型是Parent，调用静态方法就只看Parent里有没有这个方法。这和实例方法看“运行期实际类型”是完全不同的规则。

3.2 finally与return的执行顺序问题

异常处理部分也是重头戏，其中有一道题考察finally块对返回值的影响：

public static int test() { int i = 1; try { return i; } finally { i++; } } public static void main(String[] args) { System.out.println(test()); }

问最终输出。答案是1。虽然finally块里的i++确实执行了，i会变成2，但return语句在离开try块之前，已经把返回值1复制到了返回值槽（或者理解为临时保存了一份），finally里对局部变量i的修改不会影响已保存的返回值。

但如果把题目改成这样，结果就完全不同了：

public static int test() { int i = 1; try { return i; } finally { return ++i; } }

这种情况下输出是2，因为finally块里的return会直接覆盖try中的返回值。而且如果finally块里有return，try中的return就永远不会真正返回了，异常也会被吞掉。

注意：finally中的return是非常危险的写法，它会掩盖try块中的返回值甚至异常。实际项目中不应该在finally里写return。

做题时还有一点值得留意：如果try块中有System.exit(0)，finally块不会执行，因为JVM已经终止了。这个属于“安全退出”类的考察点，偶尔也会在选择题里出现。

3.3 Integer缓存与自动装箱

基础类型的包装类也是高频考点，尤其是Integer的缓存机制。题目大概是这样的：

Integer a = 100; Integer b = 100; Integer c = 200; Integer d = 200; System.out.println(a == b); // 第1行 System.out.println(c == d); // 第2行

第1行输出true，第2行输出false。原因在于自动装箱实际上调用的是Integer.valueOf(int)，而valueOf方法内部有一个缓存数组，默认缓存范围是-128到127。在这个范围内的整数，valueOf返回的是缓存数组中的同一个Integer对象，所以a == b指向同一对象，结果是true。超出这个范围，valueOf会每次new一个Integer对象，所以c == d是两个不同对象，==比较结果是false。

这个缓存范围可以通过JVM参数-XX:AutoBoxCacheMax调整，但默认就是-128到127，背这个数字的时候也要理解为什么是127：因为Java规范中规定“如果被装箱的整数值在-128到127之间，必须装箱成缓存中的对象”，低边界-128是固定的，高边界127是JVM实现的选择，HotSpot允许调大但不允许调小。

这题的实战意义在于：写代码做整数值比较时，如果值可能超出缓存范围，一定用equals或者intValue。用==比较Integer是典型的“本地跑得好好的，上生产就出bug”的问题，因为数据分布变了，哈希值超过127后==就不再等于equals了。

4. 集合框架与容器扩容机制：HashMap和ArrayList的底层秘密

4.1 HashMap的容量、负载因子与树化阈值

集合部分几乎必考HashMap，用友这套题里出现了好几道相关题目，包括：

HashMap的默认初始容量是多少？默认负载因子是多少？为什么链表长度超过8且数组长度不低于64时转为红黑树？

默认初始容量是16，默认负载因子是0.75。这两个数字背后都有一定的权衡逻辑。16之所以选它，是因为它是2的幂，HashMap计算桶下标时用(n - 1) & hash代替取模，只有当n是2的幂时，n - 1的低位才全是1，才能保证哈希值均匀分布在各个桶上。

负载因子选0.75而不是1.0，是空间和时间的一个折中。负载因子越低，数组扩容越频繁，空间浪费越多，但碰撞减少，查找效率提升；负载因子越高，空间利用率越高，但碰撞概率增大，链表变长，查询效率下降。0.75是一个经过统计学和工程实践验证的相对均衡值。

至于树化阈值为8，是因为在理想情况下，哈希函数足够随机时，桶内元素个数服从泊松分布。负载因子0.75时，单桶链表长度达到8的概率已经低于千万分之一。也就是说，出现8个元素挂在同一个链表上，说明哈希函数大概率出了严重问题（比如key分布不均匀），这时候用红黑树进行补偿是值得的。红黑树节点大约是普通链表节点的2倍大小，所以不能轻易树化，8这个阈值兼顾了概率判断和内存开销。

// JDK 1.8 HashMap中树化的经典条件 if (binCount >= TREEIFY_THRESHOLD - 1) { // binCount >= 7 treeifyBin(tab, hash); } // treeifyBin方法里还有容量判断 if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY) { resize(); // 容量不足64时，优先扩容而不是树化 }

这里有个细节值得注意：链表长度达到8还不够，还要求数组长度不小于64。如果数组长度没到64，HashMap会优先扩容而不是树化。原因在于，容量小的时候，扩容能让哈希值的高位参与重新分布，往往就能把长链表打散，不需要用红黑树来救场。

4.2 ArrayList扩容时为什么是1.5倍

另一道印象深刻的题是：

ArrayList默认容量是多少？扩容时每次增加多少？

ArrayList底层是Object数组，默认容量是10，但JDK 8有一个优化：无参构造创建ArrayList时，底层数组指向一个空的共享数组DEFAULTCAPACITY_EMPTY_ELEMENTDATA，真正第一次add时才扩容到10。这样做的好处是，创建大量空ArrayList时不浪费内存。

扩容时，ArrayList执行的是int newCapacity = oldCapacity + (oldCapacity >> 1);，也就是增加原来容量的一半，即1.5倍。为什么是1.5倍而不是2倍？如果每次都翻倍，内存浪费太明显；如果增长太少，比如1.25倍，那么频繁add需要反复复制数组，性能下降。1.5倍是性能和空间的一个平衡点，在大多数场景下既能减少扩容次数，又不会造成过大的内存闲置。

// JDK 8 ArrayList.grow方法中的核心逻辑 int newCapacity = oldCapacity + (oldCapacity >> 1); if (newCapacity - minCapacity < 0) { newCapacity = minCapacity; } if (newCapacity - MAX_ARRAY_SIZE > 0) { newCapacity = hugeCapacity(minCapacity); } elementData = Arrays.copyOf(elementData, newCapacity);

做题时看这个代码会注意到一个容易忽略的坑：如果oldCapacity >> 1后，newCapacity仍然小于minCapacity（也就是用户通过ensureCapacity明确要求的最小容量），会直接把minCapacity当作新容量。这就是为什么addAll大集合时，ArrayList不会只按1.5倍扩容，而是直接扩到足够容纳所有元素的大小。

4.3 HashSet为什么能保证元素不重复

HashSet的题目相对简单，但考察思路值得注意：

HashSet是如何保证元素不重复的？

答案：HashSet底层就是一个HashMap，add方法实际上是map.put(e, PRESENT)，这里的PRESENT是一个常量Object对象，只作为占位value存在。HashMap的put操作会先看key是否已存在，判断标准是先比较hash值，再使用equals比较内容。如果key已存在，put会返回旧的value；如果不存在，返回null。

所以HashSet的去重逻辑完全依赖于HashMap的key去重逻辑，而HashMap要求存入的key要正确重写hashCode和equals。如果一个自定义对象放到HashSet里却没有重写这两个方法，就会出现两个“内容相同”的对象同时存在于Set中，因为默认的hashCode是对象的内存地址。

当时做题时我提醒自己注意：HashSet的底层是HashMap，TreeSet的底层是TreeMap（红黑树），LinkedHashSet的底层是LinkedHashMap，这三兄弟的底层数据结构一定要分清楚。面试官特别喜欢问“XX的底层实现是什么”，本质上是在考察你是否能从一个类的源码推导出整套数据结构原理。

5. JVM内存与异常处理实战：从OOM到垃圾回收

5.1 常见OOM类型与对应内存区域

用友这套题里JVM相关的题目主要围绕内存区域展开。有一道题列出了几个异常，要选出哪些属于OutOfMemoryError：

• java.lang.OutOfMemoryError: Java heap space
• java.lang.StackOverflowError
• java.lang.OutOfMemoryError: Metaspace
• java.lang.OutOfMemoryError: unable to create new native thread

逐个分析。Java heap space是堆内存溢出的经典错误，通常是因为对象创建过多或存在大对象，且GC无法及时回收。StackOverflowError是栈溢出，严格来说它不算OOM，它表示栈深度超过了JVM允许的最大深度，最常见的触发场景是无终止条件的递归调用。Metaspace是JDK 8之后元空间溢出的错误，元空间存放类的元数据和静态变量，如果动态生成类过多就会触发。unable to create new native thread表示无法创建新的本地线程，属于操作系统层面的资源耗尽，通常和栈内存、进程句柄数限制有关。

做题时的关键判断点：OOM是“内存区域不够了”，StackOverflowError是“栈帧太深了”，这两者不能混淆。很多人把StackOverflowError也当成OOM的一种，严格来说，StackOverflowError继承自VirtualMachineError，和OutOfMemoryError是平级关系，不是子类关系。

5.2 可达性分析与GC Roots

关于垃圾回收的题目里，有一道问：

下面哪些对象可以作为GC Roots？

GC Roots是可达性分析的起点，主要包括四类：

1. 虚拟机栈（栈帧中的本地变量表）中引用的对象
2. 方法区中静态属性引用的对象
3. 方法区中常量引用的对象（如字符串常量池中的引用）
4. 本地方法栈中JNI引用的对象

理解GC Roots的核心在于：GC Roots是“从外部可达的、存活的对象”的入口，GC扫描时从这些根出发，沿着引用链遍历，能到达的对象就是存活的，不能到达的就会被判定为可回收。

注意：JDK 7之后，字符串常量池移到了堆中，所以“方法区中常量引用的对象”这个说法在实现细节上已经发生了变化，但它在抽象层面的含义依然成立——它就是根集合的一部分。

做题时容易被绕进去的一点是“局部变量但已不再使用的对象”。一个局部变量在作用域内声明了，它的引用计数/GC Roots引用是存在的，但如果后续代码没有再使用它，JVM的即时编译器可能做优化，把变量置为null或清空引用，这在某些场景下会影响GC行为。笔试一般不会考到这个层面，但面试可能会追问。

5.3 try-with-resources比finally好在哪

异常处理部分除了前面说的finally和return问题，还有一道关于资源关闭的题：

JDK 7引入的try-with-resources相比传统try-finally有什么优势？

它最大的优势是自动关闭资源和异常抑制机制。传统写法里，如果try块抛异常，finally块里的close又抛异常，那么finally里的异常会覆盖try里的原始异常，导致问题难以排查。try-with-resources会在关闭资源时，如果close也失败，会把关闭异常作为抑制异常添加到原始异常的suppressed列表里，最终抛出的仍然是原始异常，但可以通过getSuppressed()方法拿到所有被抑制的异常。

// 传统写法：资源关闭异常可能覆盖原始异常 BufferedReader reader = null; try { reader = new BufferedReader(new FileReader("a.txt")); String line = reader.readLine(); } finally { if (reader != null) { reader.close(); // 如果这里抛异常，会吞掉try块的原始异常 } } // try-with-resources写法：自动且更安全 try (BufferedReader reader = new BufferedReader(new FileReader("a.txt"))) { String line = reader.readLine(); }

这个知识点在笔试题里看起来简单，但实际开发中价值很高。资源关闭是比较容易出线上问题的环节，文件流、数据库连接、网络连接都有类似的关闭需求。用try-with-resources写出来的代码更简洁，也不会因为关闭顺序或异常覆盖问题产生隐蔽bug。

6. 并发编程与Java新特性：volatile、synchronized与Lambda

6.1 volatile的可见性与不保证原子性

并发部分是整套卷子中区分度较高的内容。有一道题我很喜欢：

public class Counter { private volatile int count = 0; public void increment() { count++; } }

问：两个线程同时调用increment，最终count一定是2吗？答案是不一定。volatile只能保证可见性和禁止指令重排序，不能保证操作的原子性。count++在字节码层面是三步：读取count、将count加1、写回count。两个线程可能都读到同一个初始值0，然后各自加1写回，最终结果是1而不是2。

要让count自增变得线程安全，可以用AtomicInteger，或者给方法加synchronized，或者用LongAdder（高并发场景下性能更好）。volatile的适用场景是“单个线程写、多个线程读”的标记位，比如开关变量、状态标志。

做题时我给自己强调了一个判断标准：如果操作是“读-改-写”一体的，volatile基本扛不住；如果只是“一个线程修改，其他线程读取最新值”，volatile就够了。

6.2 synchronized与ReentrantLock的对比

还有一道题是：

synchronized和ReentrantLock有什么区别？

我把当时整理的要点写一下。synchronized是JVM层面的关键字，基于Monitor锁实现，JDK 6之后有锁升级机制，从偏向锁到轻量级锁再到重量级锁，大多数场景下性能很好，而且用法简单，不需要手动释放锁，异常时自动释放。

ReentrantLock是JDK层面的API，基础是AQS，提供了synchronized没有的能力：可中断地获取锁（lockInterruptibly）、超时获取锁（tryLock(timeout)）、支持公平锁（构造传入true）、支持多个Condition条件队列。

它们俩都是可重入的，可重入意思是同一个线程可以多次获得同一把锁而不死锁。synchronized的可重入是基于锁的持有者线程计数，ReentrantLock是基于AQS的state状态计数。

注意：公平锁和非公平锁的差异，笔试常考。非公平锁是默认的，原因是减少线程切换开销，吞吐量通常更高；公平锁能避免线程饥饿，但性能略低。不要为了“公平”而盲目开启公平锁，没有明确业务需求时用默认即可。

6.3 Lambda表达式与匿名内部类的区别

Java新特性部分，Lambda是必考项。有一道题是：

Lambda表达式和匿名内部类有什么区别？

核心区别有三点：

第一，Lambda表达式必须是函数式接口（只有一个抽象方法的接口），匿名内部类可以是抽象类，也可以是有多个方法的接口。比如new Runnable(){...}能被Lambda替换，但new MyAdapter(){...}只要是抽象类，就不能用Lambda替换。

第二，Lambda表达式不生成独立的class文件，而是通过invokedynamic指令在运行时动态生成实现类，而匿名内部类在编译阶段就会生成单独的class文件，所以大量使用匿名内部类会增加类加载压力。刷过字节码的应该知道，每个匿名内部类都对应一个OuterClass$1.class文件。

第三，Lambda表达式中的this指向的是外部类的实例，因为Lambda没有自己的作用域，而匿名内部类里的this指向的是匿名内部类自身。这个区别在写回调代码时尤其重要，如果你在匿名内部类里引用外部对象，需要写成Outer.this.xxx；而Lambda里直接写this.xxx就是外层对象的方法。

还有一点容易被忽略：Lambda表达式访问外部局部变量时，要求该变量是effectively final的，也就是变量被赋值后不再改变。这是JVM实现lambda捕获机制的限制，因为Lambda可能被延迟执行，如果捕获的变量后续又变了，语义上会出问题。

6.4 枚举类型：不只是“一组常量”

枚举也是Java新特性中的高频考点。用友这套题里有一道问：

枚举可以定义在类内部吗？枚举可以定义抽象方法吗？

答案是：枚举可以定义在类内部，普通内部类的修饰符限制不完全适用于枚举，枚举本身就是一种类，它有自己的构造器、字段、方法，甚至可以实现接口、定义抽象方法。

枚举的核心知识点在于：定义一个枚举常量时，实际上是在创建该枚举类的一个实例。枚举构造器默认是private的，不能通过new创建实例。枚举可以定义抽象方法，每个枚举常量必须实现该方法，这种用法在实现状态机时特别有用。

还有一个细节：所有枚举都隐式继承java.lang.Enum类，所以枚举不能继承其他类，但可以实现接口。枚举实现接口是常见的设计，比如定义公共行为接口，让不同枚举常量提供不同实现。面试时如果能把这层关系讲清楚，会显得你理解得很透。

7. 易错点复盘与笔试答题方法论

7.1 高频易错点速查表

做完一整卷题，我把自己踩过的坑和容易混淆的点整理成了一张速查表，这部分内容不仅在笔试中有用，在实际面试面对“八股文”提问时也是很好的复习提纲。

这类表在笔试复习阶段特别有用。每整理一条，我都会在IDE里写个小Demo跑一遍，确认自己理解的执行结果和实际运行结果一致。实践证明，纸上谈兵和真正跑一遍的差距非常大，很多你以为懂了的知识，跑完代码才发现理解有偏差。

7.2 选择题的排除法技巧

用友这套卷子的选择题，很多答案不是一眼能看出来的，但用排除法往往能大幅提高正确率。比如字符串比较的题目，先把“==比较内容”这个错误的选项排除，再把“equals比较地址”排除，剩下的选项通常就清晰了。

做Java基础题我习惯分三步走：第一步，确认题目的考察方向（运算符、集合、JVM、并发，还是新特性）；第二步，在脑海中回忆对应的底层机制（比如HashMap的put流程、Integer的缓存机制、volatile的内存语义）；第三步，把题目里的具体值套进机制里推演。如果某个选项涉及到精确数值（比如默认容量、负载因子、树化阈值），直接回忆源码，不要靠猜。

还有一个技巧：多选题拿不准时，宁少选不多选。很多笔试题多选漏选给一半分，错选不给分，所以拿不准的选项就不选。我当时就是因为多选了一道关于垃圾回收器的题目，多选了一个G1的特性，结果整题零分，非常可惜。

7.3 编程题的实战建议

用友这套题的最后有一道编程题，我记得是链表的简单操作题，考察的是链表反转或者删除指定节点。这类题不涉及复杂算法，更多是考察编码基本功、边界条件处理和代码规范。

写编程题时，我总结了几个实用建议：

第一，先写思路再写代码。哪怕只是简单写三五行注释，也能帮自己理清逻辑，尤其是处理链表、数组这类边界敏感的题目。

第二，单独处理空指针和边界情况。链表的头节点为空、数组长度为0、目标值不存在，这些情况都要在代码中显式处理，不能被用例绕过。

第三，命名规范要清晰。变量名不要用a、b、c这种无意义的名字，至少用node、current、prev这类有意义的名词。面试官看代码时会关注代码可读性，这反映你的工程素养。

第四，写完代码后一定手动跑一遍测试用例。用一个小例子在纸上推演，可以快速发现越界、空指针、循环条件写错等问题，比提交后再后悔好得多。

7.4 如何系统化准备Java笔试

最后，说一套我自己用下来比较有效的方法，核心就四个字：以题为镜。不要盲目刷题，而是每做一道错题，就把它对应的知识点在源码层面查一遍，再向外扩展两三个关联的知识点。

比如做错了一道关于HashMap树化的题，就去看HashMap源码里treeifyBin方法，搞清楚为什么容量不足64时优先扩容；顺藤摸瓜再看红黑树和普通的区别、为什么插入用红黑树而不直接用平衡二叉树；再往外延伸到ConcurrentHashMap的树化条件为什么是数组容量大于等于64，它和HashMap的树化条件有什么异同。

这种“一题串一片”的复习方式，比我当年死记硬背“面试八股文”效率高得多。因为死记硬背只能应付原题，而“以题为镜”能帮你建立知识点之间的连接，遇到没见过的变体也能从原理出发推导出答案。

还有一种方式是看真实业务场景来反推考点。用友这类做ERP和财务软件的公司，代码里会大量处理单据流、审批流、报表计算等偏业务逻辑的内容，但笔试题不考业务，只考基本功。原因很简单：业务可以入职后学，但Java基础要是不过关，团队根本不敢把核心模块交给你。所以准备笔试时要抓大放小，把集合源码、JVM内存、并发机制这三座大山啃透，通过率会高很多。

这套卷子做完之后，我最大的体会是：企业级应用的笔试，重点不在于你刷了多少题，而在于你是否真的理解Java这门语言的底层运作方式。HashMap的每一次扩容、Integer的每一次装箱、String的每一次拼接，背后都是JVM在设计时做出的权衡。把这些权衡逻辑搞清楚了，不光是应付笔试，写业务代码时也能自然地避免很多坑。