从恒生笔试题看开发岗基本功：并发、数据结构与底层能力

前几天整理旧资料，翻出一份恒生公司2015年秋招开发类的笔试题。10年前的笔试题放到今天看，很多考点依然眼熟——手写链表反转、String比较、SQL优化、Linux查日志。这年头大家张口闭口都是agent开发、AI应用开发，好像不会点新框架就不好意思投简历，但真正到了笔试环节，考的还是那些底层的、不随框架迭代而失效的东西。

这篇文章不是要逐题报答案，而是想借恒生这套题，把开发类笔试的考察逻辑、核心考点和准备方法完整拆一遍。不管你是准备校招的应届生，还是打算跳槽的工程师，只要目标是开发岗，这套基本功的复习框架都值得对一遍。我会按题型逐类展开，补充完整解题思路和踩坑点，确保你看完能直接拿去用。

1. 一份2015年的恒生笔试题，为什么值得现在翻出来看

1.1 恒生这家公司想招什么样的人

恒生的业务主要围绕金融IT展开，证券、银行、基金、保险这些核心交易与清算系统很多都跑在他们家的软件上。这类系统的共同特点是：不能宕机、不能算错账、高并发下还要保证数据一致。所以恒生笔试的开发者筛选逻辑非常明确——先看基础功底过不过关，再看有没有工程意识，最后才看你会不会某个具体框架。

这跟互联网大厂的海量算法题路线不太一样。金融IT更看重你对内存、并发、事务、数据一致性这些概念的理解深度。2015年的笔试题里就已经大量出现线程安全、锁、数据库隔离级别这类题目，因为在真实的交易系统里，一个并发处理不当就是真金白银的损失。

从这层业务背景出发，你就能推断出一份合格笔试考卷的选题倾向。基础数据结构和算法一定会有，但占比不会像互联网公司那么极端；操作系统、计算机网络、数据库、Linux命令这些“硬功夫”会占相当大的篇幅；Java或C++的语法陷阱题也是标配，用来筛掉那些只背过框架API的简历型选手。

1.2 这套卷子的题型分布与考察逻辑

一份典型的开发类笔试卷，通常由选择题、填空题、简答题、程序输出题、手写代码题和SQL题组成。2015年恒生的这份卷子基本也是这个结构。我按记忆里的常见分布归纳如下，你可以当成一张复习地图：

很多同学复习时喜欢死磕算法题，但这类笔试里真正拉开差距的，往往是那些“看起来简单”的程序输出题和SQL题。你以为是考语法，实际上考的是你平时写代码时有没有真正理解内存模型、执行顺序和异常处理机制。这些内容在IDE里跑一遍看不出差别，但一到笔试就容易翻车。

2. 从金融IT业务场景反推考察重点：并发、事务与基础功底

2.1 为什么并发和锁是必考中的必考

金融系统的核心场景是交易。成千上万个用户同时买入卖出，同一个账户可能被多个请求同时操作。如果账户余额的扣减没有做好并发控制，轻则数据错乱，重则资金事故。所以恒生笔试里出现并发相关题目，几乎是必然的。

2015年那会儿Java 8刚普及不久，ConcurrentHashMap、ThreadLocal、synchronized与ReentrantLock的区别这类问题就已经是高频考点了。放到今天来看，这些问题依然是Java岗笔试的常客。还有一个特别经典的手写题：用两个线程交替打印奇偶数，考察wait/notify配合synchronized的熟练度。

这类题目的考察重点不是你会不会调API，而是三个层次：

1. 能不能说清楚并发问题的本质——可见性、原子性、有序性
2. 能不能给出正确的同步方案——锁、 volatile、CAS、并发容器分别解决什么问题
3. 能不能识别出错误方案——比如用double check却忘了加volatile

拿账户扣款这个场景举例，很多人的第一反应是给方法加synchronized。这确实能保证线程安全，但在高并发下性能堪忧。更合理的方式是使用乐观锁，通过CAS或版本号机制在更新时校验数据是否被修改过。这个思考过程本身就是一道隐形的加分题，笔试不一定直接问，但答题时的设计思路会体现在字里行间。

2.2 数据库事务的考察在金融IT笔试中的分量

交易系统的另一个核心诉求是数据一致性。转账、对账、清算这些环节都依赖数据库事务。因此，数据库部分在恒生这类公司的笔试题里，比重明显高于一般互联网公司。

