记录类隐式声明组件字段为final，禁止在构造后进行修改。当使用紧凑构造函数——省略正式参数列表时，Java编译器禁止通过 this.component = ... 进行显式字段赋值，因为它会在构造函数体执行后自动注入赋值字节码。这项设计迫使开发人员自己重新分配参数变量（例如，component = Objects.requireNonNull(component)），而不是直接操作字段。因此，对于可变组件，防御性复制变得至关重要；由于记录存储的是引用，未能在紧凑构造函数内克隆可变参数将允许外部修改破坏记录的不变性保证。
在开发高频交易平台期间，架构团队采用记录类来表示包含BigDecimal价格和java.util.Date时间戳的不可变市场数据滴答。Date的可变性表现出一个关键漏洞，因为竞争条件可能允许生产者线程在记录实例化后修改时间戳对象，导致审计跟踪的损坏。
考虑了三种方法来减轻这一风险。第一种策略是迁移到java.time.Instant，这是一种不可变的时间类型。虽然这消除了防御性复制的开销并与现代Java时间API对齐，但它需要对序列化Date对象的遗留中间件组件进行大规模重构，增加了不可接受的交付风险。
第二个选项利用静态工厂方法在委派到规范构造函数之前执行防御性复制。这种方法保持了封装，但放弃了记录内在的简洁语法和自动结构相等的好处，此外还使预期规范构造函数模式的反序列化框架变得复杂。
最后的解决方案采用紧凑构造函数来验证输入并创建防御性克隆：timestamp = (Date) timestamp.clone();。这利用编译器的隐式字段赋值来存储克隆而不是原始引用，确保线程安全而不牺牲记录语义。
该实现成功防止了时间操控攻击，在后续涉及数百万次并发交易的压力测试中，没有发生数据损坏事件。
为什么编译器在紧凑构造函数中拒绝显式 this.field 赋值，而在常规构造函数中允许？
Java语言规范将紧凑构造函数定义为扩展为规范构造函数，其中编译器合成参数列表并附加字段赋值。由于记录组件隐式为final，紧凑构造函数体在预赋值状态下执行，此时字段被认为是“绝对未赋值”的。任何显式 this.field 的赋值都构成对final变量的第二次赋值，违反了确定性赋值规则，而重新分配参数变量是被允许的，因为它仅仅是遮蔽了后续的隐式赋值。
记录的紧凑构造函数中防御性复制如何保护免受使用ObjectInputStream的反序列化攻击？
与传统的Serializable类不同，JVM通过Unsafe分配实例化并通过反射或readObject方法填充，反序列化记录始终通过调用具有流提供参数的规范构造函数进行重建。因此，紧凑构造函数内执行的防御性复制逻辑自动清理恶意或损坏的输入流，防止尝试注入可变对象以便于后续修改。开发人员常常忽视这一机制，错误地在记录中实现readObject或readResolve方法，而这些方法在标准反序列化过程中既不必要也不被调用。
紧凑构造函数与记录中显式声明的规范构造函数之间有哪些字节码区别？
紧凑构造函数编译为字节码，其中invokespecial（调用Object构造函数）之后是构造函数的逻辑，然后是编译器生成的每个组件的putfield指令。而显式的规范构造函数内嵌了开发者编写的putfield操作。这一区别防止了紧凑构造函数在同一方法内进行字段初始化后的验证或逻辑，从根本上限制了初始化顺序，并要求所有防御性转换在隐式赋值执行之前对参数变量进行。