2025年javamysql面试题及答案

2025年javamysql面试题及答案1.请说明JDK21中虚拟线程与平台线程的核心区别、适用场景及使用注意事项答案：虚拟线程是JDK19引入预览、JDK21正式转正的轻量级线程实现，由JVM在用户态调度，不需要与内核线程1:1映射，核心区别包括：①内存占用：虚拟线程栈按需分配，默认仅占用几KB内存，单进程可支持百万级虚拟线程；平台线程栈固定1MB，单进程最多支持数千个。②调度开销：虚拟线程上下文切换在用户态完成，开销仅为平台线程的1%不到；平台线程切换需进入内核态，开销较高。③调度模型：虚拟线程由JVM的ForkJoinPool作为调度器，挂载到平台线程（Carrier线程）执行，阻塞时会自动卸载，不占用Carrier线程资源；平台线程阻塞时会一直占用内核线程资源。适用场景：IO密集型业务，如API网关、接口聚合服务、消息消费服务等，可大幅提升系统吞吐量；不适用CPU密集型业务，此类场景下用户态调度的收益可忽略，反而会增加额外开销。使用注意事项：避免在虚拟线程中使用ThreadLocal存储大对象，虚拟线程的高并发量会导致内存占用激增；不要执行长时间的CPU密集型操作，避免占用Carrier线程导致其他虚拟线程饥饿；不要修改虚拟线程的优先级，JVM不支持虚拟线程优先级调度。2.请说明Java密封类（SealedClass）的作用、语法规则及适用场景答案：密封类是JDK17正式引入的语法特性，用于限制类的继承范围，避免类被随意扩展。语法规则：①定义类时添加sealed修饰符，通过permits关键字指定允许继承该类的子类列表；②子类必须是以下三种类型之一：final修饰的类，禁止再被继承；sealed修饰的类，可继续指定允许继承的子类；non-sealed修饰的类，放开继承限制，允许任意类继承。作用：实现更安全的类型建模，替代以往通过枚举、反射校验继承关系的方案，避免非法继承导致的逻辑漏洞；配合模式匹配可实现更简洁的类型判断，不需要写冗余的instanceof判断分支。适用场景：领域模型中的状态类、枚举替代类，如订单状态类可限制仅允许已定义的待支付、已支付、已取消等子类继承；框架内部的核心接口，避免外部实现破坏框架逻辑。3.请说明SpringBoot3对比SpringBoot2.x的核心变化及迁移注意事项答案：核心变化包括：①最低依赖升级为JDK17，不再支持JDK8及以下版本，全面支持JDK21虚拟线程等新特性；②JavaEE规范升级为JakartaEE9+，所有javax.*包路径全部替换为jakarta.*，如javax.servlet替换为jakarta.servlet；③内置GraalVM原生镜像支持，通过AOT编译可将SpringBoot应用编译为二进制可执行文件，启动速度提升10-100倍，内存占用降低50%以上，适配Serverless、云原生场景；④自动配置注册方式变更，原META-INF/spring.factories的自动配置注册方式废弃，替换为META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件；⑤内置观测性支持，默认集成Micrometer框架，不需要额外依赖即可实现指标采集、链路追踪、日志关联的可观测能力。迁移注意事项：全局替换所有javax.*包引用为jakarta.*，优先升级第三方依赖到支持JakartaEE的版本；自定义Starter的自动配置需要修改注册文件路径，兼容新的自动配置加载规则；若使用原生镜像编译，需要提前注册反射、资源文件、动态代理等运行时动态访问的内容，避免编译后运行报错；移除已废弃的API，如WebMvcConfigurerAdapter、Jackson的过时序列化配置等。4.请说明分布式锁的常见实现方案对比，以及Redisson可重入锁的实现原理、锁超时问题解决方案答案：常见分布式锁实现方案对比：①MySQL行锁/悲观锁：基于select...forupdate实现，一致性高，性能低，仅适合并发量小于100QPS的小业务场景，不适合高并发场景；②Redis分布式锁：基于SETNX+过期时间实现，性能高，支持高并发，适合大部分常规业务场景，极端情况下存在锁丢失的可能（如主节点宕机未同步锁数据到从节点）；③Zookeeper临时有序节点：基于节点唯一性和Watcher机制实现，一致性高，不会出现锁丢失，适合金融核心、支付等对一致性要求极高的场景，性能略低于Redis方案。Redisson可重入锁实现原理：基于RedisHash数据结构存储锁信息，Hash的key为锁名称，field为锁持有线程的唯一标识（节点ID+线程ID），value为锁的重入次数；加锁、释放锁均通过Lua脚本保证原子性，默认锁过期时间为30s，加锁成功后会启动WatchDog（看门狗）线程，每10s自动为锁续期30s，直到锁被主动释放。锁超时问题解决方案：①开启WatchDog自动续期，避免业务执行时间超过锁默认过期时间导致锁提前释放；②根据业务最大执行时间设置合理的锁过期时间，设置为业务最大执行时间的1.5倍以上；③释放锁时校验锁持有线程的唯一标识，避免误释放其他线程持有的锁；④加锁操作设置超时时间，避免长时间等待锁导致线程阻塞。5.请说明JDK17+垃圾回收器的变化，以及G1和ZGC的适用场景选择答案：JDK17默认垃圾回收器为G1，JDK21默认垃圾回收器为ZGC，核心变化包括：①ZGC在JDK17引入分代回收能力，解决了之前不分代导致的内存碎片化、高吞吐量场景下内存占用过高的问题，最大停顿时间稳定控制在1ms以内，吞吐量仅比G1低3%-5%；②永久代（PermGen）彻底移除，元空间（Metaspace）直接使用本地内存，不需要设置永久代大小参数；③字符串去重、类卸载等优化默认开启，不需要额外配置参数。适用场景选择：①G1适合堆内存8G-32G、对停顿时间要求在100ms-200ms的常规业务系统，如电商后端、企业管理系统、CRM系统等，调优成本低，稳定性高；②ZGC适合堆内存32G以上、对停顿时间要求极高的低延迟场景，如实时交易系统、API网关、实时计算引擎、高频消息消费系统等，支持TB级堆内存，停顿时间不受堆大小影响。6.请说明MySQL8.0原子DDL的实现原理、解决的问题，以及与MySQL5.7DDL的区别答案：原子DDL是MySQL8.0的核心特性，指DDL操作要么全部执行成功，要么全部回滚，不会出现部分执行的情况。实现原理：基于InnoDB的原子数据字典，将表元数据存储在InnoDB系统表中，同时将DDL操作的redolog、undolog统一纳入事务管理，DDL执行失败时会通过undolog回滚所有元数据变更和数据变更。解决的问题：①避免DDL执行失败导致元数据不一致，如5.7中droptablet1,t2时若t2不存在，会删除t1后报错，8.0会全部回滚，两个表都不会被删除；②避免主从复制时DDL部分执行导致的主从不一致问题；③降低DDL操作的风险，不需要提前备份元数据即可执行DDL操作。与5.7的其他区别：8.0默认支持在线DDL，大部分DDL操作（如新增普通字段、新增普通索引）不会阻塞DML读写，仅修改字段类型、新增主键等全表重构操作会阻塞写入；支持DDL的进度查询，可通过performance_schema查看DDL的执行进度。7.请说明MySQL索引失效的常见场景，以及MySQL8.0的索引新特性答案：索引失效的常见场景包括：①索引列使用函数、表达式计算、隐式类型转换，如whereage+1=18、whereid='123'（id为int类型）；②like模糊查询左匹配，如wherenamelike'%张三'；③复合索引不满足最左前缀匹配规则，如复合索引(a,b,c)，查询条件仅包含b、c时索引失效；④使用or连接的条件中，任意一侧条件没有索引时，整体索引失效；⑤数据量过小时，优化器判定全表扫描性能高于索引查询，会选择全表扫描；⑥使用不等于（!=、<>）、isnotnull时，大部分场景下索引失效。MySQL8.0索引新特性：①不可见索引（InvisibleIndex）：可将索引设置为不可见，优化器会忽略该索引，可用于测试索引删除的影响，不需要实际删除索引，避免删错索引后重建的高开销；②降序索引：支持索引列按降序存储，之前版本的降序查询需要反向扫描索引，性能较低，8.0的降序索引可直接顺序读取，提升降序查询性能；③函数索引：支持对函数、表达式的计算结果建索引，解决了索引列使用函数时索引失效的问题；④直方图：支持对数据分布不均匀的字段生成直方图，优化器可根据直方图更准确的估算扫描行数，选择最优执行计划。8.请说明MySQL的MVCC实现原理，以及可重复读隔离级别下是否会出现幻读答案：MVCC（多版本并发控制）是InnoDB实现事务隔离的核心机制，基于undolog版本链和ReadView（读视图）实现，用于实现读写不阻塞，提升并发性能。实现原理：①每行数据都包含两个隐藏列：trx_id（最近一次修改该行数据的事务ID）、roll_pointer（指向undolog中该行历史版本的指针），每次修改数据都会生成新的undolog版本，通过roll_pointer形成版本链；②读视图（ReadView）包含四个核心字段：当前活跃事务的最小ID、最大ID、创建ReadView时活跃的事务ID列表、创建ReadView的事务ID；③查询时会遍历undolog版本链，找到第一个符合ReadView可见性规则的版本，即为查询结果。读已提交隔离级别下，每次查询都会生成新的ReadView，因此每次查询都能看到其他事务最新提交的数据；可重复读隔离级别下，仅在事务第一次查询时生成ReadView，整个事务期间复用该ReadView，因此保证了多次查询结果一致。可重复读隔离级别下不会出现幻读：InnoDB通过Next-KeyLock（临键锁）解决了幻读问题，临键锁是记录锁和间隙锁的组合，当执行范围查询时，会锁住查询范围对应的所有记录以及记录之间的间隙，禁止其他事务在该范围内插入新数据，因此不会出现同一事务内两次范围查询得到的结果行数不一致的幻读问题。仅当使用当前读（select...forupdate）且没有加范围条件时，才有可能出现幻读。9.请说明MySQL主从延迟的常见原因、优化方案，以及MySQL8.0并行复制的实现原理答案：主从延迟的常见原因：①主库写入压力大，binlog生成速度快，网络传输带宽不足导致binlog同步到从库的延迟高；②从库单SQL线程回放binlog，写入速度跟不上主库的多线程写入速度；③大事务执行时间长，从库回放时需要等待整个事务执行完成，导致后续事务阻塞；④从库硬件配置低于主库，IO性能不足，无法支撑binlog的快速回放；⑤从库承担大量读请求，CPU、IO资源被读请求占用，导致回放速度慢。优化方案：①升级从库硬件配置，采用SSD/NVMe磁盘提升IO性能，配置与主库相同或更高的CPU、内存规格；②开启并行复制，提升从库binlog回放的并行度；③拆分大事务，将大事务拆分为多个小事务执行，减少回放阻塞时间；④主库采用分库分表架构，降低单库的写入压力；⑤搭建多从库集群，分摊读请求，降低单从库的读负载；⑥半同步复制调整为异步复制，降低主库写入等待时间，适合对数据一致性要求不高的场景。MySQL8.0并行复制实现：基于WRITESET（写集合）的并行复制机制，主库上同一批次提交的事务，只要修改的行没有冲突（即没有修改同一行数据），就会被标记为可并行执行，从库回放时可多线程并行执行这些事务，突破了MySQL5.7基于库级别的并行复制限制，并行度大幅提升，主从延迟可稳定控制在毫秒级。10.请说明分库分表的常见策略，以及分库分表后跨库关联查询、分页查询的解决方案答案：分库分表常见策略：①垂直分库：按业务模块拆分数据库，如将订单、用户、商品模块分别拆分为独立的数据库，降低单库的负载；②垂直分表：将大表的冷数据字段、大字段拆分到扩展表，如将用户表拆分为用户基础表（存储高频访问的用户名、手机号等）和用户详情表（存储低频访问的地址、个性签名等），提升单表查询性能；③水平分库分表：按分片键将数据拆分到多个库表中，常见分片规则包括哈希分片（适合均匀分布数据，负载均衡好）、范围分片（适合按时间、ID范围查询的场景）、一致性哈希分片（适合节点动态扩容的场景，避免数据大量迁移）。跨库关联查询解决方案：①字段冗余：将需要关联的字段冗余到主表中，避免跨库关联，如订单表冗余用户名字段，不需要关联用户表查询；②全局表：将数据量小、更新频率低的字典表、配置表在每个分库中都存储一份，同步更新，避免跨库关联；③宽表预聚合：将关联后的结果提前写入宽表，直接查询宽表即可，适合报表类查询场景；④异构索引：将全量数据同步到Elasticsearch、ClickHouse等引擎，先查询异构引擎得到主键列表，再到分库中批量查询详情。分页查询解决方案：①强制分页查询携带分片键，路由到单个分库执行，性能与单表分页一致；②不带分片键的分页查询，禁止深分页，限制最大查询页数不超过100页，超过的话通过缩小查询范围实现；③深分页查询通过异构索引实现，先在Elasticsearch中分页查询得到主键列表，再到分库中批量查询数据，避免全分库扫描。11.高并发场景下的库存扣减如何实现，避免超卖、少卖问题答案：根据并发量级和一致性要求，可选择以下三种方案：①基于MySQL乐观锁的方案：库存表新增version字段，扣减库存时执行SQL：update