2024年秋招我投的是贝壳找房Java工程师被分到了第二批笔试。考完之后最大的感受是这批题对“工程落地”的考查比很多大厂要重它不满足于你背得出八股文还希望你把知识点串起来用到具体的业务场景里。这篇文章我就复盘一下整套笔试的题型、考点、我当时的答复思路以及一些能让你少踩坑的细节给还在等面试通知或者准备下一批的兄弟做个参考。1. 投递与考前准备贝壳这批笔试在考什么1.1 简历投递后的信息收集与技术栈判断投完简历之后大概一周收到笔试链接。我的准备其实从投递当天就开始了先做的事不是刷题而是去了解贝壳找房的技术栈和业务形态。Java在贝壳的存量系统里占大头Spring Boot、Spring Cloud、MySQL、Redis、Elasticsearch、MQ这些都是常见组件房产交易又牵扯到房源搜索、地图找房、经纪人调度、签约流程、资金托管等业务所以并发、缓存、检索和分布式事务经常出现。我翻了一下去年秋招的经验贴贝壳的笔试风格不是单纯的LeetCode刷题而是“Java基础 业务设计”的组合拳。尤其是设计题往往会给你一个和房产交易、房源检索相关的场景让你说说怎么做。这跟我面过的一些做SaaS、电商业务的厂子风格比较像所以我提前把贝壳App端和PC端的找房流程都过了一遍用户进入首页、搜索房源、地图找房、点击详情、约看、下单每一环都可能成为设计题的切入角度。1.2 把复习重心放在Java集合与并发上笔试前我把高频八股梳理了一遍重点放在Java集合源码、并发工具、JVM、Spring、MySQL索引与事务、Redis数据结构。为什么这批笔试会反复考集合和并发因为大部分后端业务都可以抽象成“处理一批数据”和“抗住并发读写”HashMap为什么线程不安全ConcurrentHashMap为什么能并发安全底层是怎么用synchronized和CAS的ArrayList和LinkedList的增删改查复杂度TreeMap和PriorityQueue的排序场景。这些都是贝壳这种流量型平台最常碰到的底层能力所以笔试也爱考。讲一个记忆比较深的点我考前特意把快速排序和冒泡排序的Java实现各写了两遍。原因很简单贝壳笔试算法难度不是竞赛级但经常让你手写经典排序然后把时间复杂度、稳定性、适用场景一起问出来。快排的partition写法如果不熟练在线上编译器里很容易写出边界问题后面编程题部分我会细说。并发部分我主要过了两个考点。一个是synchronized和ReentrantLock的区别synchronized是JVM层面的监视器锁ReentrantLock是JDK层面的可重入锁支持公平锁、可中断、可设置超时。另一个是线程池的核心参数尤其是corePoolSize、maximumPoolSize、workQueue的配合逻辑提交任务时先判断核心线程是否空闲再判断队列是否已满最后判断最大线程数队列满了但线程数没到上限时会创建新线程。贝壳的房源详情页、搜索请求都绕不开线程池和并发控制这类题可以说是必考。1.3 算法题准备方向与资料取舍我备考算法用的是“先掌握高频数据结构和套路再刷少量真题保持手感”的策略。高频结构是数组、链表、二叉树、哈希表、栈/队列、字符串套路就是二分、双指针、滑动窗口、递归和动态规划入门。贝壳第一批笔试的反馈里有人提到字符串处理题和链表题比较多所以我第二批前专门把字符串转整数、括号匹配、合并两个有序链表这类题又过了一遍。其实笔试准备阶段一个最大的坑就是什么都想刷结果什么都没吃透。我个人建议如果你的时间只有一周那就只做三件事——Java集合和并发源码的常见考点SQL的索引与事务场景题手写两三道排序和链表题。时间充裕再补JVM和Spring。贝壳这种厂子笔试真正拉开差距的往往不是算法压轴题而是你面对基础题能不能又快又准地写出来。2. 正式笔试题型分布与核心知识点拆解2.1 选择题里的“陷阱题”从HashMap到JVM参数贝壳笔试的客观题量不算少我这次遇到的是30道单选、10道多选限时40分钟。选择题覆盖面很广但核心就那么几类。第一类是Java基础考得很细比如自动拆装箱、泛型擦除、异常体系、equals和hashCode约定。有个题问“两个对象的equals返回truehashCode一定相等吗”这题考的就是hashCode契约equals相等则hashCode必须相等反过来不成立。另外还考了lambda表达式的变量捕获规则以及枚举类能不能继承、能不能实现接口。这些都是很基础但容易记混的点尤其是枚举很多人知道枚举是final class但忘了它可以实现接口。第二类是集合框架最典型的是HashMap。JDK8的HashMap底层是数组链表红黑树默认初始容量16负载因子0.75扩容阈值是12put时会计算key的hash扰动然后按位与取模链表长度超过8并且数组长度达到64时转成红黑树。还有ConcurrentHashMap在JDK8里取消了分段锁改用CASsynchronized锁粒度细化到数组桶。这些属于必背内容但笔试并不会只问你结论它会给你几行代码让你判断扩容后某个元素落在新的哪个桶考的是put的寻址和扩容细节。第三类是JVM。我印象深的一道题是问“栈溢出和堆溢出的区别”还有一个选项里出现了OutOfMemoryError: insufficient memory这是IDE或构建工具启动时常见的错误本质是JVM分配不了足够的内存可能因为堆过小、线程栈过多或物理内存不足。对应在笔试里就是判断什么情况会抛OOM。另外类加载的委派模型也是高频题为什么双亲委派能防止核心类被篡改破坏双亲委派的场景有哪些比如Tomcat和JDBC驱动加载。2.2 编程题排序、字符串处理与ACM输入输出贝壳笔试编程题我是2道一道要求实现快速排序另一道是合并两个有序数组并去重。快速排序这道题考得很直接让手写并说明复杂度。我原本以为快排就是递归加双指针结果在线上编辑器里写了一半才发现partition函数的边界条件非常容易错。我写的是从两端交替扫描的经典写法循环条件里必须带等号否则left和right会错位。另一个常见错误是基准值选择如果直接选最左边且序列已经有序快排会退化成O(n²)虽然笔试一般不要求你写随机化但你能主动提到“可以用三数取中或随机基准来避免最坏情况”会给后续面试留下好印象。合并两个有序数组这题我用的双指针从后往前合并可以避免覆盖。去重用了额外的TreeSet来保证有序不重复但面试官想看到的应该是原地合并和去重。其实这题还有更简单的做法直接把两个数组合并后排序去重但在笔试环境里能用但体现不出算法能力。我建议先写出可运行的版本再优化到双指针至少不会得0分。如果想展示更多可以把“双指针合并”的时间复杂度、空间复杂度写清楚尤其是“从后往前”的思路能够省去额外的复制数组。编程题的坑主要在ACM模式。贝壳的笔试平台需要自己处理输入输出很多人在IDE里能跑通一贴到在线编辑器就报错八成是读入循环写错。我的经验是先看清是多行输入还是单行输入、用空格分隔还是逗号分隔然后老老实实写while (in.hasNext())或readLine()。不要为了省事用System.in.read()去读整数那样很容易把换行符读进去。还有一个细节如果题目要求输出结果以空格分隔最后一个元素后面要不要多余空格很多平台是严格比对的。我习惯在循环里判断一下i ! len - 1再决定是否打印空格能少扣点分。2.3 简答/设计题贴近贝壳业务的场景题怎么答笔试最后一部分是两道简答/设计题它不是让你写出完整代码但要求答案有清晰的方案和关键代码片段。我遇到的题目偏向业务场景一个是“设计一个查询附近房源的功能”另一个是“如何保证房源详情页在秒杀活动场景下不被打崩”。总的来说贝壳的场景题不是考你背了多少中间件而是考你遇到真实业务时能不能把一个模糊问题拆成可落地的方案。答题的时候我是按这个框架来的先定义问题边界确认数据量级、读写比例、延迟要求再画系统上下文哪些服务负责什么最后落到关键数据结构和算法上。比如附近房源先估算一个城市有多少房源再考虑Redis GEO和ES的选型比如详情页抗压先分析热点数据是什么再设计缓存和降级策略。只要你的逻辑是递进的哪怕选型不是最优面试官也能看到你的思路。贝壳的业务场景题通常不用你写太细的伪代码但如果你能给出一个关键的数据结构或接口定义就比纯文字描述强很多。我当时把附近房源接口的参数和返回结构都写了出来还标了索引字段这部分后面细讲。3. 贝壳业务场景题示例与解题思路3.1 附近房源检索的索引与缓存设计附近房源是贝壳这类平台的核心功能之一笔试里出现频率很高。你可以把它拆成三层来看。存储层坐标点到底存MySQL还是ES如果量级在百万级以内MySQL的Geometry类型加空间索引可以扛住但贝壳的城市级别房源量很大一般会引入Elasticsearch的geo_distance查询或Redis GEO。我当时的答复是核心库用MySQL主从对外检索走ESRedis GEO做热点城市或热门商圈的缓存。GeoHash的作用和精度是必考点。GeoHash会把二维经纬度编码成一维字符串字符串越长精度越高从短到长分别对应5位约5公里、6位约1.2公里、7位约150米。附近房源可以通过前缀查询快速缩小范围但会导致边界上的点被滤掉所以通常需要搜索周围8个邻居格子再聚合去重这是很经典的空间索引面试题。我会在回答里主动提到这个边界问题而不是只写完GeoHash就停这会让面试官觉得你真的做过类似功能。缓存层面附近房源的数据属于读多写少但实时性要求不低比如新上架房源和价格变动要尽快可见。我会优先设计一个“城市商圈缩放级别”维度做缓存Key缓存里面只放房源ID列表和基础信息详情用CDN或各自的缓存承载。为了防止缓存雪崩Key的过期时间要加随机偏移量。线上如果碰到高并发再考虑加本地缓存或接口限流。这些答题点写进去基本就把一个空泛的设计题撑起来了。3.2 房源详情页的延迟与原子性考虑如果说附近房源考的是检索那么详情页考的就是缓存和一致性问题。房源详情页通常会拼装房源基础信息、图片、经纪人信息、带看记录、成交记录等多个数据如果每个数据都查一次数据库响应延迟会很高。所以常规做法是先用一个聚合服务把数据组装成JSON缓存到Redis再给到一个短暂的本地缓存。但缓存过期后如果大量请求同时打到DB就是缓存击穿。我在笔试里给出的方案是“逻辑过期”或“互斥锁重建缓存”。逻辑过期是指缓存里存一个过期时间字段请求发现逻辑过期后只让一个线程重建缓存其他线程先返回旧数据适合容错性高的场景。互斥锁则适用于必须拿到最新数据的场景。我对比过两者的差别互斥锁实现简单但可能造成线程阻塞逻辑过期实现更复杂但用户体验更好。贝壳的详情页如果发生缓存击穿直接影响就是首页或搜索页集中点击时接口变慢所以这种题目考的就是你平时有没有真正处理过缓存问题。还有一个点容易被忽略房源价格或状态变更时缓存怎么更新如果先更新DB再删缓存在极端情况下会有一个覆盖问题如果先删缓存再更新DB在更新DB失败时可能导致缓存不可用。常见做法是更新DB后异步删缓存或者用canal监听binlog去更新缓存。这类问题贝壳笔试不一定要求你选到最优解但答出“我是怎么保证最终一致性的”这个思路就够了。3.3 短链接与ID生成这类高频题的通用套路虽然不是贝壳的典型业务但很多大厂笔试会把“短链接服务”或“全局唯一ID生成”当设计题来考。对应到贝壳可能是促销活动页、分享屋源链接等场景。答案的核心套路是一样的先明确需求跳转QPS、存储量、有效期。然后设计存储短码与原URL的映射表。生成短码可以用哈希截断冲突处理也可以用发号器生成自增ID再做Base62编码。Base62编码在“分布式ID”场景里很常见6位编码能表示62^6约568亿个不同值足够日常活动使用。如果要考深度还会问你遇到热点短码怎么办加一层本地缓存或者用一致性哈希做多级缓存。还会问短码过期怎么处理懒删除和定时任务补偿。你会发现这套方案不管放到哪个业务场景都是通用的。答题时我会先画一个请求流程图客户端访问短码 - Nginx - 网关 - 短链服务 - 缓存 - DB然后逐层讲解这样既系统又不容易漏点。另外还有一个近年出现频次增加的点开放平台API Key的安全对接尤其是Spring Boot项目中如何设计一个签名的接口。比如贝壳开放平台给第三方经纪人系统查询房源数据需要先申请AppKey和AppSecret请求时用AppSecret生成签名服务端验签并做时间戳防重放敏感字段走HTTPS再配合IP白名单和限流。这虽然不是纯粹的笔试编程题但放在设计题里可以作为安全扩展点提到会让你的答案比“调用方直接传ID”高一个档次。4. 笔试后复盘那些让我扣分的细节与准备建议4.1 Lombok报错、JDK版本不一致等环境坑笔试过程中很多人会被环境坑掉时间尤其是本地IDE里能跑提交到平台却报错。我这次虽然整体顺利但前一天的模考中就遇到过Lombok的报错“you arent using a compiler supported by lombok, so lombok will not work”大概率是JDK版本和Lombok插件版本不兼容。比如你用JDK17跑旧版Lombok编译器注解处理会异常解决办法是把Lombok升到1.18.30以上或者在Maven里明确annotationProcessorPaths配置。类似的还有“源发行版17需要目标发行版17”的警告。这个问题的本质是IDE的Java编译器版本和项目字节码目标版本不一致。在命令行里编译时javac -source 17 -target 17或Maven的maven.compiler.source/target必须匹配。笔试平台一般只会设置一个默认JDK版本如果你在本地用高版本特性比如switch表达式、文本块平台很有可能编译失败。所以笔试写代码尽量用保守写法不要秀新语法。另外JVM启动参数也要注意。本地IDEA经常会配-Xmx但在线上编译器里堆内存是受限的如果一个测试用例故意构造了很大的数组可能出现OutOfMemoryError: insufficient memory。这时不要慌看看是不是递归没有终止条件、或者数组长度读错。这种OOM往往不是平台限制而是你代码本身的问题。还有人在本地用JDK17平台默认JDK8代码里用了var或List.of()直接编译不过。考前一定确认一下笔试平台要求的Java版本不确定就按JDK8的语法写。4.2 规范答题与代码风格笔试平台里看不见的评分点很多同学觉得笔试只要结果对就能过其实不是。贝壳这类公司笔试结果会由技术面试官人工复核代码风格和注释会直接影响后续面试邀约。我自己的几个习惯是类名、方法名、变量名要见名知意不要用a、b、temp。关键算法题要写注释解释自己的思路哪怕只有一行“// 使用双指针从后往前合并避免覆盖”。不要在一个方法里写几百行至少拆出partition()、merge()这类辅助方法。处理边界条件比如快排里low high的递归出口、链表题里的空指针判断。如果笔试平台允许在线调试我建议先把主流程跑通再补边界。千万不要一上来就追求最优解结果基础样例都过不了。你先把30分的暴力解拿到再慢慢优化至少不会因为一个隐蔽的bug白给。还有一点是关于“要不要写设计题的关键代码”。我见过很多人设计题只写文字总觉得面试官看的是思路。其实错了文字描述得再好也不如一个关键类或接口定义来得直接。比如设计附近房源我写了一个NearbySearchRequest的字段列表又写了缓存Key的拼接规则面试官只要扫一眼就知道我能不能落地。贝壳的秋招笔试通常没有人工阅卷那么快但到了面试环节面试官翻到你的笔试答案时一份代码规范、逻辑清晰的答案会让他的第一印象好很多。4.3 给后续批次考生的三条实操建议第一别把时间全押在选择题上。我一直觉得客观题靠平时积累临时冲刺很难提升真正拉开差距的是编程题和设计题。选择题做得再快也就比其他人多几分钟但设计题的思路展示往往决定你能不能进面试。第二练习时一定要用笔试平台自带的编辑器至少提前模拟一次ACM模式练习一下自己处理输入输出。牛客网和LeetCode的模式不一样不要等到正式笔试才发现不会读多行数据。第三把贝壳的业务和Java知识点绑定记忆。比如看到Redis就会想到附近的房源和经纪人位置看到MySQL索引就会想到房源条件筛选看到JVM就会想到高并发下的GC调优。这样记下来的知识笔试时自然能写出来。最后还是那句话笔试只是秋招的第一道门槛真正决定你能不能拿到offer的是笔试后面的面试。但这一道门槛确实会拦住相当一部分准备不充分的人。希望这篇复盘能帮你少走点弯路祝你顺利。