我印象里最常考的题型是：给一个并发转账场景，问你不同事务隔离级别下会出现什么问题。

脏读、不可重复读、幻读这三个概念，表面上看起来差不多，实际考察的是你对锁和MVCC的理解深度：

笔试作答时加一句“MySQL InnoDB在可重复读级别下通过MVCC解决了快照读的幻读问题，但当前读仍需依赖间隙锁”，这个深度一下就拉起来了。这比单纯背表格要加分太多，因为它说明你真看过底层实现。

3. 数据结构与算法题：高频手写代码的完整得分思路

3.1 单链表反转：一道题测出指针功底

单链表反转是手写代码题里出场率最高的题目之一，因为它短小精悍，却能把一个人的指针操作基本功暴露得干干净净。笔试考场上时间紧张，很多人一紧张就把链表指针指来指去指乱了。

迭代版是最稳的写法，思路就一句话：遍历链表时，把当前节点的next指向前一个节点。代码如下：

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

这段代码有几个笔试中特别容易扣分的点：

1. 必须先保存curr.next，否则改完指针后链表就断了
2. 循环结束条件是curr != null，不是curr.next != null
3. 最后返回的是prev，不是curr（此时curr已经是null）

递归版本也经常被要求写，虽然实际工程中不常用，但考察的是递归思维：

public ListNode reverseList(ListNode head) { if (head == null || head.next == null) { return head; } ListNode newHead = reverseList(head.next); head.next.next = head; head.next = null; return newHead; }

我建议两个版本都背熟。考场上如果时间充裕，可以写完迭代版后再补一句“递归版本也可以实现，核心是让head.next.next指向head”，这句话能体现你对同一问题的多角度理解。

3.2 二分查找变体：边界条件才是真正的考点

直接考二分查找有点太简单，所以笔试更常见的是变体题。比如“在一个有序数组中查找第一个等于目标值的下标”或者“查找最后一个小于等于目标值的元素”。

这类题的难点不在二分思想本身，而在边界条件的处理。我总结的通用模板是：

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

写这类题时，我建议每次循环都手动走一遍：

1. mid的计算用left + (right - left) / 2，避免left + right溢出
2. 当前值大于等于target时，把右边界收到mid - 1，找到等于target的元素后不急着返回，继续往左找
3. 循环结束后检查result是否被更新过，没更新说明数组里没有目标值

考场上最容易犯的错是：找到第一个等于target的元素就直接return，结果忽略了“第一个”这个限定条件。这恰恰是出题人设置的陷阱。

3.3 用两个栈实现队列：数据结构联动的经典设计题

这道题考察的是你对栈和队列本质特性的理解。栈是后进先出，队列是先进先出，怎么用两个栈模拟出先进先出的效果？思路其实很巧妙：

入队时，直接往stack1里push。出队时，先把stack1里的元素全部弹出并push到stack2里，再pop stack2的栈顶。这样stack2的栈顶就是最先入队的元素。

class MyQueue { private Deque<Integer> inStack; private Deque<Integer> outStack; public MyQueue() { inStack = new ArrayDeque<>(); outStack = new ArrayDeque<>(); } public void push(int x) { inStack.push(x); } public int pop() { if (outStack.isEmpty()) { while (!inStack.isEmpty()) { outStack.push(inStack.pop()); } } return outStack.pop(); } }

注意一个关键优化：只有当outStack为空时，才需要把inStack的元素倒过去。如果outStack里还有元素，直接pop即可。这个“懒惰倒腾”的思路能让均摊时间复杂度降到O(1)。

这道题还喜欢延伸问：两个队列怎么实现栈？反过来想就行——入栈时把元素放到非空队列，出栈时把前n-1个元素移到另一个队列，剩下的就是栈顶。这类题目没有背诵价值，但理解了“用数据结构特性去模拟另一种数据结构”的思路后，现场推演也不怕。

4. 语言的陷阱题：String、集合与JVM内存那些“送命题”

4.1 String、StringBuilder、StringBuffer到底怎么选

这道题几乎年年出现在Java岗笔试试卷里，恒生2015年的卷子也没放过。很多人能背出结论：String不可变、StringBuilder线程不安全但快、StringBuffer线程安全但慢。但笔试问法通常更刁钻，比如给一段字符串拼接代码，问创建了几个对象。

String s = "a" + "b" + "c";

这行代码在编译阶段就会直接优化成"abc"，运行时不会额外创建对象。但如果写成：

