JPA 高频面试题（真实面试版）

JPA高频面试题（真实面试版）一、基础概念面试题（初级必问）1、简单说下什么是JPA？它和JDBC的区别是什么？JPA是Java持久层规范，是一套标准化的ORM接口，本身不实现具体功能，仅定义数据库操作的统一标准，常见的实现框架有Hibernate、EclipseLink等。和JDBC的核心区别：JDBC是原生数据库操作API，需要手动写SQL、处理结果集、手动关闭连接，代码冗余度高；JPA基于ORM思想，通过实体类映射数据库表，可通过对象操作实现增删改查，大幅减少样板代码，同时屏蔽了不同数据库的语法差异，便于项目数据库迁移。2、JPA、Hibernate、SpringDataJPA三者的关系？面试中经常被混淆JPA是规范接口，是官方定义的持久层标准，无具体实现；Hibernate是JPA的具体实现框架，是底层执行者，实现了JPA所有接口，同时提供了很多拓展功能；SpringDataJPA是Spring封装的上层框架，基于JPA规范和Hibernate底层，进一步简化了持久层开发，不用写实现类，仅通过接口方法名、注解就能完成数据库操作，是目前项目中最常用的版本。3、JPA的核心常用注解有哪些？分别说下作用@Entity：标识当前类为数据库实体类，可被JPA管理；@Table：映射实体类对应的数据库表名，可指定表名、索引、唯一约束；@Id：标注数据库主键字段；@GeneratedValue：配置主键生成策略，包含自增、UUID、数据库序列等方式；@Column：映射表字段，可设置字段长度、是否为空、唯一、备注等属性；@Transient：标识临时字段，该字段不映射数据库表字段；@Temporal：处理日期类型字段，指定日期、时间、年月日格式；@Enumerated：枚举类型字段映射，解决枚举与数据库数值的转换问题。4、JPA主键的几种生成策略？各自适用场景IDENTITY：数据库自增，依赖数据库自增主键，MySQL常用，插入数据后才会生成主键；SEQUENCE：数据库序列，Oracle、PostgreSQL常用，通过序列生成主键；TABLE：通过单独的表维护主键，兼容性强，所有数据库都支持，性能较差；AUTO：默认策略，框架自动根据数据库类型选择对应的主键生成方式。5、@Transient注解的使用场景是什么？实体类中部分字段仅用于业务计算、页面展示，不需要持久化到数据库，就可以用该注解标注。比如用户实体的密码确认字段、临时计算的积分总和、拼接的展示名称等，避免多余字段映射数据库，减少数据库冗余字段。二、SpringDataJPA核心面试题（中级核心）1、SpringDataJPA的核心原理是什么？为什么只需要写接口不用写实现类？核心原理是动态代理+方法名解析。项目启动时，Spring会扫描所有继承JpaRepository的接口，通过JDK动态代理自动生成接口的代理实现类。开发者定义的接口方法名遵循固定命名规则（findBy、countBy、existsBy、deleteBy等），框架会自动解析方法名，拼接对应的JPQL语句，自动完成数据库操作，因此无需手动编写实现类和SQL。2、SpringDataJPA支持的查询方式有几种？三种主流方式：1、方法名命名查询：通过规范方法名实现简单条件查询，无需写SQL，适合简单单表查询；2、@Query注解查询：支持自定义JPQL语句和原生SQL语句，适合复杂多条件、关联查询；3、Specification动态查询：用于多条件动态拼接的复杂查询，避免编写大量冗余的@Query方法，适配前端动态传参场景。3、@Query中JPQL和原生SQL的区别？什么时候用原生SQL？JPQL是面向实体对象的查询语言，操作的是实体类和属性，不依赖数据库方言，可跨数据库适配，语法更面向对象；原生SQL是直接操作数据库表和字段，执行效率更高，支持数据库专属函数、复杂分页、批量操作、联表复杂查询。一般简单查询用JPQL，涉及数据库特殊函数、海量数据分页、复杂统计、存储过程调用时，使用原生SQL。4、SpringDataJPA分页查询怎么实现？Page和Pageable的使用细节分页核心依赖Pageable参数，接口方法中传入Pageable对象，返回值定义为Page<实体类>即可实现分页。Pageable需要指定页码、每页条数、排序规则，注意JPA分页页码从0开始，和前端常见的从1开始的页码需要做转换。Page对象可以获取总条数、总页数、当前页数据、是否首尾页等分页信息，自带分页封装，无需手动统计总数。5、JPA的修改和删除操作，必须加@Modifying和@Transactional吗？为什么？自定义的更新、删除接口方法，必须添加这两个注解。@Modifying：告知Spring这是数据修改操作，而非查询操作，框架会执行update/delete语句；@Transactional：JPA的写操作需要事务支持，否则会抛出事务异常，同时保证数据操作的原子性，避免数据不一致。注意：默认的save、delete内置方法已经封装了事务，无需手动加注解。三、ORM映射与关联关系（中高级重点）1、JPA的四种关联关系？分别对应什么业务场景？一对一（@OneToOne）：比如用户和用户详情、员工和工号，一一对应关系；一对多（@OneToMany）：比如部门和员工、订单和订单详情，一个主体对应多个子数据；多对一（@ManyToOne）：员工对应所属部门、订单详情对应订单，多个子数据对应一个主体；多对多（@ManyToMany）：用户和角色、角色和权限，双向多关联场景。2、@OneToMany和@ManyToOne如何选择？谁是维护端、谁是被动端？多对一是关系维护端，负责维护外键字段，数据新增、修改时由多的一方维护关联关系；一对多是关系被动端，必须配置mappedBy属性，放弃外键维护权，避免双向维护导致数据冗余、死循环更新。实际开发中，优先用多对一，少用一对多，减少数据库外键维护压力，提升性能。3、多对多关联关系怎么处理？中间表需要额外字段怎么办？常规无额外字段的中间表，直接使用@ManyToMany注解即可，框架自动生成中间表；如果中间表需要新增创建时间、操作人、状态等自定义字段，禁止使用原生多对多注解，需要将中间表单独建实体类，通过两个多对一关联关系，分别关联两个主表，灵活操作中间表字段。4、JPA的懒加载和急加载区别？什么时候用懒加载？急加载（EAGER）：查询主实体时，立即加载关联数据，默认多对一、一对一为急加载；懒加载（LAZY）：查询主实体时，仅加载主数据，访问关联属性时才会查询关联数据，默认一对多、多对多为懒加载。业务中大部分关联查询都建议用懒加载，避免一次性查询大量无关关联数据，造成性能浪费，解决数据冗余加载问题。5、懒加载出现couldnotinitializeproxy-noSession异常的原因和解决方案？原因：实体对象已经脱离持久化上下文，Session已经关闭，此时访问懒加载的关联属性，无法触发数据库查询，抛出异常。常见于查询后在Controller层、前端渲染时访问关联数据。解决方案：1、业务层提前获取需要的关联数据；2、使用JOINFETCH关联查询，一次性加载关联数据；3、开启事务延长Session生命周期（不推荐，影响性能）。四、缓存、事务与性能优化（进阶面试题）1、JPA的一级缓存和二级缓存区别？默认开启哪个？一级缓存（Session缓存）：默认开启，作用域为单次事务、单次请求，缓存当前会话中的实体对象，避免重复查询同一数据，会话关闭后缓存失效；二级缓存：默认关闭，作用域为全局应用，跨会话、跨请求生效，可缓存公共的、不常变更的数据，需要手动配置开启，适合字典、配置类静态数据。2、JPAsave方法是新增还是更新？底层判断逻辑是什么？save方法是新增还是更新，完全根据主键判断：如果实体主键为null/默认空值，判定为新增，执行insert语句；如果实体主键有值，判定为更新，执行update语句。面试高频坑：自增主键场景下，手动设置主键会导致误执行更新操作，覆盖原有数据。3、JPA批量新增、批量更新为什么不推荐用循环save？怎么优化？循环save会频繁触发SQL执行，每次save都会交互数据库，大量数据场景下IO开销极大，性能极差，同时会产生大量事务日志。优化方案：使用JPA自带的批量保存方法saveAll，同时配置hibernate批量操作参数，开启批量提交，减少数据库交互次数。4、JPAN+1查询问题是什么？如何解决？问题场景：查询一批主数据（1次查询），遍历每条数据时，每条都会单独查询关联数据（N次查询），总共N+1次数据库查询，海量数据下性能瓶颈严重。解决方案：1、使用JOINFETCH联表查询，一次性加载主表和关联表数据；2、通过@EntityGraph指定预加载关联属性；3、避免循环中单独查询数据库。5、JPA事务失效的常见场景有哪些？1、方法非public修饰，事务无法生效；2、同类中方法内部自调用，绕过Spring动态代理，事务失效；3、异常类型不匹配，默认仅回滚RuntimeException，普通Exception不会触发回滚；4、数据库引擎不支持事务（如MyISAM）；5、多线程场景下，事务上下文不共享，子线程事务独立。五、实战坑点与压轴面试题（面试加分项）1、JPA中@DynamicUpdate注解的作用？什么时候必须用？默认JPA更新数据时，会更新实体所有字段，无论字段是否修改；添加@DynamicUpdate后，会自动对比新旧实体数据，只更新发生变更的字段。适用场景：字段多、大文本字段、频繁更新部分字段的实体，可减少SQL体积，提升更新性能，避免无意义的字段更新。2、JPA实体类字段和数据库字段大小写不一致会报错吗？怎么解决？MySQL默认不区分大小写，但Windows环境下可能出现映射异常，Linux环境严格区分。解决方案：通过@Column手动指定数据库字段名，统一映射规则，避免环境兼容问题。3、SpringDataJPA和MyBatis的优缺点对比？项目中如何选型？JPA优点：开发速度快、代码极简、ORM映射规范、数据库兼容性好、无需手写大量SQL；JPA缺点：复杂SQL、多表超级联表、海量数据统计场景灵活性差，容易出现性能问题，新手易踩N+1、懒加载坑；MyBatis优点：SQL可控、灵活度高、性能可精准优化、适配复杂业务查询；MyBatis缺点：代码冗余，需要维护大量XML/注解SQL，开发效率低。选型：中小型项目、业务简单、CRUD多、追求开发效率选JPA；大型复杂项目、复杂统计查询、高性能要求场景选MyBatis。4、JPA如何实现乐观锁？解决并发修改问题通过@Version注解实现乐观锁，在实体类中添加version版本字段。数据更新时，框架会自动校验