JDK系列13：记录类Record、密封类Sealed Class，规范化数据载体

文章目录

• • 一、前言：传统Java建模的两大痛点
  • • 1.1 数据载体极度冗余
    • 1.2 类继承完全失控
  • 二、Record 记录类：极简不可变数据载体
  • • 2.1 核心设计思想
    • 2.2 传统POJO VS Record 对比
    • • 传统Java POJO（冗余版）
      • Record 极简写法
    • 2.3 Record 底层编译机制
    • 2.4 Record 自定义拓展能力
    • • 2.4.1 紧凑构造器（核心：参数校验）
      • 2.4.2 自定义方法与静态工具
    • 2.5 Record 强制约束（避坑重点）
    • 2.6 Record 生产级适用场景与禁忌场景（落地指南）
    • 2.7 Record VS Lombok @Data 深度对比（生产必看）
  • 三、Sealed Class 密封类：可控的继承体系
  • • 3.1 为什么需要密封类？
    • 3.2 密封类核心语法
    • 3.3 完整实战案例：业务支付类型层级
    • • 3.3.1 定义密封父类
      • 3.3.2 子类实现规则
    • 3.4 三层继承进阶：sealed + non-sealed 组合
    • 3.5 密封接口
    • 3.6 密封类核心优势与适用场景
    • • 优势
      • 适用场景
  • 四、Record + Sealed Class 王炸组合（高阶实战）
  • • 4.1 高阶拓展：结合模式匹配实现穷尽分支
  • 五、高频面试真题 + 核心考点总结
  • • 5.1 Record 核心考点
    • 5.2 Sealed Class 核心考点
  • 六、总结

📌 专栏：JDK核心进阶系列

🎯 适用人群：Java后端开发者、面试备考者、技术进阶学习者

🔥 核心看点：告别冗余POJO、根治继承滥用、打造类型安全的规范化数据模型

Java 从 JDK8 之后进入高速迭代阶段，不再局限于性能优化，更多聚焦代码规范化、语法轻量化、类型安全升级。很多开发者疑惑：Record和Sealed Class看似不是重磅颠覆性API，却是 Java 建模体系的重要转折点——Record记录类解决了冗余数据载体定义问题，Sealed Class密封类终结了无限制继承的混乱局面。

二者强强联合，彻底重构了 Java 的数据建模与类层级设计思想，让代码更简洁、层级更严谨、类型更安全。本文将从零拆解这两大Java高阶特性，对比传统写法、详解语法规则、实战场景与避坑要点，带你吃透规范化建模核心能力。

---

一、前言：传统Java建模的两大痛点

在 Record 和 Sealed Class 出现之前，Java 建模存在两个长期被诟病的硬伤，也是日常开发中最常见的代码冗余、架构混乱的根源：

1.1 数据载体极度冗余

定义一个简单的数据实体（DTO、VO、参数实体），必须手动编写构造器、getter/setter、toString、equals、hashCode等大量模板代码。即便目前主流通过Lombok注解（@Data、@AllArgsConstructor）简化开发，依然存在诸多无法规避的问题：第一，引入第三方依赖，增加项目依赖风险；第二，Lombok 编译期注解在部分 IDE、编译插件环境下容易出现编译报错、代码不生效问题；第三，@Data 注解存在坑点，会重写 equals 与 hashCode，忽略父类属性，同时无法天然保证数据不可变；第四，大量模板代码隐藏业务逻辑，代码可读性与规范性极差。

1.2 类继承完全失控

Java 原生类继承机制过于开放：非 final 类默认可以被任意子类继承。在大型项目、框架开发中，父类的层级无法约束，开发者可以随意扩展子类，导致类层级混乱、架构不可控、分支逻辑泛滥，后期维护成本极高。

而 Java 推出的 Record、Sealed Class 正是为解决这两大痛点而生，分别从数据载体规范化和继承体系规范化两个维度，补齐 Java 建模短板。

---

二、Record 记录类：极简不可变数据载体

Record 是 JDK13 推出的预览特性，JDK16 正式纳入正式语法，是 Java 官方为解决「数据载体冗余、可变安全问题」推出的原生特性。其核心定位非常纯粹：用于承载不可变数据、无复杂业务逻辑、仅用于状态传输的规范化数据载体，彻底替代传统模板化 POJO，告别 Lombok 依赖。

