先说明一下这套整理不是从网上随便拼出来的“答案速查”而是我结合自己作为Java面试官的筛选逻辑、以及在真实项目里踩过的坑把“高频题”和“解题思路”一起串起来了。你如果只想背八股文它也能用但更建议你在看每道题时多问一层“为什么”面试官真正想确认的往往是你有没有建立自己的技术判断力。做了几年Java开发也换过几家公司我自己既被面试过也坐到过面试官那一边。Java面试题翻来覆去其实就那些类目但很多人复习时只会背结论一到追问就露馅。这篇文章我会把近几年最高频的Java高级工程师面试题、标准答案以及答案背后的原理和排查思路全部摊开讲争取让你看完之后不只是“记住了”而是“想通了”。内容主要覆盖Java基础语法与集合、JVM内存与调优、并发编程与锁、Redis与框架实战、还有高频的环境与编码问题。每一块我都按“面试官问什么”、“该怎么答”、“追问怎么接”三层来写部分内容附上可以直接用的命令、配置和代码片段。适合准备跳槽的Java工程师也适合刚入行想建立系统知识体系的新人。1. Java基础面试题——代码功底的高频考点1.1 集合类框架ArrayList、LinkedList与HashMap的选型逻辑面试官问集合几乎必问“ArrayList和LinkedList有什么区别”接着就会问HashMap的底层实现。这两题听起来基础但我见过很多工作三五年的人答不全。先说ArrayList和LinkedList。ArrayList底层是Object数组查询快是因为随机访问直接按下标定位时间复杂度O(1)但插入和删除尤其是从中间插需要把后面的元素整体后移平均时间复杂度O(n)。LinkedList底层是双向链表插入删除只需要修改前后节点的引用看起来是O(1)但这个复杂度是有前提的——你要已经持有对应节点的引用。如果按索引插入LinkedList依然要遍历到那个位置复杂度还是O(n)而且链表节点还要额外存两份指针内存占用比数组更大。所以实际项目里绝大多数场景用ArrayList就够了LinkedList能发挥优势的场景相当少。再来看HashMap这题深度可以差出很多。基础答案是数组加链表加红黑树默认容量16负载因子0.75链表长度超过8且数组长度大于等于64时转红黑树。为什么是0.75这是时间成本和空间成本的一个折中0.75意味着数组用到四分之三就扩容比1更不容易产生长链表又比0.5更节省内存。转红黑树为什么定8根据泊松分布在负载因子0.75的情况下一个桶里链表长度达到8的概率已经极低大约是千万分之六所以阈值定在8是“概率学上的安全边界”。面试官一旦追问“为什么容量是2的幂”这里就有关键原理。因为HashMap计算元素落点用的是(n - 1) hash如果n是2的幂n-1的二进制就是低位全1与运算的结果等价于取模但性能远高于取模扩容时旧元素搬家也只需要看高位新增的那个bit是0还是1是0留在原位置是1就移动到“原位置旧容量”这个设计非常精巧。我面试时如果候选人能答到这一步基本确认他对集合是有真实理解的。1.2 异常体系与受检异常、非受检异常的实际选择跟集合题同样高频的是Java异常体系。“Error和Exception有什么区别”“受检异常和运行时异常怎么选”几乎是送分题但很多人答得模棱两可。Java把可抛出的东西分成两大类Error和Exception两者都继承自Throwable。Error是JVM层面的严重问题比如OutOfMemoryError、StackOverflowError程序本身处理不了不应该试图catch后继续运行。Exception才是代码层面可以预期、可以恢复的问题。Exception又分成受检异常和运行时异常受检异常如IOException、SQLException编译期强制你处理要么try/catch要么throws运行时异常如NullPointerException、IllegalArgumentException编译期不检查运行到那行才可能爆出来。面试官会进一步问你写业务代码时应该用哪种我的答案是自定义业务异常比如参数校验失败、资源不存在这类问题用运行时异常更合适。理由很简单如果在Service层到处声明throwsController层也得跟着处理方法签名会被异常声明污染写起来非常啰嗦。受检异常适合留给那些“调用方必须处理”的资源型操作比如文件读取、网络连接因为你不处理资源就漏了。热搜词里出现过uncaught exception java.lang.noclassdeffounderror: java/applet/applet in thread这类报错这其实就属于NoClassDefFoundError——类定义缺失。它是Error不是Exception说明JVM在加载某个类时找不到依赖的类。它在老项目里常遇到原因是JDK 9以后的模块化把Java Applet相关的类从默认加载列表里移除了代码里用了AWT的Applet类但没引入依赖运行时就抛Error。遇到这种情况别在代码层面瞎try/catch先检查依赖完整性和JDK版本兼容性。1.3 泛型与类型擦除为什么运行时不关心Fish还是Dog泛型也是高频区。“Java泛型是怎么实现的”标准答案是类型擦除泛型信息只存在于编译期编译完成后源码里的ListString和ListInteger在字节码层面都变成原始类型List运行时无法通过反射拿到真正的泛型参数类型。这时我常会追问那为什么下面的代码能通过反射读取泛型很多时候候选人就卡住了。其实擦除不是把信息全删掉类上定义的泛型信息会以Signature属性的形式留在字节码里比如一个类声明了class UserDaoT那么T的信息会保留在Signature中所以Spring在注入时才能通过反射把真实类型解析出来。而方法参数里的泛型比如方法(ListString list)这个String信息会以局部变量表里的签名形式保留所以有些框架能读方法参数的泛型。真正会被完全擦掉的是方法内部的局部泛型变量。除了原理面试官很喜欢问“泛型能不能用于数组”比如new T[10]能不能写。不能因为Java的数组是协变的String[]是Object[]的子类运行时能检查对象实际类型但泛型靠擦除实现运行时信息不完整如果允许泛型数组违法存储数组存储会破坏类型安全所以编译器直接禁止。实际要存泛型内容可以用ArrayListT代替数组或者用反射创建泛型数组但那属于绕弯不建议。1.4 Lambda表达式与函数式接口变量捕获的隐藏规则Java 8以后Lambda基本是必考。面试官会问“Lambda表达式能访问外部的哪些变量”。要答到点子上Lambda里只能访问被final修饰的局部变量或者实际上不可被修改的变量也就是常说的“effectively final”。为什么因为Lambda底层会把这部分变量复制到lambda对应的匿名类里如果变量后面还被修改复制品和原来的值就对不上了容易产生难以定位的并发和副效应问题。这不是语法限制而是Java为了确保行为可预测做的设计。我还遇到过面试官问“Lambda和匿名内部类的区别”除了写法简洁更本质的是作用域。匿名内部类里如果你有一个和外部同名的变量内部类会“遮蔽”外部变量用this.xx就能感觉到它们是不同作用域Lambda没有独立的作用域它跟外围方法共享作用域所以Lambda里不能声明和局部变量同名的参数。另外匿名内部类会生成独立的class文件Lambda则通过 invokedynamic 动态生成JVM可以利用这一点做更多运行期优化这就是为什么很多地方说Lambda性能优于匿名内部类。2. JVM与内存管理高频面试题——高级工程师的必考分水岭2.1 内存区域划分与OutOfMemoryError定位思路JVM这关过不了高级工程师基本没戏。第一问通常是“JVM内存区域怎么划分”。答的时候要区分线程私有和线程共享线程私有的有虚拟机栈、本地方法栈、程序计数器线程共享的有堆、方法区JDK 8之后是元空间、直接内存往往不算在JVM堆内。程序计数器是唯一不会OutOfMemoryError的区域因为每条线程的程序计数器空间是固定的。堆是对象分配的主战场也是垃圾回收的主要区域。老年代和新生代的比例默认是2:1新生代内部Eden区、Survivor0、Survivor1默认是8:1:1。为什么要两块Survivor因为要有地方暂存“经历过一次Minor GC还没死”的对象同时也是为了减少碎片化。虚拟机栈才真正对应我们常说的“栈”每个方法调用就是一个栈帧局部变量表、操作数栈、动态链接、方法出口都放在栈帧里。栈深度超过JVM默认限制就抛StackOverflowError大多数情况下是递归没有出口或者方法调用链路太深。看热搜词里的java: outofmemoryerror: insufficient memory这类堆内存不足特别常见。排查先分两步是堆不够还是系统层面内存不够还是元空间不够。堆不够通常是对象量太大或存在泄漏先用jstat看各区域使用率再用jmap -dump导出堆快照用MAT或JProfiler分析对象引用链如果是元空间不够多半是CGLib动态类生成太多或者反射太频繁适度调大-XX:MetaspaceSize可以缓解但根治还得从代码层面减少动态类。注意别一上来就盲目加-Xmx如果系统物理内存本身就紧张加堆内存反而把操作系统页交换拖慢GC停顿更明显。2.2 GC机制、回收器选型与三色标记GC相关的常见问题有“怎么判断对象可以被回收”“讲一下CMS和G1区别”“你的项目用的什么回收器”。判断对象是否存活标准答案是可达性分析从GC Roots出发按照引用链走不到的对象就是可回收的。GC Roots包括虚拟机栈中引用的对象、静态属性引用的对象、常量引用的对象、JNI引用的对象等。有些候选人会答引用计数需要指出引用计数解决不了循环引用问题JVM用的不是它。CMS和G1的区别是重点。CMS以最短停顿为目标老年代回收采用标记清除算法会有碎片化问题G1则是把堆划分成多个Region既可以回收年轻代也可以回收老年代用可预期停顿模型和复制算法优化了碎片和停顿。面试常追问“CMS并发阶段怎么处理漏标问题”这里就引出了三色标记白色是没访问过的对象灰色是正在访问的对象黑色是自身和引用都处理完的对象。并发标记时如果黑色对象直接引用了白色对象而且灰色对象到该白色对象的引用被切断这个白色对象会被漏标。CMS用增量更新的方式记录新增引用G1用SATBSnapshot At The Beginning方式记录删除引用两种思路各有取舍。我自己的项目里JDK 8用CMSJDK 11以上直接切G1。不是CMS不好而是长期维护成本高碎片问题要注意遇到大对象分配失败的Full GC概率会增加。G1调优主要关注-XX:MaxGCPauseMillis目标停顿一般设置在100到200毫秒之间设得太小会导致垃圾回收过于频繁反而降低吞吐量。2.3 生产环境JVM排查常用指令与调优参数这个题实践性很强。面试官会问“线上JVM CPU飙升怎么排查”标准答案要包括这些步骤先用top找到CPU高的进程再用top -Hp 进程号找到CPU高的线程接着把线程号转成十六进制jstack导出线程快照搜索十六进制线程号定位到具体代码行。很多人会背这一步但实际操作中要注意jstack抓出来的线程号前缀需要自己去匹配而且抓快照最好连续抓几次看同一线程是不是多次出现这样判断才靠谱。调优参数我有几个常用模板。堆内存起步: -Xms4g -Xmx4g等价于起始值和最大值一致避免运行期动态扩容带来的性能抖动新生代大小可以-Xmn1g或者设置-XX:NewRatio2让老年代占三分之二OOM要留下线索必须加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/路径/日志.hprof。元空间-XX:MetaspaceSize建议设个初始值比如256m这样JVM启动时就能预留比较充足的元空间减少运行期扩容次数。GC日志JDK 8用-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/路径/gc.logJDK 11之后统一用-Xlog:gc*:filegc.log。这些参数看起来基础但很多线上故障就是因为没有留日志、没有开OOM dump导致事后连现场都没有。我通常建议基础服务在发布脚本里默认把这些参数带上代价很小排查问题时价值极大。3. 并发编程与锁面试题——进大厂的核心分水岭3.1 synchronized与ReentrantLock锁升级、AQS与公平性并发题能筛掉很多人。第一波问题通常是“synchronized底层原理是什么”“和ReentrantLock怎么选”。synchronized从JDK 6之后不再是“重型锁”的代名词它有锁升级的过程无锁、偏向锁、轻量级锁、重量级锁。偏向锁解决的是“只有一个线程反复获取锁”的场景一旦出现竞争升级为轻量级锁通过CAS自旋尝试拿锁自旋超过阈值或者竞争激烈升级为重量级锁线程挂起进入操作系统内核态等待。JDK 15之后逐步废弃偏向锁因为现代应用线程竞争往往没那么单纯偏向锁的撤销成本甚至比收益还高。ReentrantLock则基于AbstractQueuedSynchronizerAQS实现。AQS内部维护一个volatile的state变量和一个双向等待队列加锁就是通过CAS把state从0改成1失败了就进入等待队列挂起。为什么ReentrantLock能重入因为同一个线程再次加锁时state不是从0改成1而是在原基础上加1解锁时再减回去所以叫可重入。ReentrantLock比synchronized多的能力是可中断地等待锁、支持超时获取锁、支持公平锁、支持多个条件队列。公平锁和非公平锁的区别在于非公平锁在加锁时先直接CAS抢一次抢不到才进队列公平锁严格按请求顺序排队。非公平锁吞吐量更高因为减少了线程挂起唤醒的开销但可能出现“插队”造成的饥饿。答最后一题我一般会给个选择建议能用synchronized优先synchronized因为写法简单、JVM自动优化需要超时中断、公平性、多条件队列时再考虑ReentrantLock。3.2 volatile与可见性、重排序问题volatile是必考题但它常被误解。volatile解决的是多线程下的可见性和有序性问题它不保证原子性。可见性靠的是JMM的happens-before规则以及缓存一致性协议有序性靠的是禁止编译器和CPU重排序。为什么volatile int count做count还是线程不安全因为count包含三步读、加、写volatile保证每一步之间其它线程能看到最新值但三步作为一个整体不具备原子性两个线程可能同时读到相同旧值各自加一写回结果少加了一次。正确用法是普通状态标志用volatile比如volatile boolean running true另一个线程读它判断是否终止或者Double-Checked Locking单例模式里instance字段必须加volatile防止指令重排序导致拿到未初始化完成的对象。不加volatile的DCL单例在极端并发下会出现拿到半初始化对象的问题这是面试官最喜欢追问的安全点。延伸的问题是“volatile能防止重排序吗”要解释内存屏障。JMM在volatile读写前后插入StoreStore、StoreLoad、LoadLoad、LoadLoad等屏障限制处理器和编译器不能把屏障两侧的指令随意越过。这个点如果能画个简单的屏障示意或者举一个单例初始化的例子面试官基本就满意了。3.3 线程池的核心参数与拒绝策略“线程池的核心参数有哪些”这个问题10个人里8个人能背出来但追问“核心线程数怎么设置”就卡住了。ThreadPoolExecutor有七个参数核心线程数、最大线程数、空闲存活时间、时间单位、工作队列、线程工厂、拒绝策略。核心线程数设置没有银弹CPU密集型推荐核心数1IO密集型推荐核心数*2左右还要结合压测结果调整。关键理解是提交任务时如果线程数小于核心线程数直接创建线程如果等于核心线程数任务先进队列队列满了才创建额外线程直到最大线程数最大线程数和队列都满了触发拒绝策略。拒绝策略有四种AbortPolicy默认直接抛异常、CallerRunsPolicy让提交任务的线程自己跑、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃最老的任务。我在订单类系统里通常用CallerRunsPolicy因为宁可让提交线程慢一点也不允许消息丢。还有个细节是线程池“预热”核心线程默认不会预先创建而是在有任务时创建如果希望提前创建要调用prestartAllCoreThreads()。网上很多文章推荐用Executors的静态方法但阿里规约和绝大多数主流团队都反对。原因很直接Executors.newFixedThreadPool和newSingleThreadExecutor用的是无界LinkedBlockingQueue队列可以无限长最大线程数形同虚设任务堆积时有内存耗尽风险newCachedThreadPool最大线程数是Integer.MAX_VALUE高并发下可能创建出天文数字的线程直接拖垮机器。所以使用线程池一定手动new ThreadPoolExecutor并明确设置队列大小和拒绝策略。4. 常用组件与框架实战高频问题——Redis、Spring与常见故障排查4.1 RedisTemplate的increment()报错ERR value is not an integer or out of range这个报错在热搜词里出现了也是我实际被问过很多次的问题。很多人在Spring Boot里用RedisTemplate操作Redis计数器调increment()时触发ERR value is not an integer or out of range。原因是Redis的INCR命令要求key对应的value必须是能被解释为整数的字符串如果value不是数字字符串比如之前用set(count, abc)或者保存了一个JSON串再执行increment就会报错。还有一种更隐蔽的情况value是用StringRedisSerializer序列化写入的整数但读取时RedisTemplate却用了JDK序列化器两边序列化方式不一致导致存进去的字节数据根本不是纯文本数字。排查步骤建议这么走先redis-cli连上Redis敲get 你的key看value长什么样。如果是乱码基本是序列化器不一致检查RedisTemplate的keySerializer、valueSerializer和HashKeySerializer等是否都配成统一方案如果是“abc”这类非数字内容说明代码里曾经用set方法写入过非数字值需要清理这个key或者换一个全新的key再increment。我个人的习惯是RedisTemplate统一配置String序列化所有存储的value都要自己能确认格式尤其计数器这种需要原子自增的字段从头到尾只通过increment操作不允许用set/append去改这样能从源头避免类型混乱。有一点容易忽略increment()的返回值是Long如果你把它强转成Integer数值超过Integer范围会直接抛异常。这也是“不是integer or out of range”里out of range的一部分原因。实际操作时计数器超过21亿是很常见的比如订单号、访问量统计Long才是稳妥的类型。4.2 Lombok版本导致的编译失败You arent using a compiler supported by lombokjava: You arent using a compiler supported by lombok, so lombok will not work是另一个高频报错。这类问题大多出现在升级JDK或换编译环境之后Lombok通过JDK内部的注解处理器接口修改抽象语法树JDK版本一变Lombok不识别新编译器的内部API就直接罢工。常见于JDK 16、JDK 17刚发布那阵子或者IDE自带编译器与项目JDK版本不一致。解决办法不复杂先确认项目JDK版本再上Maven仓库查对应Lombok版本JDK 8用1.18.20及以下JDK 11需要1.18.20JDK 16需要1.18.22JDK 17需要1.18.24JDK 21建议1.18.30。然后升级依赖并注意Maven编译插件里如果配置了annotationProcessorPaths也要把lombok的版本同步更新只改dependency版本、不改annotationProcessorPaths会依然报错。IDEA里还要检查Settings - Build - Compiler - Annotation Processors是否开启否则即使依赖对了IDE内启动也还是编译不过。还有个小坑是把Lombok用在了JDK 8项目里且版本过新比如1.18.30在JDK 8环境下有时反而不兼容所以别盲目追求“新版”结合JDK选版本才是关键。实在不想升级包也可以把Data/Slf4j等注解手动改写成getter/setter/logger声明但工作量不小不推荐长期这样干。4.3 大写字母开头的Bean变量被JSON序列化变小写的坑项目里经常遇到实体类字段是private String URL;用Jackson或Spring默认消息转换器转JSON后前端拿到的字段变成url结果联调对不上字段名。原因是JavaBeans规范里有“Introspector.decapitalize”规则如果属性名的前两个字母都是大写Bean属性名会被按“原始字符串”处理如果只有第一个字母是大写第二个字母小写则第一个字母会被转成小写。URL这个字段两个字母全大写规则正好不会把它变小写但更常见的坑是uRL这种不规范的命名会被解析成uRL或者URL在某些Jackson版本下也确实会被处理成url不同库实现细节不一致。这个问题在网上常被归为“Jackson坑”本质是JavaBean命名规则与JSON字段命名之间的映射冲突。解决手段有这么几种字段上用JsonProperty(URL)强制指定序列化名称或者在getter方法上标注JsonProperty(URL)也可以全局配置PropertyNamingStrategy但那会影响所有字段的命名一般不建议。更重要的是从规范层面禁止这种字段命名Java驼峰式命名法首字母小写后面单词首字母大写url就写成url如果是常量用大写加下划线。实体类里冒出大写开头字段往往是历史代码从C#或数据库字段直接平移过来的习惯需要靠代码规范去约束。4.4 Java枚举类型、反射与Reflection的常见考点枚举看起来简单但面试官能从它问出一串高级知识点。基础问题是“枚举的底层实现是什么”答案是枚举本质是一个继承自java.lang.Enum的final类每个枚举常量都是这个类的一个静态final实例。所以枚举天然是单例的而且线程安全这也是为什么《Effective Java》推荐用枚举实现单例。追问“枚举能不能有抽象方法”可以每个枚举常量可以单独实现抽象方法这在策略模式里很常见用一个枚举类就能封装多个策略。反射则往往结合Spring原理来问。“Spring里哪里用到了反射”答案太多了Bean实例化通过反射调用构造器依赖注入通过反射读字段和setterAutowired、Value解析都需要反射AOP代理底层也要反射调用方法。追问“反射为什么慢”一方面是反射需要动态解析方法调用编译期优化全部失效另一方面是要做访问权限检查、参数包装等额外工作。JDK 8之后反射性能有所优化但频繁调用热点代码仍然不建议无脑反射能缓存Method对象就缓存能接口调用就接口调用别在循环里每次重新获取Method。5. 高频细节与易错题汇总——环境、编码、异常排查速查5.1 Java环境变量配置与NoClassDefFoundError问题复盘环境变量这是一个非常实操的问题面试不一定问但工作中天天能遇到而且网上的教程经常把人带偏。Java环境变量主要配三个JAVA_HOME、PATH、CLASSPATH。JAVA_HOME指向JDK安装目录比如D:\Java\jdk1.8.0_202PATH里追加%JAVA_HOME%\bin这样命令行才能直接识别java和javacCLASSPATH过去需要配现在JDK 5以后不强制了默认会找当前目录和JRE的lib所以一般可以不用手工配置配错了反而会干扰类加载。热搜词里有个报错叫requires a java environment 1.5.0或者NoClassDefFoundError: java/applet/Applet这通常是电脑上装了JRE但没装JDK或者JDK版本过旧缺少某些类导致的。还有种情况是安装多个JDK版本PATH里先命中的是旧版项目用的新版命令行下运行某个工具就用错了Java。我的建议是装完JDK后先用命令java -version和javac -version确认两个版本一致再看echo %JAVA_HOME%确认路径没有多余的尾斜杠和空格。如果命令行版本和IDE版本不一致大概率是IDE里手动指定了JDK路径跟系统PATH无关需要在IDE的Project Structure里更正。5.2 Java控制台中文乱码与编码问题的排查逻辑乱码是特别普遍的问题热搜词里vscode运行Java报错乱码就属于这类。Java中文乱码的根本原因是字符集不一致源文件编译时用的字符集、JVM运行时读入字符串的字符集、控制台或终端展示用的字符集三步中任何一步不一致就会乱码。比如代码文件是UTF-8但javac编译时用的系统默认字符集是GBK编译出来的class里字符串已经乱掉或者运行程序时命令行没指定-Dfile.encodingUTF-8Windows控制台默认GBK也会显示乱码。解决方案分成几层。编译时Maven项目在pom.xml里配置project.build.sourceEncoding为UTF-8Gradle项目在build.gradle里配置compileJava.options.encoding UTF-8。运行时启动命令加-Dfile.encodingUTF-8如果是Windows控制台要先把代码页切到65001或者使用IDEA的Run Configuration里设置VM options。在vscode里跑Java乱码除了设置环境变量还要检查lauch.json里console选项以及java.debug.settings.console编码。排查乱码我习惯写成“三步法”先确定源文件编码再用javac -encoding UTF-8编译验证最后运行参数加-Dfile.encodingUTF-8基本能定位到是哪一层出了问题。5.3 高频易错题与基础语法速查表最后一个部分我把平时最容易在笔试和一面中翻车的细节汇总成一张速查表方便面试前临时过一遍。尤其是运算符优先级、数组越界、标识符命名、排序复杂度这类零散知识点用表格比死记硬背更有用。易错点核心说明常见坑标识符命名字母、下划线、$开头不能用数字开头不能是关键字用中文或特殊符号编译报错运算符优先级赋值最低三目次低高于||移位低于算术高于关系复杂表达式读起来和想的完全不同数组越界ArrayIndexOutOfBoundsException索引范围0到length-1遍历时边界写成length冒泡排序平均和最坏O(n^2)最好O(n)稳定排序忘记优化交换标志已有序数组还跑完整趟快速排序平均O(n log n)最坏O(n^2)不稳定基准选择差时退化成冒泡字符串比较用equals比较内容比较引用字符串常量池和new String混用导致判断错误switch支持的变量类型支持byte、short、char、int、枚举、String不可以用long默认值int默认0boolean默认false引用类型默认null局部变量没有默认值不初始化直接编译失败位操作带符号右移无符号右移负数右移时符号位行为不同数组越界题我曾经在一次笔试里见过一个变形int[] arr new int[5];然后访问arr[5]答案是抛数组越界但是写arr[4]没问题。这个确实基础但很多人在写二分查找时容易把mid的计算写错导致死循环或越界。更实用的是记住二分查找和快速排序的边界条件如果面试时让手写快排partition函数里两个指针的交换条件必须想清楚否则最后几步就会乱。冒泡排序的优化也很常考加一个swapped标志位如果某趟下来没有发生任何交换就提前退出最好情况下时间复杂度能降到O(n)。面试官如果问“数组已经有序怎么写最快”你需要给出这个优化版本而不是直接写教科书版这能体现你有没有在实际项目中关注过性能。我个人在选择排序算法时会跟候选人确认一个思路冒泡和快排虽然笔试考得多但Java的Arrays.sort()底层对于基本类型用的是双轴快速排序对于对象类型用TimSort平时工程项目直接用标准库就够了。面试里能手写快排是基本功但真正让我认可的是能说清楚什么场景用什么排序以及为什么标准库做了这样取舍。再补充一个反射的隐含考点。反射和泛型经常合起来考比如“在反射中怎么获取List的具体泛型类型”。这个要答到ParameterizedType先通过Field.getGenericType()拿Type判断它是不是ParameterizedType再调用getActualTypeArguments()拿真实类型。Spring的GenericTypeResolver本质上也是做类似的事。能回答到这个层次的候选人说明确实接触过Spring源码级别的泛型处理而不是只会用Autowired。这里我想多说一句很多网上的面经喜欢把“反射性能差”当成死记硬背的结论但实际如果Method对象可以缓存并且不用频繁做越权检查反射性能并不差到不能用的程度。关键是把反射的适用范围想清楚——它是框架层、通用层的利器业务代码里能避免就避免能缓存就缓存。最后一个高频小细节Java里String的intern()方法。它会去字符串常量池查有没有相同内容有就返回池里的引用没有就放入池并返回引用。但new String(a)在运行期构造的对象与字符串常量池里的a不是同一个引用。这个坑在很多基础笔试里反复出现理解了字符串常量池之后s1 s2这类比较题基本不会做错。环境变量、乱码、集合、并发、JVM这些内容拼在一起基本覆盖了Java高级工程师面试80%以上的高频题。如果你准备时间有限优先吃透第2章和第3章这两个部分几乎决定了面试官对你的定级判断。做完这些题目之后你会发现面试官追问的很多问题并不难难的是你第一次就没把基础原理梳理清楚。