String s = ""; for (int i = 0; i < 10; i++) { s += i; }

那就会在循环里创建大量String对象。因为字符串拼接的本质是每次new一个StringBuilder，append后再toString。循环多少次就创建多少个临时对象。这个执行过程笔试简答题如果让你分析性能瓶颈，标准答案就是：循环内字符串拼接应直接使用StringBuilder。

4.2 ==、equals和hashCode：三个概念串起一整套约定

这类题出成程序输出题时，迷惑性特别强：

Integer a = 127; Integer b = 127; Integer c = 128; Integer d = 128; System.out.println(a == b); System.out.println(c == d);

很多人一看Integer是对象，觉得==比较的是引用，应该都是false。但正确答案是true和false。原因在于IntegerCache默认缓存了-128到127之间的Integer对象，所以a和b指向同一个缓存对象，c和d则各自new了新对象。

这个知识点不只在笔试里有用，实际开发中同样容易踩坑。比如用==比较两个Integer变量，在127以内没问题，超过127就会出错。这也是为什么阿里巴巴Java开发规范里明确要求：所有整型包装类对象之间值的比较，全部使用equals方法。

hashCode与equals的约定也是必考项。核心要点就一句话：两个对象equals相等，hashCode必须相等；hashCode相等，equals不一定相等。重写equals时必须重写hashCode，否则HashMap、HashSet这些依赖hash的集合就会出现逻辑错误。

4.3 HashMap的底层结构演变与扩容机制

HashMap在2015年的笔试里就已经是常客了。那会儿JDK 8刚发布，数组+链表+红黑树的结构刚引入不久，很多人还没反应过来。放到现在，这个问题基本上已经成了Java笔试的必问项。

核心考点有三个维度：

1. 数据结构：数组+链表，链表长度超过8且数组长度超过64时转为红黑树
2. put流程：先计算key的hash，定位到数组槽位，如果该位置为null直接放入，否则遍历链表/红黑树判断key是否存在，存在则覆盖，不存在则新增
3. 扩容机制：默认负载因子0.75，容量达到阈值时扩容为原来的两倍

还有一个容易被问到的点：为什么HashMap允许key为null，而ConcurrentHashMap不允许？因为HashMap本身不是线程安全的，它可以将null映射到数组的0号槽位；而ConcurrentHashMap的并发控制依赖于key的hash值，null的hash无法参与计算，同时设计上也不希望在并发场景下出现歧义。

4.4 抽象类、接口与final/finally/finalize

这道题在选择题里出现频率极高，但很多人只记住了“抽象类可以有构造方法，接口不能”这类表面结论。更深入的考察方向是：JDK 8之后接口增加了默认方法和静态方法，这个设计是为了解决什么问题？

答案是接口的演进需要兼容性。在JDK 8之前，给接口加一个新方法意味着所有实现类都必须同步实现，否则编译报错。新增默认方法后，可以在不破坏现有实现的情况下给接口增加新能力。这和Java 9的模块化、Java 17的密封类一样，都是Java在向后兼容和向前演进之间的取舍智慧。

final/finally/finalize这三个长得像的兄弟也是选择题的常客。final是修饰符，finally是异常处理的关键字，finalize是Object类里的一个方法。笔试里常挖的坑是：finally块里的return会不会覆盖try块里的return。答案是会，但正确做法是不要在finally里写return，因为这会吞掉try块里的异常信息。finalize方法从JDK 9开始就被标记为废弃了，不建议依赖它做资源释放。

5. 数据库、操作系统与网络简答题的底层理解模板

5.1 索引为什么用B+树而不是红黑树

这道简答题在开发类笔试里出现的频率极高，恒生这类做交易系统的公司尤其爱问，因为索引设计直接影响数据库查询性能。

从底层来讲，数据库索引需要存储在磁盘上，而磁盘I/O是性能瓶颈。B+树的每个节点能存储多个键值，树的高度更低，一次查询需要访问的磁盘块更少。更关键的是，B+树的叶子节点通过指针串联成有序链表，非常适合范围查询和排序操作，这正对交易系统里常见的时间区间查询场景。

回答这道题的完整层次是：

1. 数据库数据量大，无法全部载入内存，必须考虑磁盘I/O次数
2. 树的高度决定查询时需要访问的磁盘块数量，B+树的矮胖结构优势明显
3. 叶子节点有序链表让范围查询只需要顺序遍历，避免回溯
4. 非叶子节点只存储键不存储数据，单节点能容纳更多键，进一步降低树高