2.1 核心设计思想

Record 的设计初衷：数据即状态，无副作用、可透明访问、自动实现基础方法。它是一种特殊的隐式 final 类，默认具备不可变性，编译器自动生成所有模板代码，彻底告别 POJO 冗余。

2.2 传统POJO VS Record 对比

我们以常见的「用户登录数据载体」为例，直观感受差异：

传统Java POJO（冗余版）

publicclassUserLoginDTO{// 成员变量privateStringusername;privateStringpassword;privateIntegerloginType;// 无参构造publicUserLoginDTO(){}// 全参构造publicUserLoginDTO(Stringusername,Stringpassword,IntegerloginType){this.username=username;this.password=password;this.loginType=loginType;}// Getter & SetterpublicStringgetUsername(){returnusername;}publicvoidsetUsername(Stringusername){this.username=username;}publicStringgetPassword(){returnpassword;}publicvoidsetPassword(Stringpassword){this.password=password;}publicIntegergetLoginType(){returnloginType;}// toString@OverridepublicStringtoString(){return"UserLoginDTO{"+"username='"+username+'\''+", password='"+password+'\''+", loginType="+loginType+'}';}// equals & hashCode@Overridepublicbooleanequals(Objecto){if(this==o)returntrue;if(o==null||getClass()!=o.getClass())returnfalse;UserLoginDTOthat=(UserLoginDTO)o;returnObjects.equals(username,that.username)&&Objects.equals(password,that.password)&&Objects.equals(loginType,that.loginType);}@OverridepublicinthashCode(){returnObjects.hash(username,password,loginType);}}

Record 极简写法

// 一行代码搞定所有模板代码publicrecordUserLoginRecord(Stringusername,Stringpassword,IntegerloginType){}

差距一目了然：Record 仅一行代码，自动包含全参构造、属性访问方法、toString、equals、hashCode，零模板代码。

2.3 Record 底层编译机制

Record 并非简单的语法糖，是JVM 层面原生支持的特殊类型，编译阶段编译器会自动为我们生成固定逻辑的字节码，我们可以通过反编译清晰看到底层实现，核心规则如下：

• 隐式 final 修饰，禁止继承：Record 类编译后默认被 final 修饰，无法被任何子类继承，保证数据载体的唯一性与稳定性。

• 组件字段默认 private final，天然不可变：头部声明的所有属性，编译后自动被 private final 修饰，初始化后无法修改，天然保证线程安全。

• 自动生成规范全参构造器：严格按照属性声明顺序生成全参构造，为所有 final 字段完成初始化赋值，无无参构造。

• 无 get 前缀的属性访问方法：摒弃传统 JavaBean get 规范，直接以字段名作为方法名，简洁直观，例如 username()、password()。

• 精准重写三大核心方法：自动生成适配当前所有字段的 toString()、equals()、hashCode()，规避手动编写与 Lombok 的逻辑漏洞。

• 隐式继承 java.lang.Record：所有 Record 类默认直接继承顶层 Record 父类，无法继承其他任何类，单继承结构固定。

2.4 Record 自定义拓展能力

Record 不是“只能写一行”，支持自定义构造器、静态方法、实例方法、校验逻辑，适配复杂业务。

2.4.1 紧凑构造器（核心：参数校验）

紧凑构造器不会重复定义参数列表，专门用于做入参校验、数据预处理，是 Record 最常用的进阶写法：

publicrecordUserLoginRecord(Stringusername,Stringpassword,IntegerloginType){// 紧凑构造器：参数校验publicUserLoginRecord{if(username==null||username.isBlank()){thrownewIllegalArgumentException("用户名不能为空");}if(password==null||password.length()<6){thrownewIllegalArgumentException("密码长度不能小于6位");}}}

2.4.2 自定义方法与静态工具

publicrecordUserLoginRecord(Stringusername,Stringpassword,IntegerloginType){// 实例方法publicbooleanisPhoneLogin(){return2.equals(loginType);}// 静态工具方法publicstaticUserLoginRecorddefaultWebLogin(Stringusername,Stringpassword){returnnewUserLoginRecord(username,password,1);}}

2.5 Record 强制约束（避坑重点）

Record 的语法约束非常严格，这也是其保证数据安全、结构纯粹的核心原因，同时也是面试高频深挖考点，详细约束与原理如下：

1. 禁止声明自定义实例变量：所有实例状态必须在类头组件参数中声明，方法体内部只能定义静态变量、常量，不能新增非 final 实例字段，避免状态混乱。

2. 仅能隐式继承 Record 类：无法 extends 任何自定义父类，保证所有记录类的底层统一性，简化 JVM 处理逻辑。

3. 禁止被继承、禁止重写父类final方法：隐式 final 特性杜绝子类篡改数据结构，保证数据载体的一致性。

4. 支持接口实现与静态拓展：可以实现任意接口，支持静态字段、静态方法、实例方法，具备一定拓展能力，并非完全僵化。

5. 紧凑构造器必须全覆盖字段：紧凑构造器仅用于参数校验与预处理，无需手动赋值，编译器自动完成所有 final 字段赋值，无法跳过任意字段。

6. 无默认无参构造器：Record 仅存在全参构造与自定义紧凑构造，不存在无参构造，无法空初始化，规避空数据载体问题。

2.6 Record 生产级适用场景与禁忌场景（落地指南）

2.7 Record VS Lombok @Data 深度对比（生产必看）

很多开发者会疑惑：已经有 Lombok 了，为什么还要用 Record？二者核心差异极大，生产环境选型差异明显：

对比维度	Record 记录类	Lombok @Data
依赖方式	JDK 原生，无第三方依赖	第三方插件依赖，需引入maven依赖
可变性	字段默认 final，天然不可变、线程安全	默认可变，存在线程安全风险
代码规范性	JVM 强制约束，结构统一规范	依赖注解，易出现滥用、逻辑漏洞
编译稳定性	原生支持，无编译报错、IDE适配问题	IDE 版本不兼容、编译插件缺失会报错
equals/hashCode 逻辑	全覆盖当前字段，逻辑严谨无坑	忽略父类字段，容易出现判等bug
拓展能力	受限拓展，保证数据纯粹性	无强制约束，可随意修改属性

结论：简单数据载体优先使用 Record，无需 Lombok；需要可变属性、复杂拓展的实体，再考虑 Lombok。

---

• **✅ 核心适用场景（生产推荐）**前后端交互：接口入参 DTO、响应 VO、分页结果封装

• 数据查询载体：Mybatis/数据库单条查询结果、多表联查临时封装类

• 方法增强：多返回值方法封装、复杂参数分组传输

• 常量配置：系统固定配置、枚举配套数据、字典数据载体

• 线程安全场景：多线程传输数据、消息队列消息实体（天然不可变）

• **❌ 禁忌使用场景（避坑）**需要属性修改的业务实体：CRUD 数据库实体、需要 set 赋值的可变对象

• 需要被继承拓展的基础实体：公共父类、通用拓展模型

• 存在复杂生命周期、属性动态变化的业务对象

---

三、Sealed Class 密封类：可控的继承体系

如果说 Record 是规范数据，那 Sealed Class 就是规范类型。

Sealed Class 于 JDK15 预览、JDK17 正式转正，核心作用：限制类的继承范围，父类指定允许继承的子类，彻底杜绝随意继承。

3.1 为什么需要密封类？

传统 Java 类只有两种状态：

• final 类：完全不能被继承

• 普通类：所有人都能继承

传统 Java 的类继承只有「完全开放」和「完全禁止」两种极端，中间缺失可控继承的能力：很多业务场景中，父类只希望被指定的少数子类实现，禁止全局随意拓展，这是 final 和普通类都无法实现的空白场景。

在大型项目、框架开发、业务状态机设计中，无限制继承会导致严重的架构问题：子类泛滥、层级混乱、业务分支不可控、代码维护成本飙升。而密封类的出现，完美填补了 Java 继承体系的空白，实现精准、可控、可追溯的继承层级，是现代 Java 架构规范化的核心特性。

3.2 密封类核心语法

密封类的语法体系由四个核心关键字组成，各司其职，构成完整的可控继承体系，也是开发和面试必须掌握的核心：

• sealed：修饰抽象类、普通类、接口，标识当前类型为密封类型，开启继承权限管控，禁止随意继承。

• permits：核心限定关键字，明确列出允许继承/实现的子类列表，未列出的类一律禁止继承，编译器强制校验。

• final子类：终止继承链路，当前子类不再允许被任何类继承（生产最常用，保证层级稳定）。

• sealed子类：继承父类密封特性，继续管控下一级子类，实现多层级精准约束。

• non-sealed子类：打破密封约束，放开继承权限，恢复传统类的自由继承特性，用于部分可拓展的业务节点。

3.3 完整实战案例：业务支付类型层级

场景：支付方式固定为微信、支付宝、银行卡三种，禁止新增其他支付类型

3.3.1 定义密封父类

// 密封类：仅允许指定三个子类继承publicsealedabstractclassPayTypepermitsWechatPay,AliPay,BankPay{// 抽象支付方法publicabstractvoidpay(BigDecimalamount);}

3.3.2 子类实现规则

密封类的子类必须明确后续继承权限：

1. final 子类：彻底关闭继承（最常用）

2. sealed 子类：继续密封，限制下级子类

3. non-sealed 子类：放开继承，恢复传统自由继承

// final 终止继承publicfinalclassWechatPayextendsPayType{@Overridepublicvoidpay(BigDecimalamount){System.out.println("微信支付："+amount);}}// final 终止继承publicfinalclassAliPayextendsPayType{@Overridepublicvoidpay(BigDecimalamount){System.out.println("支付宝支付："+amount);}}// final 终止继承publicfinalclassBankPayextendsPayType{@Overridepublicvoidpay(BigDecimalamount){System.out.println("银行卡支付："+amount);}}

此时如果新建新的子类继承 PayType（如 UnionPay 银联支付），IDE 会直接标红报错，编译阶段直接拦截，从根源杜绝非法拓展，保证业务支付类型的唯一性与可控性，完美适配固定业务场景！

3.4 三层继承进阶：sealed + non-sealed 组合

部分场景需要：顶层约束、中层放开拓展，演示组合用法：

// 顶层密封类：只允许动物、鸟类两个大类继承publicsealedabstractclassAnimalpermitsMammal,Bird{}// 中层放开继承：可以自由拓展哺乳动物子类publicnon-sealedabstractclassMammalextendsAnimal{}// 继续密封：鸟类仅允许飞禽、水禽publicsealedabstractclassBirdextendsAnimalpermitsFlyBird,WaterBird{}// 最终终止publicfinalclassFlyBirdextendsBird{}publicfinalclassWaterBirdextendsBird{}// 自由拓展子类，合法publicclassDogextendsMammal{}publicclassCatextendsMammal{}

3.5 密封接口

sealed 同样支持接口，约束接口的实现类：

publicsealedinterfaceOperationpermitsAddOperation,SubOperation{intcalculate(inta,intb);}publicfinalclassAddOperationimplementsOperation{@Overridepublicintcalculate(inta,intb){returna+b;}}publicfinalclassSubOperationimplementsOperation{@Overridepublicintcalculate(inta,intb){returna-b;}}

3.6 密封类核心优势与适用场景

优势

• 架构可控：杜绝随意继承，规范类层级结构

• 穷尽分支判断，消除代码隐患：结合 JDK17+ 模式匹配 switch，可实现对子类的穷尽匹配，无需编写 default 分支，杜绝分支遗漏bug

• 可读性极强：permits 列表直接展示所有子类，一目了然

适用场景

• 固定业务类型：支付方式、订单状态、消息类型、操作类型

• 框架底层设计：统一约束拓展类，防止滥用继承

• 状态机、枚举体系的高阶替代方案

---

四、Record + Sealed Class 王炸组合（高阶实战）

两者结合可以实现类型安全、不可变、层级可控的完美业务模型，是现代 Java 最佳建模实践。

场景：定义统一消息体，消息类型固定为文本、图片、文件，不可新增类型，消息数据不可变。

// 密封父类：固定三种消息类型publicsealedinterfaceMessagepermitsTextMessage,ImageMessage,FileMessage{}// Record 实现密封接口：不可变数据载体publicrecordTextMessage(Stringcontent,LongsendTime)implementsMessage{}publicrecordImageMessage(Stringurl,Integerwidth,Integerheight)implementsMessage{}publicrecordFileMessage(StringfileName,StringfilePath,Longsize)implementsMessage{// 紧凑构造器校验文件大小publicFileMessage{if(size>1024*1024*100){thrownewIllegalArgumentException("文件不能超过100M");}}}

核心落地效果：

1. 所有消息数据不可变，线程安全

2. 无任何模板代码，极度简洁

3. 禁止新增其他消息类型，架构严格可控

4. 支持穷尽式Switch模式匹配：无需default分支，编译期校验所有消息类型，彻底杜绝分支遗漏

4.1 高阶拓展：结合模式匹配实现穷尽分支

Record + Sealed Class 最大的生产价值，就是搭配 JDK17 模式匹配，实现类型安全的穷尽逻辑判断，彻底消灭 switch default 兜底、if-else 冗余判断：

publicclassMessageHandler{// 穷尽所有消息类型，新增类型编译报错，绝对安全publicstaticvoidhandleMessage(Messagemessage){switch(message){caseTextMessagetext->System.out.println("处理文本消息："+text.content());caseImageMessageimg->System.out.println("处理图片消息："+img.url());caseFileMessagefile->System.out.println("处理文件消息："+file.fileName());}}}

核心优势：如果后续新增任何 Message 实现类，编译器直接报错，提示分支未覆盖，从编译期规避业务逻辑遗漏，这是传统继承体系完全无法实现的能力。

---

---

五、高频面试真题 + 核心考点总结

5.1 Record 核心考点

• Q：Record 的 JDK 版本迭代？
  A：JDK13 预览特性，JDK16 正式转正，长期可用。

• Q：Record 默认的修饰符与字段特性？
  A：类隐式 final、字段隐式 private final、天然不可变、线程安全。

• Q：Record 自动生成哪些方法？和传统POJO的区别？
  A：自动生成全参构造、字段访问方法、toString、equals、hashCode；无get前缀、无set方法、不可变。

• Q：Record 紧凑构造器的作用和特点？
  A：无参数列表，仅用于参数校验和数据预处理，无需手动赋值，编译器自动完成字段初始化。

• Q：Record 能否继承类、能否被继承？
  A：只能继承 java.lang.Record，无法继承自定义类；自身隐式 final，禁止被继承。

5.2 Sealed Class 核心考点

• Q：Sealed Class 版本迭代？
  A：JDK15 预览，JDK17 正式转正，是Java17核心新特性。

• Q：密封类的核心原理与作用？
  A：通过 sealed+permits 限定子类范围，解决继承失控问题，实现可控层级架构。

• Q：密封子类的三种修饰方式及区别？
  A：final（终止继承）、sealed（继续约束）、non-sealed（放开继承）。

• Q：密封类最大的生产价值？
  A：固定业务类型、规范架构层级、支持穷尽式分支判断，编译期规避代码bug。

• Q：Record+Sealed 组合的核心优势？
  A：实现层级可控、数据不可变、类型安全、分支穷尽的现代化Java建模方案。

---

六、总结

Java 8 之后的现代化新特性，核心演进思路就是：去模板化、强类型安全、架构规范化。而 Record 和 Sealed Class 正是该思路下的核心落地特性，彻底革新了传统 Java 臃肿、混乱的建模方式：

• Record 记录类：干掉 POJO 模板代码，打造极简、不可变、安全的数据载体，彻底替代简单 DTO/VO 模板类。

• Sealed Class 密封类：终结自由继承，让类层级从“无序”变为“有序可控”，大幅提升代码可维护性与架构严谨度。

目前 Java17+ 已是企业主流长期支持版本，Sealed Class + Record + 模式匹配已经成为企业级项目的标准建模最佳实践。熟练掌握这两大特性，不仅能简化日常开发、规避线上bug，更能搭建更规范、更安全、更易维护的项目架构，是中高级 Java 开发者的必备核心能力。

---

💡 往期推荐

JDK新特性系列：Lambda、Stream、Optional、新日期API、虚拟线程等持续更新中

👉 关注博主，持续深耕Java进阶技术，规避开发踩坑！