Lombok重构POJO：成员声明时直接实例化的潜在问题咨询

我们团队正在重构一款应用，引入Lombok简化POJO的编写与阅读。这次重构存在一些争议点，不过错误本身也是成长的契机。

重构前的类 #

package eu.middle.services.app.generiques.model;

import java.time.LocalDate;
import java.util.List;

public class Stabilite {

    private LocalDate dateMiseAJour;
    private LocalDate dateFin;
    private List<Molecule> liste;

    public Stabilite() {
        super();
    }

    public Stabilite(LocalDate dateMiseAJour, LocalDate dateFin, List<Molecule> liste) {
        super();
        this.dateFin = dateFin;
        this.dateMiseAJour = dateMiseAJour;
        this.liste = liste;
    }

    public LocalDate getDateFin() {
        return dateFin;
    }

    public void setDateFin(LocalDate dateFin) {
        this.dateFin = dateFin;
    }

    @Override
    public boolean equals(Object obj) {// NOSONAR
        ....
    }
// 其他getter/setter、hashCode、toString方法

}

重构后的类 #

package eu.middle.services.app.generiques.model;

import java.io.Serializable;
import java.time.LocalDate;
import java.util.ArrayList;
import java.util.List;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Stabilite implements Serializable {

    private static final long serialVersionUID = 2356231377315682966L;

    private LocalDate dateMiseAJour;
    private LocalDate dateFinObservation;
    private List<Molecule> liste = new ArrayList<>();
}

本次重构中，将原本的private List<Molecule> liste;修改为private List<Molecule> liste = new ArrayList<>();，目前已有近百个类做了这类修改，我对此持反对态度，现咨询以下问题：

1. 这是否会造成不必要的内存消耗？ #

会产生不必要的内存消耗：

• 如果对象创建后liste字段从未被使用（比如某些业务场景不需要这个列表），提前初始化的空ArrayList会白白占用内存；若这类对象被大量创建（如批量处理场景），累积的内存开销会很可观。
• 空ArrayList本身会占用固定内存（比如内部初始容量的数组内存），哪怕没有存储任何元素。

2. 这是否会影响多态性？ #

会限制多态性的灵活度：

• 原设计中外部可以传入任意List接口的实现类（如LinkedList、CopyOnWriteArrayList），适配不同业务场景的需求；但现在字段默认初始化为ArrayList，若后续代码依赖了这个初始类型（比如强转成ArrayList），会埋下类型转换隐患。
• 无参构造创建的对象中liste固定为ArrayList，而通过全参构造传入其他List实现时会覆盖这个值，导致同一类的不同实例行为可能不一致，比如需要LinkedList的首尾操作特性时，无法通过无参构造得到符合需求的对象。

3. 还有哪些我未考虑到的问题？ #

• 序列化/反序列化逻辑冲突：由于类实现了Serializable，反序列化时若原数据中liste为null，反序列化后会变成空ArrayList，这会和原有依赖liste == null判断数据是否存在的逻辑冲突，引发业务错误。
• 空值判断逻辑失效：原有代码中可能存在if (liste == null)的分支处理，现在字段永远不为null，这些判断会直接失效，导致原本预期的逻辑（比如初始化默认数据）无法执行，或空列表被误判为有数据。
• 构造方法的状态不一致：无参构造创建的对象liste是空ArrayList，但全参构造若传入null，liste会变成null，同一类的实例出现两种不同的字段状态，增加了代码复杂度和出错概率。
• ORM框架兼容性问题：如果使用Hibernate等ORM框架加载对象，框架会自行处理集合的初始化逻辑，手动提前初始化可能和框架逻辑冲突，引发额外的对象创建或数据加载异常。

内容的提问来源于stack exchange，提问作者bedomon