如果你能再补一句“红黑树更适合内存中的场景，比如TreeMap和JDK 8的HashMap树化”，这个对比就更立体了。

5.2 TCP三次握手为什么不是两次

网络题在开发类笔试里主要考TCP/IP协议栈。最经典的就是三次握手的“为什么”。标准答法是：三次握手可以防止已失效的连接请求报文段突然又传到服务器，避免服务器创建无意义的连接并浪费资源。

如果你不想让答案显得像背课文，可以加一句更本质的解释：三次握手的核心目的是让通信双方都确认自己的发送能力和接收能力是正常的。第一次握手，服务器确认客户端的发送能力；第二次握手，客户端确认服务器的发送和接收能力；第三次握手，服务器确认客户端的接收能力。这样双方就完成了双向通信能力的确立。

还有一个高频考点是TIME_WAIT状态。主动关闭连接的一方会进入TIME_WAIT，等待2MSL时间后才真正关闭。原因是：一是为了保证最后一个ACK报文能够到达对端，如果丢了对端会重发FIN；二是为了让本连接内所有延迟的报文在网络中自然消失，避免干扰新的连接。做高并发服务端开发的同学，对TIME_WAIT导致端口耗尽的问题应该有切身体会。

5.3 死锁的必要条件与避免策略

操作系统里的死锁题也是简答题常客。四个必要条件得背熟：互斥条件、请求与保持条件、不可剥夺条件、循环等待条件。笔试如果考简答题，除了列条件，最好再各加一句解释。

更进阶的考察方式是给一段并发代码，问你有没有死锁风险，或者直接让你设计一个避免死锁的方案。在实际工程里，最常见的做法是破坏循环等待条件——对多个资源进行排序，所有线程都按相同顺序加锁。这个方案简单高效，代价是需要程序员在编码时严格遵守约定。

比如一个转账场景，A账户转给B账户，B账户同时转给A账户。如果两个线程分别先锁A再锁B、先锁B再锁A，就很容易形成死锁。解决办法是无论从A转B还是B转A，都先锁账户id较小的那个，再锁较大的那个。这样两个线程的加锁顺序一致，循环等待就被打破了。

6. Linux命令与日志排查：笔试中的实操题拿法

6.1 面试官通过几道命令题筛掉“简历型选手”

不管你是面后端开发还是做嵌入式开发，Linux命令几乎都是必考项。恒生这类维护大量服务器的金融科技公司，更看重工程师能否在Linux环境下快速定位线上问题。

笔试中常见的考察形式是：给你一个线上故障场景，让你写出排查命令。这些题目没有太高技术含量，但没在服务器上实战过的人，很容易卡壳。我整理了一张高频命令速查表，可以直接当复习提纲：

6.2 三个典型的日志排查笔试场景

场景一：线上接口突然变慢，怎么定位。标准思路是先top看CPU和内存，再用jstack看Java线程状态，再用jstat看GC情况。笔试不需要写jstack的具体用法，但能把jstack、jstat、top、free这几条命令按排查顺序列出来，就已经合格了。

场景二：统计日志中某个接口的调用次数。假设日志格式是每行一条，包含接口路径和状态码：

2025-01-01 10:00:00 INFO /api/order/create success 2025-01-01 10:00:01 INFO /api/order/create success 2025-01-01 10:00:02 ERROR /api/order/query error

统计接口调用次数可以这样写：

grep "/api/order/create" app.log | wc -l

统计每个接口的调用次数并排序：

awk '{print $4}' app.log | sort | uniq -c | sort -nr

这类题目考察的是你对awk、sort、uniq这些文本处理工具的掌握程度。不需要背复杂脚本，但基本组合用法得熟练。

场景三：定时清理日志。这个在开发同学眼里很基础，但动不动就有人因为磁盘被日志写满导致线上故障。笔试如果问“如何每天凌晨3点清理/tmp下7天前的日志文件”，答案是：

0 3 * * * find /tmp -type f -mtime +7 -exec rm -f {} \;

这个命令的关键点是-mtime +7表示修改时间超过7天，-exec配合{}和;实现对每个文件执行删除操作。笔试填空中容易漏掉最后的反斜杠分号。

7. 笔试现场的时间分配与拿分策略

