Java对象浅拷贝后修改属性影响原对象，本质是引用被复制而非对象本身，排查重点在于识别引用类型字段、确认拷贝方式是否真为浅拷贝（如Object.clone()默认行为）、验证hashCode是否一致，并通过不可变设计或手动深拷贝修复。
Java中对象浅拷贝后修改属性影响原对象，本质是引用被复制而非对象本身，排查重点在于识别哪些字段是引用类型、哪些拷贝方式触发了这个问题。
确认是否真的用了浅拷贝
常见误区：以为调用了clone()或构造器就一定是深拷贝。实际上Object.clone()默认只复制基本类型和引用地址，属于典型浅拷贝。
- 检查类是否重写了
clone()方法，且内部是否对引用类型字段做了单独拷贝（如用new ArrayList(oldList)） - 若用第三方工具（如BeanUtils.copyProperties），需确认其默认行为——Spring的
BeanUtils不支持深拷贝，Apache Commons的BeanUtils.cloneBean()也仅浅拷贝 - 用IDEA调试时，在拷贝后打断点，对比新旧对象中某个引用字段（如List、Map、自定义对象）的
hashCode()是否一致，一致说明是同一对象
定位被共享的引用字段
不是所有字段都会出问题，只有引用类型字段（非String、Integer等不可变类型）才可能被意外共用。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 逐个检查对象的成员变量：数组、集合（ArrayList/HashMap）、自定义POJO、Date、StringBuilder等
- 特别注意嵌套结构，比如
User里有Address address，而Address又有List<string> phones</string>——浅拷贝会让三层引用都指向原对象 - 用
System.identityHashCode(obj)比obj.hashCode()更可靠，避免重写hashCode()干扰判断
验证修改是否真由浅拷贝引起
现象可能是浅拷贝导致，也可能是其他原因（如多线程共享、单例误用、静态字段）。需排除干扰。
立即学习“Java免费学习笔记（深入）”；
- 在拷贝后立即打印关键引用字段的
identityHashCode，再修改副本中的该字段内容，观察原对象对应字段是否同步变化 - 如果修改副本的
list.add(x)导致原对象list也增加，说明list引用相同；但若只是修改list.get(0).setName("xxx")，则要看get(0)返回的对象是否也被共享 - 临时把可疑字段改为
final或用不可变集合（如ImmutableList）测试，若问题消失，基本可锁定为浅拷贝泄漏
修复建议：按需选择深拷贝方案
不一定要全局深拷贝，关键是让业务逻辑需要隔离的字段真正独立。
- 对简单对象：手动在
clone()中逐个new引用字段，例如this.name = new String(original.name)、this.items = new ArrayList(original.items) - 对复杂嵌套：用序列化（如JSON反序列化）实现“伪深拷贝”，注意Serializable兼容性和性能；或引入Lombok的
@With+ 不可变设计 - 更推荐思路：避免拷贝，改用不可变对象（Immutable）或构建器模式，从源头消除共享风险
