2025年高频java研发工程师面试题及答案

2025年高频java研发工程师面试题及答案Java中JDK17相对于JDK8的核心新特性有哪些？JDK17作为长期支持版本（LTS），核心新特性包括：密封类（SealedClasses），通过`sealed`关键字限制类的继承，增强类型安全；模式匹配（PatternMatching）在`instanceof`中的扩展，允许直接提取对象字段并转换类型，简化代码；`switch`表达式的进一步增强，支持`case`中使用模式匹配和`null`处理；引入VectorAPI（孵化阶段），提供高效的向量计算，替代传统循环；垃圾收集器方面，移除了实验性的ParallelScavenge+SerialOld组合，正式启用ZGC作为生产可用的低延迟收集器；此外，JDK17还优化了内存模型，增强了安全性（如移除RMI的Activation机制），并通过`--enable-preview`支持未来特性的早期试用。ConcurrentHashMap在JDK8中的主要改进有哪些？JDK8的ConcurrentHashMap放弃了JDK7及之前的分段锁（Segment）设计，改为基于CAS（Compare-And-Swap）+`synchronized`的轻量级锁机制。核心改进包括：1.数据结构从“Segment数组+HashEntry数组+链表”改为“Node数组+链表/红黑树”，当链表长度超过8且数组长度≥64时，自动转换为红黑树，提升查找效率；2.锁粒度细化到数组中的单个节点（Node），通过`volatile`修饰数组节点保证可见性，CAS操作用于节点的插入和更新，仅在冲突时使用`synchronized`锁定单个节点，减少锁竞争；3.新增`putIfAbsent`、`compute`等函数式API，支持更灵活的原子操作；4.统计大小（`size()`）时采用更高效的方法，通过遍历`CounterCell`数组累加计数，避免JDK7中遍历所有Segment的性能损耗。如何解决Spring中的循环依赖？Spring通过三级缓存（`DefaultSingletonBeanRegistry`中的三个Map）解决循环依赖，仅支持单例Bean的构造器注入以外的循环依赖（如属性注入）。三级缓存包括：1.一级缓存（`singletonObjects`）：存储已初始化完成的单例Bean；2.二级缓存（`earlySingletonObjects`）：存储提前暴露的未完全初始化的Bean（用于解决AOP代理问题）；3.三级缓存（`singletonFactories`）：存储Bean的工厂对象（`ObjectFactory`），用于提供早期Bean实例（可能包含代理逻辑）。具体流程：当创建BeanA时，首先将A的工厂对象（`ObjectFactory`）存入三级缓存；A需要注入BeanB，触发B的创建；B创建时需要注入A，此时从三级缓存获取A的工厂对象，提供早期A实例（可能应用AOP代理）并存入二级缓存；B完成初始化后存入一级缓存，返回给A；A获取到B后完成初始化，最终从二级缓存或三级缓存中移除，存入一级缓存。若存在AOP代理，三级缓存的工厂对象会提前提供代理实例，避免二级缓存中的原始对象与最终代理对象不一致的问题。ZGC与G1垃圾收集器的核心区别是什么？ZGC和G1均为低延迟收集器，但设计理念和实现机制差异显著：1.内存管理方式：G1采用基于Region的堆划分（约2048个Region），包含Eden、Survivor、Old等类型；ZGC采用动态的“页面”（Page）管理，支持大页（2MB）、中页（32MB）、小页（256KB），更灵活地适配不同对象大小。2.标记算法：G1使用SATB（SnapshotAtTheBeginning）标记，通过写屏障记录对象引用变化；ZGC使用颜色指针（ColorPointers）和读屏障，将标记信息存储在指针的高四位（支持64位系统），标记与应用线程并发执行，无需STW（StopTheWorld）。3.停顿时间：G1目标是停顿时间不超过50ms，但实际可能因老年代回收复杂度过高而延长；ZGC通过并发标记、并发转移等阶段，理论上停顿时间不超过10ms，且与堆大小无关（支持TB级堆）。4.适用场景：G1适合堆大小在几GB到几十GB的场景；ZGC适合大内存、低延迟要求高的场景（如分布式数据库、实时数据处理系统）。如何设计一个线程安全的单例模式？请写出代码示例。线程安全的单例模式需满足：延迟初始化、线程安全、避免反射/序列化攻击。推荐使用双重检查锁定（Double-CheckedLocking）或静态内部类模式。双重检查锁定示例（JDK5及以上，依赖`volatile`保证可见性）：```javapublicclassSingleton{//volatile禁止指令重排序，确保instance初始化完成后再赋值privatestaticvolatileSingletoninstance;privateSingleton(){//防止反射创建实例if(instance!=null){thrownewIllegalStateException("Singletoninstancealreadyinitialized");}}publicstaticSingletongetInstance(){if(instance==null){//第一次检查，避免不必要的锁synchronized(Singleton.class){if(instance==null){//第二次检查，防止多线程同时通过第一次检查instance=newSingleton();}}}returninstance;}}```静态内部类模式（利用类加载机制保证线程安全，天然延迟初始化）：```javapublicclassSingleton{privateSingleton(){}//静态内部类在第一次调用getInstance时加载privatestaticclassHolder{staticfinalSingletonINSTANCE=newSingleton();}publicstaticSingletongetInstance(){returnHolder.INSTANCE;}}```若需防御序列化攻击，需实现`readResolve()`方法返回现有实例；防御反射攻击可在私有构造器中增加状态检查（如上述示例）。MySQL中覆盖索引和回表的概念是什么？如何优化？覆盖索引指查询的所有字段都包含在索引中，无需回表查询主记录。例如，若有索引（`username,email`），当查询`SELECTusername,emailFROMuserWHEREusername='test'`时，索引本身已包含所有需要的字段，直接通过索引返回结果，避免访问主键索引（聚簇索引）。回表指查询的字段不在索引中，需先通过索引找到主键，再通过主键到聚簇索引中获取其他字段。例如，索引（`username`），查询`SELECTusername,ageFROMuserWHEREusername='test'`，需先通过`username`索引找到主键，再通过主键查询`age`字段。优化回表的方法：1.扩展索引字段，将查询频繁的字段加入索引（创建覆盖索引）；2.避免`SELECT`，仅查询必要字段；3.对高频查询且字段较少的表，可考虑使用覆盖索引替代聚簇索引（如业务主键作为聚簇索引）；4.分析慢查询日志（`EXPLAIN`命令），检查`Extra`列是否包含“Usingindex”（表示使用覆盖索引）或“Usingwhere;Usingindexcondition”（可能需回表）。分布式事务中TCC模式的核心步骤是什么？与Seata的AT模式有何区别？TCC（Try-Confirm-Cancel）模式的核心步骤：1.Try阶段：预留业务资源（如冻结账户余额、锁定库存），确保后续Confirm或Cancel操作可执行；2.Confirm阶段：提交Try阶段预留的资源（如扣除冻结余额、减少库存），需幂等（多次调用结果一致）；3.Cancel阶段：回滚Try阶段预留的资源（如解冻余额、恢复库存），需幂等且与Try操作反向。TCC与SeataAT模式的区别：1.侵入性：TCC需手动实现Try/Confirm/Cancel方法，业务代码侵入性高；AT模式基于数据库的本地事务和undo日志，自动提供回滚语句，业务无感知。2.性能：TCC的Try阶段需预留资源，可能增加锁竞争；AT模式通过undo日志实现无锁（仅在提交时释放行锁），性能更优。3.隔离性：TCC依赖业务层控制隔离（如Try阶段冻结资源）；AT模式通过全局锁（Seata1.4+）保证写隔离，读隔离需业务层处理（如读已提交需查询全局事务状态）。4.适用场景：TCC适合资源预留逻辑明确、跨服务边界的复杂事务（如电商下单-支付-发货）；AT模式适合数据库操作为主、业务逻辑简单的场景（如库存扣减、账户转账）。如何解决Redis缓存击穿、穿透和雪崩问题？缓存击穿：热点key过期时，大量请求同时访问数据库。解决方法：1.热点key设置永不过期（逻辑过期，通过异步线程更新）；2.加互斥锁（如Redisson的`Rlock`），仅允许一个线程查询数据库并更新缓存，其他线程等待缓存加载；3.使用本地缓存（如Caffeine）存储热点key，减少对Redis的访问。缓存穿透：查询不存在的key（如id=-1），请求直接打到数据库。解决方法：1.缓存空值（设置短过期时间），避免重复查询；2.布隆过滤器（BloomFilter）预先存储所有可能的key，查询前检查是否存在，不存在直接返回；3.接口层校验（如id范围校验、参数格式校验），过滤无效请求。缓存雪崩：大量key同时过期，数据库压力骤增。解决方法：1.分散过期时间（在基础过期时间上增加随机值，如10-20分钟）；2.分级缓存（本地缓存+Redis），减少对Redis的依赖；3.限流降级（如Sentinel限制数据库访问流量）；4.高可用部署（Redis集群，避免单节点故障导致大面积缓存失效）。SpringBoot自动配置的核心原理是什么？如何自定义一个Starter？SpringBoot自动配置的核心依赖`@SpringBootApplication`注解（组合`@SpringBootConfiguration`、`@EnableAutoConfiguration`、`@ComponentScan`），其中`@EnableAutoConfiguration`通过`SpringFactoriesLoader`加载`META-INF/spring.factories`中的自动配置类。具体流程：1.扫描classpath下所有`META-INF/spring.factories`文件，收集`EnableAutoConfiguration`对应的配置类；2.通过条件注解（如`@ConditionalOnClass`、`@ConditionalOnMissingBean`、`@ConditionalOnProperty`）过滤无效配置类；3.实例化有效配置类中的Bean，并注入到Spring容器。自定义Starter的步骤：1.创建Maven/Gradle项目，添加`spring-boot-autoconfigure`依赖；2.编写自动配置类（如`XxxAutoConfiguration`），使用`@Configuration`标记，并通过条件注解控制生效条件（如`@ConditionalOnClass(XxxService.class)`表示当`XxxService`存在时生效）；3.定义配置属性类（如`@ConfigurationProperties(prefix="xxx")`），绑定`perties`中的配置；4.在`src/main/resources/META-INF/spring.factories`中注册自动配置类（`org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.example.XxxAutoConfiguration`）；5.可选：提供`META-INF/spring-configuration-metadata.json`提供配置提示（IDE自动补全）。如何优化Java线程池的参数配置？常见拒绝策略有哪些？线程池参数优化需结合任务类型（CPU密集型/IO密集型）和系统资源（CPU核心数、内存）：1.核心线程数（`corePoolSize`）：CPU密集型建议设为CPU核心数+1（利用线程切换）；IO密集型建议设为2CPU核心数（等待IO时可执行其他线程）。2.最大线程数（`maximumPoolSize`）：通常与核心线程数相同（避免频繁创建/销毁线程），若任务量波动大，可设为核心线程数的2-4倍，但需结合内存限制（每个线程默认栈大小1MB）。3.存活时间（`keepAliveTime`）：非核心线程空闲时的存活时间，IO密集型可设为较长时间（如60秒），避免频繁销毁；CPU密集型可设为较短时间。4.任务队列（`workQueue`）：有界队列（如`ArrayBlockingQueue`）避免OOM，队列大小需根据任务处理速度和吞吐量调整（如`max(100,maxThreads2)`）。常见拒绝策略：1.`AbortPolicy`（默认）：抛出`RejectedExecutionException`异常；2.`CallerRunsPolicy`：由调用线程直接执行任务（降低提交速度）；3.`DiscardPolicy`：静默丢弃新任务；4.`DiscardOldestPolicy`：丢弃队列中最老的任务，尝试重新提交当前任务；5.自定义策略：实现`RejectedExecutionHandler`接口（如记录日志后重试）。JVM中OOM（OutOfMemory）的常见原因及排查方法？常见OOM类型及原因：1.堆内存溢出（`java.lang.OutOfMemoryError:Javaheapspace`）：对象过多且无法被GC回收（如内存泄漏、大对象未释放）。2.栈溢出（`java.lang.StackOverflowError`）：方法调用栈深度过大（如递归未终止条件）。3.元空间溢出（`java.lang.OutOfMemoryError:Metaspace`）：类信息、常量池等过多（如动态提供类的框架，未正确清理）。4.直接内存溢出（`java.lang.OutOfMemoryError:Directbuffermemory`）：`Unsafe.allocateMemory()`或`ByteBuffer.allocateDirect()`分配的堆外内存超过`-XX:MaxDirectMemorySize`（默认与堆内存相同）。排查方法：1.收集内存快照：使用`-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/path`提供堆转储文件，通过EclipseMAT或JProfiler分析对象引用链，定位内存泄漏点。2.分析GC日志：添加`-Xlog:gc:file=/path/gc.log`，查看GC频率、停顿时间