7.1 发卷后前5分钟决定整场心态

拿到卷子后别急着动笔，先花三到五分钟把整张卷子浏览一遍。重点看三件事：

1. 各题型的数量与分值分布，确定主攻对象
2. 有没有一眼就能答对的送分题，先有个心理预期
3. 手写代码题有几道、复杂度高不高，在心里排个优先级

我个人的策略是：选择题和填空题先快速过一遍，遇到不会的做个标记，不恋战。程序输出题需要静心推演，放到第二梯队。SQL题如果思路明确就顺手做掉。手写代码题留最后，但务必保证有充足时间。

关于时间分配，以一份90分钟、满分100分的卷子为例，我建议这样拆：

7.2 手写代码的“可读性优先”原则

笔试手写代码和平时在IDE里写代码最大的区别是：没有人帮你编译，也没有自动补全。阅卷老师看的是你的思路是否清晰，而不是语法是否完美。

我强烈建议遵循三个原则：

第一，变量命名要见名知意。就算题目里用的是单字母变量，你也要在代码里写出duplicateCount、currentNode这种有语义的名字。阅卷老师看到这种代码，第一印象就会好很多。

第二，宁可多写中间变量，不要追求“一行流”。比如交换两个变量值，老老实实写temp临时变量，比用异或操作三行并成一行要清晰得多。在阅卷场景里，可读性远大于炫技。

第三，算法题写完核心逻辑后，一定补一句注释说明思路。比如在循环前加一行“// 先找到数组中间位置”或“// 快指针先走n步”。这会让阅卷老师确信你不是背代码，而是真的理解解法。

7.3 程序输出题：手动推演比凭感觉靠谱

程序输出题是笔试里最容易丢分也最容易拿分的题型。说它容易拿分，是因为答案就藏在代码执行过程里；说它容易丢分，是因为考生经常凭第一印象直接写答案，忽略了执行顺序和边界条件。

我的做题习惯是：拿一张草稿纸，把涉及的关键变量全部列成表格，一行一行模拟执行。比如遇到for循环里有i++和++i混用，或者if条件里出现了短路运算，就老老实实把每次循环后各变量的值写出来。这个过程看似麻烦，但正确率极高。

另外要特别注意异常处理结构。try-catch-finally块里如果有return，final块里的代码是否还会执行？答案是会。如果在catch块里再次抛出异常，finally块还会不会执行？答案也是会。但finally里如果包含了return，它会覆盖之前的return值。这些输出题里常设的坑，提前了解就不会掉进去。

7.4 不会的题怎么“抢分”

笔试卷子上的每一道题都有分值，哪怕完全不会，也不能空着。这一点对于开发类笔试格外重要，因为很多简答题和设计题都是按点给分，你写对关键概念就能拿到部分分数。

举个具体例子，简答题问“简述你对索引的理解”。如果只背过定义，可以这么写：

“索引是一种帮助数据库高效获取数据的数据结构。底层主要是B+树，它能降低查询的磁盘I/O次数。索引虽然能加速查询，但会降低增删改速度，因为每次修改数据时还要同步维护索引结构。在实际使用中，应该为高频查询字段创建索引，避免对低区分度的字段加索引。”

这段话能拿到基础分，而且第二、三句已经展示了你对索引代价的理解。如果还能补一句“联合索引要遵循最左前缀原则”，得分又会再上一个台阶。这个答题策略的核心是：把自己掌握的所有相关知识都写进去，让阅卷老师看出你的思维过程。

7.5 复盘：考完试比考完试更重要

我个人刷完一套笔试题后，最值的动作是花时间做复盘。不只是对着答案改对错，而是把每道错题对应的知识点重新梳理一遍，找到盲区的根源。

比如手写快排时忘了处理数组为空的边界条件，说明对“防御式编程”的意识不够；程序输出题里漏看了变量自增顺序，说明读代码时不够细心；SQL题里没选对索引列的顺序，说明对最左前缀原则理解不透。每一次错题背后都对应着一个具体的、可修正的习惯问题，这才是笔试真正要筛选的能力。

2015年的恒生笔试题放到今天，题目本身可能过时了，但背后的考察逻辑和复习方法依然是有效的。技术栈会变，框架会更新，但并发控制、数据结构、操作系统、网络协议这些底层能力，才是决定一名开发工程师能走多远的根本。这既是对校招生的提醒，也是对我自己的一次复盘。