Java中不可变对象的核心判断标准是外部无法修改其逻辑状态，关键在于状态不可变且内部可变对象不泄露引用；final字段仅保证引用不变，不阻止内容修改，需对数组、Date、Collection等类型做防御性拷贝。
Java中不可变对象的核心判断标准是什么
一个类是不是不可变，不看有没有final字段，而看外部是否能修改其逻辑状态。哪怕所有字段都加了final，只要它持有可变对象（比如ArrayList、Date）且返回了原始引用，那就不是真正不可变。
关键在两点：状态不能被修改 + 内部可变对象不能泄露引用。很多开发者卡在这第二点上，以为加了final就万事大吉。
为什么只用final字段远远不够
final只保证引用不变，不保证对象内容不变。例如：final List<string> items = new ArrayList();</string> —— 你不能把items指向另一个List，但完全可以调用items.add("x")改内容。
- 常见错误：getter直接返回
private final List<t> data;</t>的原引用 - 正确做法：返回
Collections.unmodifiableList(data)，或新建副本（如new ArrayList(data)） - 注意：
unmodifiableXxx只是运行时防护，不阻止反射篡改；防御性拷贝才是更彻底的方案 - 性能权衡：每次getter都拷贝大集合会拖慢吞吐，需结合使用场景取舍
哪些类型必须做防御性拷贝
凡是你自己不控制其内部行为的类型，都要默认当作“可能被外部修改”的对象处理。典型包括：
立即学习“Java免费学习笔记（深入）”；
- 数组（
String[]、int[]等）—— 必须用Arrays.copyOf()或clone() -
java.util.Date、Calendar—— 已废弃但仍有存量代码，必须拷贝并转为Instant或用new Date(original.getTime()) - 任何实现了
Collection、Map、Set接口的类（即使你自己写的）—— 只要没封装成不可变视图，就要拷贝 - 自定义可变类（比如
MutablePoint）—— 如果它的字段没全final，或没封住修改方法，就必须深拷贝
构造函数里如何安全接收外部传入的可变对象
构造器是不可变对象的“第一道闸门”。如果允许外部传入ArrayList或byte[]，那这个对象从诞生起就不安全。
- 禁止直接赋值：
this.items = items;❌ - 推荐防御性拷贝：
this.items = new ArrayList(items);✅（前提是items元素本身也不可变） - 如果元素可变（比如
List<mutableconfig></mutableconfig>），就得逐个拷贝：items.stream().map(MutableConfig::copy).collect(toList()) - 避免意外共享：不要在构造器里调用可能被子类重写的
init()方法，防止子类在父类初始化完成前暴露this
最常被忽略的一点：连toString()、hashCode()这类方法里，如果用到了内部可变对象，也要确保它们不会间接暴露可变状态——比如别在toString()里返回items.toString()，除非items本身已不可变或已被封装。
