深拷贝--实现（多线程时可能争抢同一引用导致出错比如null比如数据错乱，故线程间需要资源“隔离”：局部变量+深拷贝）

浅谈BeanUtils的拷贝，深度克隆

（String天然深拷贝。

基本类型的包装类因为final所以也是天然深拷贝。java的深浅复制是针对对象来说的;按照理论，包装类型也应该是浅复制;但是下面是Integer的源码;原来包装类型和String一样被final修饰了，所以就直接是深复制了，被复制者，与复制者之间没有关系了。并且它没有重写Object的clone方法，而作为对比HashMap重写了Object的clone方法。

Date已经自己实现了clone深拷贝，可以直接调用。
）

(解决：1.串行化（Serilization）持久化，使之就是两个物品

java中的深拷贝和浅拷贝（clone()方法的重写、使用序列化实现真正的深拷贝）

2.手动实现Cloneable 接口的clone方法

Cloneable接口的作用与深入理解深度克隆与浅度克隆

	
public class EhrWfStaffChangeEntity implements Serializable, BasicExportModel,Cloneable  {

@Override
	public Object clone() {
		EhrWfStaffChangeEntity change = null;
		try {
			change = (EhrWfStaffChangeEntity) super.clone();
			//如果属性是引用类型&&非null需要clone，再层层clone ↓ 如
            change.staff = (Staff)staff.clone();
/**
     staff若存在引用类型的属性，
则
staff实现clone并在这把这个父clone里把staff属性也明确clone。直到都是String或基本类型包装类
或Date等java源码已经是深拷贝效果
或已实现clone。
如果StringBuffer这种奇葩的没实现的，无法clone，又改不了源码，那就只好自己clone实现里用new String("xxx")
**/
		} catch (CloneNotSupportedException e) {
			return  null;
		}
		return change;
	}

使用：

//批量的操作时，ehrWfStaffChangeEntity是公用的会有问题。所以clone下
StaffChangeEntity changeEntity=(StaffChangeEntity)change.clone();

)

java 复制Map对象（深拷贝与浅拷贝）

subList是返回子列表之后，不改变原列表（和排序实现是改变原列表。list毕竟引用，它subList费尽心思并未真正隔离屏蔽深拷贝反显得半成品多此一举呢）