尧图网页设计 
最近公司在招Java开发我作为技术面试官连着面了十几个候选人简历写得一个比一个漂亮问到基础却支支吾吾。正当我准备结束这轮招聘时来了个叫谢飞机的哥们这名字一报出来我差点没绷住。他看上去像个段子手可一开口聊Java面试题居然句句在点子上。整个面试过程就是我板着脸追问他嬉皮笑脸拆招碰撞出一堆值得记录的技术细节。这篇文章就把这场面试还原出来顺便把我这些年总结的Java考点、容易踩的坑全部交代清楚。不管你是准备校招、社招还是想系统梳理Java基础都能从中找到有用的东西。1. 开场三分钟从自我介绍看Java基础功底1.1 简历吹牛与实战拷问谢飞机的简历不算惊艳项目经验写了三四个技术栈倒是很全Spring Boot、MySQL、Redis、消息队列、Docker基本是大厂JD里常见的那套。我习惯先让他用两分钟讲一个最拿得出手的项目。他清了清嗓子开口就说“我做过一个库存扣减系统用户下单时并发扣减库存用Redis分布式锁防止超卖后来压测发现锁粒度太大又改成分段锁吞吐量从800涨到3500。”这话听起来没什么问题但细节决定成败。我立刻追问“你说用了Redis分布式锁那锁的key怎么设计的如果进程突然宕机锁会不会死等Redis主从切换时锁失效了怎么办”他愣了两秒咧嘴一笑“面试官您这上来就是夺命连环call我差点以为自己在参加综艺。”然后他收敛表情认真回答“锁的key我用的是stock:001:lockvalue是UUID加线程ID加锁时用SETNX加上过期时间避免宕机后死锁。释放锁时用Lua脚本先比对value再删除防止误删别人的锁。至于Redis主从切换导致锁失效严格说这是RedLock要解决的问题但我们在生产里用的是Redis Cluster加Redisson看门狗会自动续期能最大程度降低风险。”这一段其实答得不错我故意继续施压“如果分布式锁也扛不住呢比如一个热点商品的库存只剩10个但抢购请求有五百万你怎么办”他摊了摊手“那我就得反思为什么要让五百万请求全打到数据库上前置拦截很重要。可以用网关层做限流比如每秒放行2000个请求再用本地缓存提前挡住大部分读请求写请求进MQ异步削峰最后只有少量请求真正操作库存表。还有库存数据本身可以做热点拆分比如把库存分成10个槽位每个槽位单独计数超卖概率极低也不会有锁竞争。”这种思路在真实大厂里非常常见。面试官表面严肃心里已经在给他加分了。很多人项目写得花里胡哨但一追问就露馅。项目经验不是流水账你要能说明白为什么选这个方案、不选另一个会怎样、瓶颈在哪儿、怎么验证有效。谢飞机在搞笑之外确实有真东西。1.2 面向对象三剑客封装、继承、多态的“相声版”我打算考一考他的面向对象基础这种题看着简单但最容易暴露理解深浅。我问“你如何理解面向对象编程Java的核心思想用生活场景解释一下。”他眼睛一亮“这不就是教我用Java编段子吗您听好。封装就像我存私房钱钱放在我手机的支付App里只提供充值、查询、消费三个按钮余额对外不可见别人改不了。Java里对应private字段加public方法把数据和操作绑定在一起外部不能直接伸手掏我的余额只能通过我定义的接口来操作。这就叫封装。”我点点头他继续“继承就像是同事老王的儿子入职我们组老王的工牌能刷的楼层儿子也能刷一部分同时他又多了自己工位的权限。Java里子类继承父类的非私有成员还可以扩展自己的字段和方法。但Java只允许单继承所以需要用接口补位接口就像门禁卡的权限模板你想刷哪些门就实现哪些接口。”“那多态呢”我追问。他笑着说“多态就是同一个‘打卡’动作在不同人身上行为不同。比如公司考勤系统里父类Employee类的clockIn()方法子类Manager重写成‘早上十点打迟到也没人管’子类Security重写成‘凌晨三点打天天夜班’。我们写代码时只管持有Employee引用调用clockIn()时JVM会自动根据真实对象类型找到对应的重写方法。这就是运行时多态底层靠方法表和虚方法分派实现。”这个比喻虽然有点皮但非常准确。封装隐藏实现、继承实现复用、多态实现解耦这是面向对象的三板斧。实际开发中我见过太多人把继承当万金油动不动就“抽取公共父类”最后整个项目继承层级深不见底改一处牵一发动全身。真正的经验是优先用组合而不是继承比如一个类需要日志功能直接注入Logger而不是搞一个LoggableBase类。谢飞机能把这些原理讲成段子说明他是真理解而不是背概念。1.3 静态链接与运行时的相爱相杀聊到Java程序的运行机制我想看看他能不能分清编译期和运行期。我问他“Java是静态链接的吗有人说Java是静态链接的你怎么看”他挠了挠头“这个说法不太严谨。Java语言是静态类型语言类型在编译期就确定了但链接过程主要是动态的。我们写一个Hello.javajavac把它编译成字节码Hello.class里面引用别的类时只记录了一个符号引用比如Ljava/lang/System;并没有把System类的代码直接塞进来。真正解析这个符号引用、把类加载进内存、完成链接是JVM在做的事而且是在类加载阶段的解析环节完成的运行时如果类有变更可能还会重新解析。这跟C/C那种编译期静态链接把所有目标文件和库打包成一个可执行文件是完全不一样的。”“不过”他补充道“Java也不是不能静态编译。GraalVM的Native Image就是AOT编译可以在构建阶段把字节码编译成机器码启动速度快、内存占用低适合Serverless场景。但它牺牲了动态特性反射、动态代理用起来很麻烦需要额外配置。我们公司之前想用Spring Native折腾半天最后还是回退到传统模式。”这里其实引申出很多面试考点Java类加载机制、双亲委派、符号引用与直接引用的转化、JVM参数等。谢飞机能主动提到GraalVM和Spring Native说明他是关注技术前沿的人。这种候选人至少在技术敏感度上没问题。Java是静态类型语言但它的动态链接能力也融进了生态的血液里Servlet容器、Spring IOC、SPI机制、Dubbo这类框架全依赖运行时类加载和反射真正理解了这些才能搞明白框架背后的魔法。2. 基础八股文轰炸数据类型、字符串与容器2.1 数据类型、包装类与缓存池面试进入第二个环节我开始甩八股文。虽然很多人吐槽八股文但基础题筛人确实有效。第一个问题“Java基础数据类型有哪几种包装类有什么用Integer的缓存范围是多少”他掰着手指头“八种整数有byte、short、int、long浮点数float、double还有char和boolean。”接着他话锋一转“但面试官您如果问我包装类我得提醒大家一个经典陷阱——Integer a 100; Integer b 100;a和b是否相等答案是true因为Integer默认缓存-128到127。但Integer c 200; Integer d 200;这俩就不相等了因为超出缓存范围会各自new一个新对象用比较的是地址不是数值。所以处理包装类比较时我从来不敢用要么用equals要么把变量拆箱成int再比较。”我追问“那为什么会有缓存池这个设计Float和Double有没有缓存”他摇头“Float和Double没有因为浮点数个数太多缓存没有意义。Boolean和Byte简单本身就只有两个或256个值全部缓存。缓存池的实质是把高频小对象复用减少内存分配和GC压力。JVM启动时加载IntegerCache类它会读取系统属性java.lang.Integer.IntegerCache.high来配置上限默认是127。”我给这个问题追加难度“有一个代码片段Integer m 1; m 1;这行代码执行时发生了什么”他想了一下“编译器会自动拆箱成int m 1; m m 1;然后加法结果再装箱赋值给m。所以这个过程中发生了一次拆箱和一次装箱。如果在大循环里反复做这种操作会创建很多Integer对象性能很差应该直接使用基本类型int。这也提醒我们在实际开发中追求极致性能时要尽量避免自动装箱拆箱。”这段回答很完整。Java基础数据类型和包装类这块几乎每次面试都必考包括int与Integer混用时什么时候拆箱、与equals的区别、缓存池的设计初衷、自动装箱的本质。不要背答案要理解为什么这样设计这样才能在变化的问题面前立于不败之地。2.2 字符串拼接、不可变性与String.intern字符串是Java里使用最频繁的对象也是最容易出错的点。我问他“String为什么设计成不可变字符串拼接推荐用什么方式”他先答不可变“String类用final修饰内部字符数组也是final而且从Java 9开始底层是byte数组存储目的是防止出现脏数据、保证hashCode缓存安全、同时满足字符串常量池的需要。因为不可变对象天然线程安全非常适合作为HashMap的key。”接着他说“字符串拼接如果在循环里千万别用因为每次都会产生新的StringBuilder对象。我用过Java 8下编译上面的循环十几个字符串拼接字节码里全是new StringBuilder和append循环一多就是垃圾对象制造的狂欢。改进做法是在循环外面单独创建一个StringBuilder不断append最后toString。到了Java 11以后字符串拼接优化更强还加了字符串折叠、压缩字符串的机制但手动复用StringBuilder仍然是稳妥的选择。”“那String.intern方法呢这个比较冷门但很有价值。”我故意问。他说“intern方法会去字符串常量池里查找当前字符串是否存在如果存在直接返回池中的引用不存在就先放入池再返回引用。这个可以用在大批读入相同字符串的场景避免重复大对象。但要注意两点第一JDK 8里常量池在堆中intern操作可能触发Full GC第二intern有很多版本差异早期是permgen拷贝后来是堆内引用。强烈建议生产环境谨慎使用除非你精确统计过重复率。最稳妥的是用更可控的缓存结构比如Guava的Interner或编码时自己维护的HashMap。”他能提到Guava Interner说明不是死背八股。Java字符串这一块面试官喜欢从“为什么不可变”发散到常量池、StringBuilder、intern、字符串底层存储的改进一条线问到底。我们平时写代码也要注意字符串在不同场景下的取舍日志模板预编译、SQL拼接使用占位符、JSON字段名做好常量管理这些都跟String的性能和内存息息相关。2.3 容器选型与HashMap源码细节“项目里Map用得最多的是哪种为什么”我问。他毫不犹豫“HashMap平均时间复杂度O(1)底层是数组加链表加红黑树。JDK 8之后链表长度超过8会树化成红黑树节点数少于6会退化为链表中间有个7的缓冲值防止频繁转换。它的容量永远是2的n次幂因为计算桶下标时用(n - 1) hash比取模效率高前提是n是2的幂。扩容时每次翻倍节点要么呆在原位要么移动原位置加旧容量的大小这个规律是看源码总结的。”我接着问“你项目中自定义对象做key的时候要注意什么”他正了正身子“这是个大坑。自定义类作为HashMap的key必须重写hashCode和equals而且这俩方法要遵循逻辑相等。比如用User对象当key如果不重写equals即使两个User的userId相同对象的默认equals比较引用地址map.get(userA)永远取不到map.put(userB)放的条目还会导致内存泄漏。最好用不可变对象做key比如Long、String或自己创建的真正不可变类。如果要存可变字段如果修改了字段导致hashCode变化map就找不到原条目了轻则取不到值重则泄漏。”他顿了顿“还有并发问题。HashMap不是线程安全的并发put可能导致CPU 100%的死循环这是JDK 7头插法的老问题JDK 8改成尾插后风险降低但数据丢失和尺寸异常仍然存在。并发场景必须用ConcurrentHashMap它的锁粒度从JDK 7的Segement变成了JDK 8的桶节点CAS加synchronized并发度提升很多而且迭代器是弱一致性的不会抛ConcurrentModificationException。”容器选型是一个经验活。ArrayList和LinkedList的区别、HashMap和TreeMap的排序特性、HashSet背后的HashMap、CopyOnWriteArrayList的适用场景这些都要清楚。谢飞机对HashMap的细节如数家珍这正是大厂面试最看重的源码阅读能力。我见过很多候选人只会说“HashMap是数组加链表”但问树化阈值、扩容机制、为什么容量是2的幂就卡壳这一轮能答得这么顺说明他真看源码。3. 线上实战题并发、锁与JVM调优3.1 多线程、线程池参数怎么定八股文告一段落我决定问点实战的。大厂面试少不了线程池。我问“你项目里用线程池吗核心参数怎么设计的”他回答“常用得最多的是ThreadPoolExecutor。我的习惯是根据任务类型分为CPU密集型和IO密集型。CPU密集型核心线程数可以设为CPU核数加一避免线程切换开销IO密集型由于大部分时间在等待IO核心线程数可以设为核心数乘2比如8核就16。但更重要的是数任务积压量和服务响应时间P99用数据来调整而不是拍脑袋。”“拒绝策略怎么选”我追问。谢飞机说“默认的AbortPolicy直接抛异常容易让用户看到报错不好。我喜欢CallerRunsPolicy让提交任务的线程自己执行这个任务起到天然限流作用不会突然丢失请求。但要注意如果线程池已满且队列满了在主线程里执行耗时逻辑会影响主流程响应所以这个策略适合对延迟稍微敏感的场景。我们曾经在订单系统里用的是DiscardOldestPolicy会把最老的排队任务丢掉但它可能丢弃有状态的请求必须结合业务幂等设计来用。”他能区分不同拒绝策略的细微差别这已经超过了大多数候选人。线程池的核心参数corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、handler每一个都值得细细考量。尤其是workQueue选型无界队列容易导致高峰请求全部堆积最后OOM有界队列加合理拒绝策略才稳妥。很多公司直接用Executors.newFixedThreadPool默认是无界队列这是一个隐患。面试时说出这一点会让面试官觉得你踩过坑。3.2 数据一致性怎么保证从锁到分布式事务“你这块涉及库存扣减那服务的数据一致性怎么保证”这是经典问题。他总结“先从单机说最简单的做法是用数据库行锁比如select * from stock where id xxx for update;在事务里锁住行保证同一时间只有一个事务能改库存。但行锁是基于数据库连接实现的如果一个事务占用时间过长连接池会被耗尽。然后是乐观锁用版本号字段update语句改成update stock set count count - #{num}, version version 1 where id #{id} and version #{oldVersion}影响行数为0就说明冲突再重试或提示用户。如果并发很高就需要RedisLua脚本原子扣减再用MQ异步落库保证最终一致。”“那跨服务呢比如订单服务扣减库存同时还要调用积分服务加积分两个服务不在一个库怎么保证”我继续加压。他认真说“如果要求强一致可以用Seata的AT模式或者本地消息表加MQ。我更推荐尽可能规避分布式事务做法是把库存、订单、积分状态都放到一个流程里如果业务允许用事务消息。事务消息机制是先把本地事务执行成功再发一条半消息到MQ如果本地事务失败发送方不确认投递MQ最终不会让消费者看到这条消息。这样消息发出和本地事务成功形成原子绑定。真正复杂的地方在于消费端要幂等同一个消息即使重复消费也不会造成数据重复。”这种思路在大厂面试中非常加分。数据一致性没有银弹核心是识别业务到底需要强一致、最终一致还是可容忍不一致。每秒几万扣减还要求严格不超卖方案一定是分层设计前置拦截、队列削峰、数据库最终兜底。谢飞机提到事务消息和幂等已经是个有分布式经验的人。3.3 一次OOM排查的完整过程我决定给他一个场景题“线上突然出现OutOfMemoryError你怎么办假设你用的是JDK 8。”他脱口而出“首先保住现场。”他把头一抬像在给下属开会“1. 第一时间把堆内存dump下来用jmap导出一个heap.hprof注意要快因为OOM经常随之而来是服务自杀。2. 查看JVM启动参数确认堆大小、垃圾回收器、是否打印GC日志。3. 用MAT或VisualVM分析dump看大对象是什么。4. 最常见的是内存泄漏比如ThreadLocal没有remove、静态集合不断添加、HTTP连接池泄漏、MyBatis缓存无上限。有一次我们排查到是日志框架里MDC的ThreadLocal没有清理导致每次请求都往里塞Map线程复用后越积越大。”“如果短时间内无法分析dump呢”我问。他说“那就临时把堆调大一点同时打开-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/logs让JVM下次OOM时自动留下现场。服务先重启保命然后马上取dump分析。还有一个容易被忽视的地方是有很多框架包装的ThreadLocal比如Spring的RequestContextHolder要在异步线程里注意继承方式必要时使用InheritableThreadLocal或TransmittableThreadLocal。”这种答案不是背出来的是真的经历过线上事故的人才讲得出来。JVM调优不是神仙参数而是一套诊断方法拿到dump、识别泄漏源、修复代码、压测验证、灰度上线。我顺便问了G1和CMS的区别他说G1是区域化、可预测停顿时间CMS是并发标记清除两者都追求减少STW但JDK 9以后CMS废弃JDK 11以后一般直接上G1JDK 17默认的是ZGC的改进版本。他对垃圾回收器的理解也比较到位。4. 算法与开放题排序、字符串判断和定时任务4.1 手写冒泡排序与排序算法选择大厂面试算法题不一定是LeetCode原题有时候会抽查基本功。我让谢飞机手写冒泡排序。他一边写一边解说“冒泡排序的思路是每一轮让相邻元素两两比较大的往后挪所以每一轮结束后最大的元素会‘冒泡’到末尾。两层循环外层是轮数i内层是比较次数n-1-i。注意优化如果某一轮没有任何交换说明已经有序提前结束。这是我写的代码”public static void bubbleSort(int[] arr) { if (arr null || arr.length 2) { return; } int n arr.length; for (int i 0; i n - 1; i) { boolean swapped false; for (int j 0; j n - 1 - i; j) { if (arr[j] arr[j 1]) { int tmp arr[j]; arr[j] arr[j 1]; arr[j 1] tmp; swapped true; } } if (!swapped) { break; } } }他写完放下笔“但说真的冒泡排序实际项目里用得少因为平均时间复杂度O(n²)。如果数据量小、几乎有序用插入排序更好它也能达到O(n)而且交换次数更少。如果数据量大直接Arrays.sort()底层是TimSort或者DualPivotQuickSortJDK会根据数组长度和基本类型自动选择。排序算法考察的其实是稳定性、空间复杂度、最坏情况而不是让你自己造轮子。”紧接着我让他写了一个「判断字符串中是否不是字母和数字」的题目。他说“这个题的坑在于空格、标点符号、中文等都要认真考虑。比如判断一个字符不是字母也不是数字可以用Character.isLetterOrDigit(ch)取反它会判断Unicode字母和数字中文肢不会被误判。如果只想判断ASCII字母数字就自己写范围判断(ch 0 ch 9) || (ch a ch z) || (ch A ch Z)注意大小写问题。”他补了一句“如果题目要求性能能先把需要判断的字符串转成char数组遍历比直接用String.charAt调用开销小因为每次charAt还要检查索引范围。这种题的关键是在面试中展现你对常见API和边界情况的敏感度。”这一番回答让我刮目相看一个会说相声的人写起代码来倒是干净利落。4.2 定时任务框架选型与设计我接着问“项目里的定时任务一般怎么实现如果任务需要分布式执行怎么保证不重复跑”他说“最早我用Timer单线程任务抛出运行时异常会杀掉整个调度线程不推荐。后来用ScheduledExecutorService支持线程池调度适合简单场景。到了Spring项目里直接用Scheduled配合EnableScheduling用cron表达式控制频率很方便。但分布式环境就麻烦了同一台机器多个实例部署Scheduled会在每个实例上都触发导致重复执行。所以至少要加一个分布式锁比如用Redis的setnx锁抢到锁的任务才执行。更完整的方案是引入分布式调度框架比如Quartz集群或XXL-JOB。XXL-JOB自带调度中心、任务分片、失败重试、告警比较符合大厂的习惯。”“为什么要用调度中心而不是自己Redis锁”我追问。他回答“因为定时任务不止是定时触发还要管理任务状态、查看执行日志、动态调整cron、集群中某台机器宕了任务自动failover。如果只用Redis锁你只能保证不同节点不重复执行但看不到任务到底跑没跑、跑了多久、有没有报错。所以中大型项目直接用分布式调度平台。选型时还要考虑任务类型是批处理、消息清理、报表生成还是数据同步。不同任务对失败补偿的要求不同有些可以接受攒一批再跑有些则要保证实时性。”这个回答回应了热词“java定时任务框架”。我们面试时经常看到候选人只知道Scheduled却不知道分布式环境下的重复问题。能够主动抛出XXL-JOB和分布式锁的人说明他真的维护过线上任务系统。4.3 手写一个线程安全的单例“既然基础聊得差不多了写个单例吧。要求线程安全还不能用synchronized修饰整个方法。”我给了个热身题。他唰唰写了双重校验锁的版本一边写还一边念叨“volatile关键字在这里必不可少不止是为了可见性更重要的是禁止指令重排序。instance new Singleton()这条语句在JVM里不是原子的它分为三步1. 分配内存空间2. 执行构造方法初始化对象3. 将引用指向内存空间。如果不加volatile那第2步和第3步有可能被CPU或JIT重排比如先将引用指向一块未完全初始化的内存。此时另一个线程发现instance非null就直接拿来用结果拿到一个半成品对象这就会出大问题。”他写完后又给了一个更简洁的静态内部类方案public class Singleton { private Singleton() {} private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }“这个方案利用了类加载的机制静态内部类只有在首次getInstance被调用时才会加载并初始化JVM保证类加载的线程安全性所以不用同步。它既满足了懒加载又兼顾线程安全。如果项目里用的是枚举我甚至推荐用枚举实现单例简洁且能防止反射破坏。”他没踩“双重校验锁必须加volatile”的坑已经打败了一大批候选人。单例看似简单其实考察了并发、JMM、类加载、反射攻击等多个维度。我们平时面试这种“小而深”的题目最能看出一个人的真实水平。5. 开发场景题权限、防爬、邮件伪造与对象拷贝5.1 行级权限的设计思路大厂后端经常要处理数据权限。我问“如果你的系统里每个销售只能看到自己的客户但是销售经理能看到全组的客户怎么设计行级权限”谢飞机想了想说“数据库层面我一般不会推荐用户每查询一次就动态拼一大串用户ID条件因为容易臃肿、性能差也容易出错。更靠谱的是把数据归属抽成一个字段比如customer表里加owner_id再配合一个数据权限配置表{ userId, scope, deptId, roleType }。查询时通过MyBatis的拦截器在SQL执行前自动把数据权限条件拼进去。例如普通销售自动拼上customer.owner_id 当前用户ID销售经理自动拼上customer.owner_id IN (SELECT user_id FROM sys_user WHERE dept_id 当前部门ID)管理员默认不加条件。这样业务代码不需要到处判断角色权限逻辑集中在拦截器里维护起来就轻松很多。”“那如果跨部门共享客户呢”我继续问。他补充“那就再加一张共享关系表或者把权限变成集合判断扫描时先根据当前用户查询出可见的owner_id列表再join。如果数据量大可以用一个独立数据权限团队维护一份位图或者布隆过滤器但一般业务用不到。要注意的是行级权限一定不能依赖前端传值比如前端传一个customerIds数组后端就信那等于裸奔。所有数据权限都要在后端拦截前端只是展示。”这个回答体现了他的工程思维。行级权限在很多公司都是刚需面试时能说出MyBatis拦截器这种落地方案比只说“加个条件查询”的人强不少。5.2 Controller层如何防爬虫“现在的互联网产品接口经常被爬虫抓甚至被刷量。如果让你在Controller层做防护你会怎么做”我抛了一个更开放的题目。他笑了笑说“防爬不是靠一个过滤器就能彻底解决但Controller层可以做第一道防线。我一般这样做在Gateway网关层或Filter里统一做限流基于IP、用户ID、设备指纹做滑动窗口限流。加一个防重放机制在请求头里带timestamp和nonce后端用Redis保存nonce5分钟有效如果同一个nonce重复出现直接拒绝。配合一个签名机制把业务参数加盐后生成签名防止请求被篡改和重放。校验User-Agent和Referer很多爬虫用的是Python脚本或curlUser-Agent和普通浏览器不同可以直接拦截但这只是初级手段。更有效的是验证码在高频请求时强制出现滑块或点选验证码。用接口幂等做二次保护防止重复提交和刷量对业务产生实际影响。如果接口数据是纯展示的可以用CDN缓存直接让大部分请求在边缘节点就被拦住。”“那你觉得真正的反爬难点在哪”我问。他说“难点在于爬虫可以模拟真实浏览器。无头浏览器可以执行JS、产生鼠标轨迹、甚至过掉简单验证码。所以现在更流行的是行为分析比如正常用户访问页面会先请求HTML、加载图片JS、再有逻辑顺序地调接口而爬虫往往直接调接口数据特征差异很大。可以在后端统计访问模式给异常行为打标再精准限流或封禁。”这个回答非常有深度。Controller层防护并不是限制在一个注解或一个过滤器里而是一整套纵深防御体系。我在面试里常看到候选人只会说“加个拦截器校验”但能讲出timestamp、nonce、签名、验证码、行为分析完整链路的人是真正做过反爬的。5.3 邮件伪造原理与简单防护“再问一个冷门但实际的问题Java发邮件如果看到一封来自ceocompany.com的邮件就一定安全吗说说邮件伪造的原理。”谢飞机眼角带着点狡黠“这就是传说中的邮件伪造。SMTP协议本身不太校验发件人身份发件人地址可以随意填。用JavaMail发送时我可以把From设成ceocompany.com即使我没有这个邮箱的密码很多邮件服务器也会收下这封信。因为SMTP是明文协议历史上设计就是基于信任的。真正的防护靠SPF、DKIM、DMARC。SPF是DNS里声明哪些IP有权以这个域名发信收件人服务器查一下发信IP是否在SPF记录里DKIM是发件人对邮件内容签名收件人通过DNS取公钥验签DMARC是告诉收件人如果验签失败该怎么处理。”“那Java端开发邮件系统要注意什么”我继续。他说“首先不要自己写SMTP客户端直接用Spring Boot的JavaMailSender配置好host、port、username、password。生产环境建议用TLS加密连接不要用25端口明文。其次在发送前强制校验发件人、收件人防内部开放转发变成垃圾邮件跳板。高安全场景可以限制每用户发送频率并对可疑内容做过滤。”这是一个很好的安全意识题。很多做业务开发的程序员从来不关注邮件伪造原理但企业内部的邮件系统如果被利用来钓鱼后果很严重。Java后端不能只关心业务CRUD还要有网络安全意识。5.4 对象深度拷贝的快与慢“Java对象深拷贝怎么实现你是不是第一反应是序列化”我笑着问。他果然笑了“是序列化是最直接的深拷贝方式对象实现Serializable然后用ObjectOutputStream写到字节流再读出来。但c和慢对象几百个字段序列化和反序列化的性能开销特别大。而且如果对象里有不实现Serializable的字段就完了。所以实际项目中更推荐以下方式自己实现拷贝构造器或setter最灵活也最快但字段多了容易漏。用Spring BeanUtils.copyProperties性能一般只能浅拷贝属性名和类型要匹配。用MapStruct或BeanCopier编译期生成拷贝代码性能接近手写适合DTO转换。如果确实需要深拷贝可以用Fastjson先把对象toJSONString再parseObject或者用Jackson的ObjectMapper转换但还是有成本。最稳的是利用Java反射写一个通用深拷贝工具但要处理循环引用和复杂集合非常容易踩坑。”“那你自己项目里怎么选择”我问。他说“大多数场景用MapStruct就够了DTO和VO转换基本够用。深拷贝真正用到的地方比较少比如要发消息给MQ但又不想让原对象后续被修改影响消息内容可以用JSON深拷贝一份。除非对象结构极其简单否则我不会手写序列化深拷贝。”这个回答非常务实。深拷贝是Java世界里的一道经典易错题网上到处是坑面试官问这个问题往往就是想看看候选人会不会无脑推荐序列化。谢飞机能分场景讨论说明他真的做了很多功课。6. 面试复盘那些年我们背过的八股文和踩过的坑6.1 谢飞机的搞笑金句与背后的技术真相面试接近尾声我忍不住问他“你简历上写的是‘精通Java’但刚才你讲的很多内容是‘熟悉’为什么不写精通”他连做两个揖“面试官写‘精通’的人有两种一种是天才一种是无知者。我是第三种靠这个字吸引您来面我然后我再用真诚打动您。‘精通’的意思是我不仅知道什么时候用它还知道什么时候不用它。比如我知道Java的ArrayList是好东西但对象频繁增删时LinkedList会更好我知道正则表达式很强大但循环一百万次字符串匹配时我会先编译Pattern再复用我知道Spring的Transactional很方便但自己调用同类方法时事务不生效这个坑我踩过三次。”他说着说着认真起来“Java八股文是敲门砖但只有把八股文背后的原理和实际踩坑连接起来才是真掌握。很多人背了HashMap红黑树门槛却不知道线上为什么链表转红黑树会失败背了Spring IoC却不知道Bean的作用域和ThreadLocal的关系背了JVM垃圾回收器却没有看一眼GC日志。我宁可面试时说自己‘熟悉’也不愿在入职后被代码打脸。”我在心里给他竖了个大拇指。这个候选人技术扎实又有自嘲的幽默感确实是个有趣的人。6.2 面试官视角什么样的候选人能拿Offer作为面试官我分享一下我的筛选逻辑。很多人以为大厂面试就是背题其实不然。我看重三样东西第一基础是否牢固。java基础、面向对象编程Java、集合、并发、JVM这些东西就是地基中的承重墙。你可以不会某个框架的冷门API但不能不理解线程安全的本质、不能不懂HashMap的hash算法、不能不清楚String是不可变的。第二有没有真实排查过问题。面试时只要深入问一个线上故障比如OOM、死锁、CPU飙升、接口超时候选人的经验多少就全暴露了。我见过太多人只会说“我们用了缓存所以很稳定”但问缓存一致性问题就哑了。像谢飞机能主动讲出ThreadLocal误用导致内存泄漏这是真经验不是培训出来的。第三沟通和场景理解能力。一个搞笑、放松、能用生活化类比讲技术的人通常也是团队里比较好协作的人。反观那种全程紧张、答非所问的人就算技术再强进了团队也会有很大磨合成本。面试不是考试是一场技术对话。面试结束后我对谢飞机说“你挺有意思等HR通知吧。”他一本正经站起来鞠了一躬说“谢谢面试官如果我有幸加入我可以每天晨会讲一个Java段子保证大家不瞌睡。”我憋着笑把备注栏里“技术扎实沟通顺畅”打完悄悄又加了一句“适合当团队气氛组。”6.3 给Java学习者的路线建议既然这篇文章写到这里我也借这个机会给正在准备面试的朋友一份经验清单先把Java基础吃透数据类型、运算符、控制语句、数组、面向对象、常用API、集合、异常、IO、反射、注解。不要急着学框架。基础扎实了后面学什么都快。数据结构和算法不能丢链表、栈、队列、二叉树、哈希表、排序、二分、动态规划、回溯早晚用得上。特别是蓝桥杯、LeetCode这类题目不仅练代码还练思维。并发编程必须实战不要只背synchronized和volatile写几个多线程程序跑一跑看看线程dump体会死锁是怎么产生的。JDK里AbstractQueuedSynchronizer的源码至少要把关键流程看懂。JVM要会看日志和dump不用背所有参数但要会用jps、jstack、jmap、jstat、MAT。线上问题处置是区分初高级程序员的分水岭。框架要延伸到原理Spring的IoC和AOP、Spring Boot的自动配置、MyBatis的Mapper代理、消息队列的重试机制都值得看源码。真看懂了你写简历就不会心虚。多做项目和复盘项目不在多在精哪怕是个人开源项目只要你讲清楚设计动机、数据流、瓶颈和优化结果面试官都会认可。同时把你踩过的坑整理成博客或笔记这就是你最好的学习资料。这篇文章写到这里我的脑海里还回荡着谢飞机那句“私房钱封装论”。我知道他不是全才分布式这块细节还是稍欠火候进大厂后还有很长的路要走但他的技术敏锐度和真诚的学习态度足够让我给他开一扇门。如果你也在准备Java面试希望你能从他的故事里找到自己的影子然后踏踏实实把基础补牢把代码写好。下一次当你坐到面试官对面时也许也可以用一句幽默开场白拉近彼此的距离然后把真本事缓缓亮出来。 Java面试官实录：从基础八股到线上问题排查，一文讲透
最近公司在招Java开发我作为技术面试官连着面了十几个候选人简历写得一个比一个漂亮问到基础却支支吾吾。正当我准备结束这轮招聘时来了个叫谢飞机的哥们这名字一报出来我差点没绷住。他看上去像个段子手可一开口聊Java面试题居然句句在点子上。整个面试过程就是我板着脸追问他嬉皮笑脸拆招碰撞出一堆值得记录的技术细节。这篇文章就把这场面试还原出来顺便把我这些年总结的Java考点、容易踩的坑全部交代清楚。不管你是准备校招、社招还是想系统梳理Java基础都能从中找到有用的东西。1. 开场三分钟从自我介绍看Java基础功底1.1 简历吹牛与实战拷问谢飞机的简历不算惊艳项目经验写了三四个技术栈倒是很全Spring Boot、MySQL、Redis、消息队列、Docker基本是大厂JD里常见的那套。我习惯先让他用两分钟讲一个最拿得出手的项目。他清了清嗓子开口就说“我做过一个库存扣减系统用户下单时并发扣减库存用Redis分布式锁防止超卖后来压测发现锁粒度太大又改成分段锁吞吐量从800涨到3500。”这话听起来没什么问题但细节决定成败。我立刻追问“你说用了Redis分布式锁那锁的key怎么设计的如果进程突然宕机锁会不会死等Redis主从切换时锁失效了怎么办”他愣了两秒咧嘴一笑“面试官您这上来就是夺命连环call我差点以为自己在参加综艺。”然后他收敛表情认真回答“锁的key我用的是stock:001:lockvalue是UUID加线程ID加锁时用SETNX加上过期时间避免宕机后死锁。释放锁时用Lua脚本先比对value再删除防止误删别人的锁。至于Redis主从切换导致锁失效严格说这是RedLock要解决的问题但我们在生产里用的是Redis Cluster加Redisson看门狗会自动续期能最大程度降低风险。”这一段其实答得不错我故意继续施压“如果分布式锁也扛不住呢比如一个热点商品的库存只剩10个但抢购请求有五百万你怎么办”他摊了摊手“那我就得反思为什么要让五百万请求全打到数据库上前置拦截很重要。可以用网关层做限流比如每秒放行2000个请求再用本地缓存提前挡住大部分读请求写请求进MQ异步削峰最后只有少量请求真正操作库存表。还有库存数据本身可以做热点拆分比如把库存分成10个槽位每个槽位单独计数超卖概率极低也不会有锁竞争。”这种思路在真实大厂里非常常见。面试官表面严肃心里已经在给他加分了。很多人项目写得花里胡哨但一追问就露馅。项目经验不是流水账你要能说明白为什么选这个方案、不选另一个会怎样、瓶颈在哪儿、怎么验证有效。谢飞机在搞笑之外确实有真东西。1.2 面向对象三剑客封装、继承、多态的“相声版”我打算考一考他的面向对象基础这种题看着简单但最容易暴露理解深浅。我问“你如何理解面向对象编程Java的核心思想用生活场景解释一下。”他眼睛一亮“这不就是教我用Java编段子吗您听好。封装就像我存私房钱钱放在我手机的支付App里只提供充值、查询、消费三个按钮余额对外不可见别人改不了。Java里对应private字段加public方法把数据和操作绑定在一起外部不能直接伸手掏我的余额只能通过我定义的接口来操作。这就叫封装。”我点点头他继续“继承就像是同事老王的儿子入职我们组老王的工牌能刷的楼层儿子也能刷一部分同时他又多了自己工位的权限。Java里子类继承父类的非私有成员还可以扩展自己的字段和方法。但Java只允许单继承所以需要用接口补位接口就像门禁卡的权限模板你想刷哪些门就实现哪些接口。”“那多态呢”我追问。他笑着说“多态就是同一个‘打卡’动作在不同人身上行为不同。比如公司考勤系统里父类Employee类的clockIn()方法子类Manager重写成‘早上十点打迟到也没人管’子类Security重写成‘凌晨三点打天天夜班’。我们写代码时只管持有Employee引用调用clockIn()时JVM会自动根据真实对象类型找到对应的重写方法。这就是运行时多态底层靠方法表和虚方法分派实现。”这个比喻虽然有点皮但非常准确。封装隐藏实现、继承实现复用、多态实现解耦这是面向对象的三板斧。实际开发中我见过太多人把继承当万金油动不动就“抽取公共父类”最后整个项目继承层级深不见底改一处牵一发动全身。真正的经验是优先用组合而不是继承比如一个类需要日志功能直接注入Logger而不是搞一个LoggableBase类。谢飞机能把这些原理讲成段子说明他是真理解而不是背概念。1.3 静态链接与运行时的相爱相杀聊到Java程序的运行机制我想看看他能不能分清编译期和运行期。我问他“Java是静态链接的吗有人说Java是静态链接的你怎么看”他挠了挠头“这个说法不太严谨。Java语言是静态类型语言类型在编译期就确定了但链接过程主要是动态的。我们写一个Hello.javajavac把它编译成字节码Hello.class里面引用别的类时只记录了一个符号引用比如Ljava/lang/System;并没有把System类的代码直接塞进来。真正解析这个符号引用、把类加载进内存、完成链接是JVM在做的事而且是在类加载阶段的解析环节完成的运行时如果类有变更可能还会重新解析。这跟C/C那种编译期静态链接把所有目标文件和库打包成一个可执行文件是完全不一样的。”“不过”他补充道“Java也不是不能静态编译。GraalVM的Native Image就是AOT编译可以在构建阶段把字节码编译成机器码启动速度快、内存占用低适合Serverless场景。但它牺牲了动态特性反射、动态代理用起来很麻烦需要额外配置。我们公司之前想用Spring Native折腾半天最后还是回退到传统模式。”这里其实引申出很多面试考点Java类加载机制、双亲委派、符号引用与直接引用的转化、JVM参数等。谢飞机能主动提到GraalVM和Spring Native说明他是关注技术前沿的人。这种候选人至少在技术敏感度上没问题。Java是静态类型语言但它的动态链接能力也融进了生态的血液里Servlet容器、Spring IOC、SPI机制、Dubbo这类框架全依赖运行时类加载和反射真正理解了这些才能搞明白框架背后的魔法。2. 基础八股文轰炸数据类型、字符串与容器2.1 数据类型、包装类与缓存池面试进入第二个环节我开始甩八股文。虽然很多人吐槽八股文但基础题筛人确实有效。第一个问题“Java基础数据类型有哪几种包装类有什么用Integer的缓存范围是多少”他掰着手指头“八种整数有byte、short、int、long浮点数float、double还有char和boolean。”接着他话锋一转“但面试官您如果问我包装类我得提醒大家一个经典陷阱——Integer a 100; Integer b 100;a和b是否相等答案是true因为Integer默认缓存-128到127。但Integer c 200; Integer d 200;这俩就不相等了因为超出缓存范围会各自new一个新对象用比较的是地址不是数值。所以处理包装类比较时我从来不敢用要么用equals要么把变量拆箱成int再比较。”我追问“那为什么会有缓存池这个设计Float和Double有没有缓存”他摇头“Float和Double没有因为浮点数个数太多缓存没有意义。Boolean和Byte简单本身就只有两个或256个值全部缓存。缓存池的实质是把高频小对象复用减少内存分配和GC压力。JVM启动时加载IntegerCache类它会读取系统属性java.lang.Integer.IntegerCache.high来配置上限默认是127。”我给这个问题追加难度“有一个代码片段Integer m 1; m 1;这行代码执行时发生了什么”他想了一下“编译器会自动拆箱成int m 1; m m 1;然后加法结果再装箱赋值给m。所以这个过程中发生了一次拆箱和一次装箱。如果在大循环里反复做这种操作会创建很多Integer对象性能很差应该直接使用基本类型int。这也提醒我们在实际开发中追求极致性能时要尽量避免自动装箱拆箱。”这段回答很完整。Java基础数据类型和包装类这块几乎每次面试都必考包括int与Integer混用时什么时候拆箱、与equals的区别、缓存池的设计初衷、自动装箱的本质。不要背答案要理解为什么这样设计这样才能在变化的问题面前立于不败之地。2.2 字符串拼接、不可变性与String.intern字符串是Java里使用最频繁的对象也是最容易出错的点。我问他“String为什么设计成不可变字符串拼接推荐用什么方式”他先答不可变“String类用final修饰内部字符数组也是final而且从Java 9开始底层是byte数组存储目的是防止出现脏数据、保证hashCode缓存安全、同时满足字符串常量池的需要。因为不可变对象天然线程安全非常适合作为HashMap的key。”接着他说“字符串拼接如果在循环里千万别用因为每次都会产生新的StringBuilder对象。我用过Java 8下编译上面的循环十几个字符串拼接字节码里全是new StringBuilder和append循环一多就是垃圾对象制造的狂欢。改进做法是在循环外面单独创建一个StringBuilder不断append最后toString。到了Java 11以后字符串拼接优化更强还加了字符串折叠、压缩字符串的机制但手动复用StringBuilder仍然是稳妥的选择。”“那String.intern方法呢这个比较冷门但很有价值。”我故意问。他说“intern方法会去字符串常量池里查找当前字符串是否存在如果存在直接返回池中的引用不存在就先放入池再返回引用。这个可以用在大批读入相同字符串的场景避免重复大对象。但要注意两点第一JDK 8里常量池在堆中intern操作可能触发Full GC第二intern有很多版本差异早期是permgen拷贝后来是堆内引用。强烈建议生产环境谨慎使用除非你精确统计过重复率。最稳妥的是用更可控的缓存结构比如Guava的Interner或编码时自己维护的HashMap。”他能提到Guava Interner说明不是死背八股。Java字符串这一块面试官喜欢从“为什么不可变”发散到常量池、StringBuilder、intern、字符串底层存储的改进一条线问到底。我们平时写代码也要注意字符串在不同场景下的取舍日志模板预编译、SQL拼接使用占位符、JSON字段名做好常量管理这些都跟String的性能和内存息息相关。2.3 容器选型与HashMap源码细节“项目里Map用得最多的是哪种为什么”我问。他毫不犹豫“HashMap平均时间复杂度O(1)底层是数组加链表加红黑树。JDK 8之后链表长度超过8会树化成红黑树节点数少于6会退化为链表中间有个7的缓冲值防止频繁转换。它的容量永远是2的n次幂因为计算桶下标时用(n - 1) hash比取模效率高前提是n是2的幂。扩容时每次翻倍节点要么呆在原位要么移动原位置加旧容量的大小这个规律是看源码总结的。”我接着问“你项目中自定义对象做key的时候要注意什么”他正了正身子“这是个大坑。自定义类作为HashMap的key必须重写hashCode和equals而且这俩方法要遵循逻辑相等。比如用User对象当key如果不重写equals即使两个User的userId相同对象的默认equals比较引用地址map.get(userA)永远取不到map.put(userB)放的条目还会导致内存泄漏。最好用不可变对象做key比如Long、String或自己创建的真正不可变类。如果要存可变字段如果修改了字段导致hashCode变化map就找不到原条目了轻则取不到值重则泄漏。”他顿了顿“还有并发问题。HashMap不是线程安全的并发put可能导致CPU 100%的死循环这是JDK 7头插法的老问题JDK 8改成尾插后风险降低但数据丢失和尺寸异常仍然存在。并发场景必须用ConcurrentHashMap它的锁粒度从JDK 7的Segement变成了JDK 8的桶节点CAS加synchronized并发度提升很多而且迭代器是弱一致性的不会抛ConcurrentModificationException。”容器选型是一个经验活。ArrayList和LinkedList的区别、HashMap和TreeMap的排序特性、HashSet背后的HashMap、CopyOnWriteArrayList的适用场景这些都要清楚。谢飞机对HashMap的细节如数家珍这正是大厂面试最看重的源码阅读能力。我见过很多候选人只会说“HashMap是数组加链表”但问树化阈值、扩容机制、为什么容量是2的幂就卡壳这一轮能答得这么顺说明他真看源码。3. 线上实战题并发、锁与JVM调优3.1 多线程、线程池参数怎么定八股文告一段落我决定问点实战的。大厂面试少不了线程池。我问“你项目里用线程池吗核心参数怎么设计的”他回答“常用得最多的是ThreadPoolExecutor。我的习惯是根据任务类型分为CPU密集型和IO密集型。CPU密集型核心线程数可以设为CPU核数加一避免线程切换开销IO密集型由于大部分时间在等待IO核心线程数可以设为核心数乘2比如8核就16。但更重要的是数任务积压量和服务响应时间P99用数据来调整而不是拍脑袋。”“拒绝策略怎么选”我追问。谢飞机说“默认的AbortPolicy直接抛异常容易让用户看到报错不好。我喜欢CallerRunsPolicy让提交任务的线程自己执行这个任务起到天然限流作用不会突然丢失请求。但要注意如果线程池已满且队列满了在主线程里执行耗时逻辑会影响主流程响应所以这个策略适合对延迟稍微敏感的场景。我们曾经在订单系统里用的是DiscardOldestPolicy会把最老的排队任务丢掉但它可能丢弃有状态的请求必须结合业务幂等设计来用。”他能区分不同拒绝策略的细微差别这已经超过了大多数候选人。线程池的核心参数corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、handler每一个都值得细细考量。尤其是workQueue选型无界队列容易导致高峰请求全部堆积最后OOM有界队列加合理拒绝策略才稳妥。很多公司直接用Executors.newFixedThreadPool默认是无界队列这是一个隐患。面试时说出这一点会让面试官觉得你踩过坑。3.2 数据一致性怎么保证从锁到分布式事务“你这块涉及库存扣减那服务的数据一致性怎么保证”这是经典问题。他总结“先从单机说最简单的做法是用数据库行锁比如select * from stock where id xxx for update;在事务里锁住行保证同一时间只有一个事务能改库存。但行锁是基于数据库连接实现的如果一个事务占用时间过长连接池会被耗尽。然后是乐观锁用版本号字段update语句改成update stock set count count - #{num}, version version 1 where id #{id} and version #{oldVersion}影响行数为0就说明冲突再重试或提示用户。如果并发很高就需要RedisLua脚本原子扣减再用MQ异步落库保证最终一致。”“那跨服务呢比如订单服务扣减库存同时还要调用积分服务加积分两个服务不在一个库怎么保证”我继续加压。他认真说“如果要求强一致可以用Seata的AT模式或者本地消息表加MQ。我更推荐尽可能规避分布式事务做法是把库存、订单、积分状态都放到一个流程里如果业务允许用事务消息。事务消息机制是先把本地事务执行成功再发一条半消息到MQ如果本地事务失败发送方不确认投递MQ最终不会让消费者看到这条消息。这样消息发出和本地事务成功形成原子绑定。真正复杂的地方在于消费端要幂等同一个消息即使重复消费也不会造成数据重复。”这种思路在大厂面试中非常加分。数据一致性没有银弹核心是识别业务到底需要强一致、最终一致还是可容忍不一致。每秒几万扣减还要求严格不超卖方案一定是分层设计前置拦截、队列削峰、数据库最终兜底。谢飞机提到事务消息和幂等已经是个有分布式经验的人。3.3 一次OOM排查的完整过程我决定给他一个场景题“线上突然出现OutOfMemoryError你怎么办假设你用的是JDK 8。”他脱口而出“首先保住现场。”他把头一抬像在给下属开会“1. 第一时间把堆内存dump下来用jmap导出一个heap.hprof注意要快因为OOM经常随之而来是服务自杀。2. 查看JVM启动参数确认堆大小、垃圾回收器、是否打印GC日志。3. 用MAT或VisualVM分析dump看大对象是什么。4. 最常见的是内存泄漏比如ThreadLocal没有remove、静态集合不断添加、HTTP连接池泄漏、MyBatis缓存无上限。有一次我们排查到是日志框架里MDC的ThreadLocal没有清理导致每次请求都往里塞Map线程复用后越积越大。”“如果短时间内无法分析dump呢”我问。他说“那就临时把堆调大一点同时打开-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/logs让JVM下次OOM时自动留下现场。服务先重启保命然后马上取dump分析。还有一个容易被忽视的地方是有很多框架包装的ThreadLocal比如Spring的RequestContextHolder要在异步线程里注意继承方式必要时使用InheritableThreadLocal或TransmittableThreadLocal。”这种答案不是背出来的是真的经历过线上事故的人才讲得出来。JVM调优不是神仙参数而是一套诊断方法拿到dump、识别泄漏源、修复代码、压测验证、灰度上线。我顺便问了G1和CMS的区别他说G1是区域化、可预测停顿时间CMS是并发标记清除两者都追求减少STW但JDK 9以后CMS废弃JDK 11以后一般直接上G1JDK 17默认的是ZGC的改进版本。他对垃圾回收器的理解也比较到位。4. 算法与开放题排序、字符串判断和定时任务4.1 手写冒泡排序与排序算法选择大厂面试算法题不一定是LeetCode原题有时候会抽查基本功。我让谢飞机手写冒泡排序。他一边写一边解说“冒泡排序的思路是每一轮让相邻元素两两比较大的往后挪所以每一轮结束后最大的元素会‘冒泡’到末尾。两层循环外层是轮数i内层是比较次数n-1-i。注意优化如果某一轮没有任何交换说明已经有序提前结束。这是我写的代码”public static void bubbleSort(int[] arr) { if (arr null || arr.length 2) { return; } int n arr.length; for (int i 0; i n - 1; i) { boolean swapped false; for (int j 0; j n - 1 - i; j) { if (arr[j] arr[j 1]) { int tmp arr[j]; arr[j] arr[j 1]; arr[j 1] tmp; swapped true; } } if (!swapped) { break; } } }他写完放下笔“但说真的冒泡排序实际项目里用得少因为平均时间复杂度O(n²)。如果数据量小、几乎有序用插入排序更好它也能达到O(n)而且交换次数更少。如果数据量大直接Arrays.sort()底层是TimSort或者DualPivotQuickSortJDK会根据数组长度和基本类型自动选择。排序算法考察的其实是稳定性、空间复杂度、最坏情况而不是让你自己造轮子。”紧接着我让他写了一个「判断字符串中是否不是字母和数字」的题目。他说“这个题的坑在于空格、标点符号、中文等都要认真考虑。比如判断一个字符不是字母也不是数字可以用Character.isLetterOrDigit(ch)取反它会判断Unicode字母和数字中文肢不会被误判。如果只想判断ASCII字母数字就自己写范围判断(ch 0 ch 9) || (ch a ch z) || (ch A ch Z)注意大小写问题。”他补了一句“如果题目要求性能能先把需要判断的字符串转成char数组遍历比直接用String.charAt调用开销小因为每次charAt还要检查索引范围。这种题的关键是在面试中展现你对常见API和边界情况的敏感度。”这一番回答让我刮目相看一个会说相声的人写起代码来倒是干净利落。4.2 定时任务框架选型与设计我接着问“项目里的定时任务一般怎么实现如果任务需要分布式执行怎么保证不重复跑”他说“最早我用Timer单线程任务抛出运行时异常会杀掉整个调度线程不推荐。后来用ScheduledExecutorService支持线程池调度适合简单场景。到了Spring项目里直接用Scheduled配合EnableScheduling用cron表达式控制频率很方便。但分布式环境就麻烦了同一台机器多个实例部署Scheduled会在每个实例上都触发导致重复执行。所以至少要加一个分布式锁比如用Redis的setnx锁抢到锁的任务才执行。更完整的方案是引入分布式调度框架比如Quartz集群或XXL-JOB。XXL-JOB自带调度中心、任务分片、失败重试、告警比较符合大厂的习惯。”“为什么要用调度中心而不是自己Redis锁”我追问。他回答“因为定时任务不止是定时触发还要管理任务状态、查看执行日志、动态调整cron、集群中某台机器宕了任务自动failover。如果只用Redis锁你只能保证不同节点不重复执行但看不到任务到底跑没跑、跑了多久、有没有报错。所以中大型项目直接用分布式调度平台。选型时还要考虑任务类型是批处理、消息清理、报表生成还是数据同步。不同任务对失败补偿的要求不同有些可以接受攒一批再跑有些则要保证实时性。”这个回答回应了热词“java定时任务框架”。我们面试时经常看到候选人只知道Scheduled却不知道分布式环境下的重复问题。能够主动抛出XXL-JOB和分布式锁的人说明他真的维护过线上任务系统。4.3 手写一个线程安全的单例“既然基础聊得差不多了写个单例吧。要求线程安全还不能用synchronized修饰整个方法。”我给了个热身题。他唰唰写了双重校验锁的版本一边写还一边念叨“volatile关键字在这里必不可少不止是为了可见性更重要的是禁止指令重排序。instance new Singleton()这条语句在JVM里不是原子的它分为三步1. 分配内存空间2. 执行构造方法初始化对象3. 将引用指向内存空间。如果不加volatile那第2步和第3步有可能被CPU或JIT重排比如先将引用指向一块未完全初始化的内存。此时另一个线程发现instance非null就直接拿来用结果拿到一个半成品对象这就会出大问题。”他写完后又给了一个更简洁的静态内部类方案public class Singleton { private Singleton() {} private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }“这个方案利用了类加载的机制静态内部类只有在首次getInstance被调用时才会加载并初始化JVM保证类加载的线程安全性所以不用同步。它既满足了懒加载又兼顾线程安全。如果项目里用的是枚举我甚至推荐用枚举实现单例简洁且能防止反射破坏。”他没踩“双重校验锁必须加volatile”的坑已经打败了一大批候选人。单例看似简单其实考察了并发、JMM、类加载、反射攻击等多个维度。我们平时面试这种“小而深”的题目最能看出一个人的真实水平。5. 开发场景题权限、防爬、邮件伪造与对象拷贝5.1 行级权限的设计思路大厂后端经常要处理数据权限。我问“如果你的系统里每个销售只能看到自己的客户但是销售经理能看到全组的客户怎么设计行级权限”谢飞机想了想说“数据库层面我一般不会推荐用户每查询一次就动态拼一大串用户ID条件因为容易臃肿、性能差也容易出错。更靠谱的是把数据归属抽成一个字段比如customer表里加owner_id再配合一个数据权限配置表{ userId, scope, deptId, roleType }。查询时通过MyBatis的拦截器在SQL执行前自动把数据权限条件拼进去。例如普通销售自动拼上customer.owner_id 当前用户ID销售经理自动拼上customer.owner_id IN (SELECT user_id FROM sys_user WHERE dept_id 当前部门ID)管理员默认不加条件。这样业务代码不需要到处判断角色权限逻辑集中在拦截器里维护起来就轻松很多。”“那如果跨部门共享客户呢”我继续问。他补充“那就再加一张共享关系表或者把权限变成集合判断扫描时先根据当前用户查询出可见的owner_id列表再join。如果数据量大可以用一个独立数据权限团队维护一份位图或者布隆过滤器但一般业务用不到。要注意的是行级权限一定不能依赖前端传值比如前端传一个customerIds数组后端就信那等于裸奔。所有数据权限都要在后端拦截前端只是展示。”这个回答体现了他的工程思维。行级权限在很多公司都是刚需面试时能说出MyBatis拦截器这种落地方案比只说“加个条件查询”的人强不少。5.2 Controller层如何防爬虫“现在的互联网产品接口经常被爬虫抓甚至被刷量。如果让你在Controller层做防护你会怎么做”我抛了一个更开放的题目。他笑了笑说“防爬不是靠一个过滤器就能彻底解决但Controller层可以做第一道防线。我一般这样做在Gateway网关层或Filter里统一做限流基于IP、用户ID、设备指纹做滑动窗口限流。加一个防重放机制在请求头里带timestamp和nonce后端用Redis保存nonce5分钟有效如果同一个nonce重复出现直接拒绝。配合一个签名机制把业务参数加盐后生成签名防止请求被篡改和重放。校验User-Agent和Referer很多爬虫用的是Python脚本或curlUser-Agent和普通浏览器不同可以直接拦截但这只是初级手段。更有效的是验证码在高频请求时强制出现滑块或点选验证码。用接口幂等做二次保护防止重复提交和刷量对业务产生实际影响。如果接口数据是纯展示的可以用CDN缓存直接让大部分请求在边缘节点就被拦住。”“那你觉得真正的反爬难点在哪”我问。他说“难点在于爬虫可以模拟真实浏览器。无头浏览器可以执行JS、产生鼠标轨迹、甚至过掉简单验证码。所以现在更流行的是行为分析比如正常用户访问页面会先请求HTML、加载图片JS、再有逻辑顺序地调接口而爬虫往往直接调接口数据特征差异很大。可以在后端统计访问模式给异常行为打标再精准限流或封禁。”这个回答非常有深度。Controller层防护并不是限制在一个注解或一个过滤器里而是一整套纵深防御体系。我在面试里常看到候选人只会说“加个拦截器校验”但能讲出timestamp、nonce、签名、验证码、行为分析完整链路的人是真正做过反爬的。5.3 邮件伪造原理与简单防护“再问一个冷门但实际的问题Java发邮件如果看到一封来自ceocompany.com的邮件就一定安全吗说说邮件伪造的原理。”谢飞机眼角带着点狡黠“这就是传说中的邮件伪造。SMTP协议本身不太校验发件人身份发件人地址可以随意填。用JavaMail发送时我可以把From设成ceocompany.com即使我没有这个邮箱的密码很多邮件服务器也会收下这封信。因为SMTP是明文协议历史上设计就是基于信任的。真正的防护靠SPF、DKIM、DMARC。SPF是DNS里声明哪些IP有权以这个域名发信收件人服务器查一下发信IP是否在SPF记录里DKIM是发件人对邮件内容签名收件人通过DNS取公钥验签DMARC是告诉收件人如果验签失败该怎么处理。”“那Java端开发邮件系统要注意什么”我继续。他说“首先不要自己写SMTP客户端直接用Spring Boot的JavaMailSender配置好host、port、username、password。生产环境建议用TLS加密连接不要用25端口明文。其次在发送前强制校验发件人、收件人防内部开放转发变成垃圾邮件跳板。高安全场景可以限制每用户发送频率并对可疑内容做过滤。”这是一个很好的安全意识题。很多做业务开发的程序员从来不关注邮件伪造原理但企业内部的邮件系统如果被利用来钓鱼后果很严重。Java后端不能只关心业务CRUD还要有网络安全意识。5.4 对象深度拷贝的快与慢“Java对象深拷贝怎么实现你是不是第一反应是序列化”我笑着问。他果然笑了“是序列化是最直接的深拷贝方式对象实现Serializable然后用ObjectOutputStream写到字节流再读出来。但c和慢对象几百个字段序列化和反序列化的性能开销特别大。而且如果对象里有不实现Serializable的字段就完了。所以实际项目中更推荐以下方式自己实现拷贝构造器或setter最灵活也最快但字段多了容易漏。用Spring BeanUtils.copyProperties性能一般只能浅拷贝属性名和类型要匹配。用MapStruct或BeanCopier编译期生成拷贝代码性能接近手写适合DTO转换。如果确实需要深拷贝可以用Fastjson先把对象toJSONString再parseObject或者用Jackson的ObjectMapper转换但还是有成本。最稳的是利用Java反射写一个通用深拷贝工具但要处理循环引用和复杂集合非常容易踩坑。”“那你自己项目里怎么选择”我问。他说“大多数场景用MapStruct就够了DTO和VO转换基本够用。深拷贝真正用到的地方比较少比如要发消息给MQ但又不想让原对象后续被修改影响消息内容可以用JSON深拷贝一份。除非对象结构极其简单否则我不会手写序列化深拷贝。”这个回答非常务实。深拷贝是Java世界里的一道经典易错题网上到处是坑面试官问这个问题往往就是想看看候选人会不会无脑推荐序列化。谢飞机能分场景讨论说明他真的做了很多功课。6. 面试复盘那些年我们背过的八股文和踩过的坑6.1 谢飞机的搞笑金句与背后的技术真相面试接近尾声我忍不住问他“你简历上写的是‘精通Java’但刚才你讲的很多内容是‘熟悉’为什么不写精通”他连做两个揖“面试官写‘精通’的人有两种一种是天才一种是无知者。我是第三种靠这个字吸引您来面我然后我再用真诚打动您。‘精通’的意思是我不仅知道什么时候用它还知道什么时候不用它。比如我知道Java的ArrayList是好东西但对象频繁增删时LinkedList会更好我知道正则表达式很强大但循环一百万次字符串匹配时我会先编译Pattern再复用我知道Spring的Transactional很方便但自己调用同类方法时事务不生效这个坑我踩过三次。”他说着说着认真起来“Java八股文是敲门砖但只有把八股文背后的原理和实际踩坑连接起来才是真掌握。很多人背了HashMap红黑树门槛却不知道线上为什么链表转红黑树会失败背了Spring IoC却不知道Bean的作用域和ThreadLocal的关系背了JVM垃圾回收器却没有看一眼GC日志。我宁可面试时说自己‘熟悉’也不愿在入职后被代码打脸。”我在心里给他竖了个大拇指。这个候选人技术扎实又有自嘲的幽默感确实是个有趣的人。6.2 面试官视角什么样的候选人能拿Offer作为面试官我分享一下我的筛选逻辑。很多人以为大厂面试就是背题其实不然。我看重三样东西第一基础是否牢固。java基础、面向对象编程Java、集合、并发、JVM这些东西就是地基中的承重墙。你可以不会某个框架的冷门API但不能不理解线程安全的本质、不能不懂HashMap的hash算法、不能不清楚String是不可变的。第二有没有真实排查过问题。面试时只要深入问一个线上故障比如OOM、死锁、CPU飙升、接口超时候选人的经验多少就全暴露了。我见过太多人只会说“我们用了缓存所以很稳定”但问缓存一致性问题就哑了。像谢飞机能主动讲出ThreadLocal误用导致内存泄漏这是真经验不是培训出来的。第三沟通和场景理解能力。一个搞笑、放松、能用生活化类比讲技术的人通常也是团队里比较好协作的人。反观那种全程紧张、答非所问的人就算技术再强进了团队也会有很大磨合成本。面试不是考试是一场技术对话。面试结束后我对谢飞机说“你挺有意思等HR通知吧。”他一本正经站起来鞠了一躬说“谢谢面试官如果我有幸加入我可以每天晨会讲一个Java段子保证大家不瞌睡。”我憋着笑把备注栏里“技术扎实沟通顺畅”打完悄悄又加了一句“适合当团队气氛组。”6.3 给Java学习者的路线建议既然这篇文章写到这里我也借这个机会给正在准备面试的朋友一份经验清单先把Java基础吃透数据类型、运算符、控制语句、数组、面向对象、常用API、集合、异常、IO、反射、注解。不要急着学框架。基础扎实了后面学什么都快。数据结构和算法不能丢链表、栈、队列、二叉树、哈希表、排序、二分、动态规划、回溯早晚用得上。特别是蓝桥杯、LeetCode这类题目不仅练代码还练思维。并发编程必须实战不要只背synchronized和volatile写几个多线程程序跑一跑看看线程dump体会死锁是怎么产生的。JDK里AbstractQueuedSynchronizer的源码至少要把关键流程看懂。JVM要会看日志和dump不用背所有参数但要会用jps、jstack、jmap、jstat、MAT。线上问题处置是区分初高级程序员的分水岭。框架要延伸到原理Spring的IoC和AOP、Spring Boot的自动配置、MyBatis的Mapper代理、消息队列的重试机制都值得看源码。真看懂了你写简历就不会心虚。多做项目和复盘项目不在多在精哪怕是个人开源项目只要你讲清楚设计动机、数据流、瓶颈和优化结果面试官都会认可。同时把你踩过的坑整理成博客或笔记这就是你最好的学习资料。这篇文章写到这里我的脑海里还回荡着谢飞机那句“私房钱封装论”。我知道他不是全才分布式这块细节还是稍欠火候进大厂后还有很长的路要走但他的技术敏锐度和真诚的学习态度足够让我给他开一扇门。如果你也在准备Java面试希望你能从他的故事里找到自己的影子然后踏踏实实把基础补牢把代码写好。下一次当你坐到面试官对面时也许也可以用一句幽默开场白拉近彼此的距离然后把真本事缓缓亮出来。