class User { 	String name; 	int age; } class Account implements Cloneable { 	User user; 	long balance; 	@Override 	public Object clone() throws CloneNotSupportedException { 		return super.clone(); 	} }

		// user. 		User user = new User(); 		user.name = "user"; 		user.age = 20; 		// account. 		Account account = new Account(); 		account.user = user; 		account.balance = 10000; 		// copy. 		Account copy = (Account) account.clone(); 		// balance因为是primitive，所以copy和原型是相等且独立的。 		Assert.assertEquals(copy.balance, account.balance); 		copy.balance = 20000; 		// 改变copy不影响原型。 		Assert.assertTrue(copy.balance != account.balance); 		// user因为是引用类型，所以copy和原型的引用是同一的。 		Assert.assertTrue(copy.user == account.user); 		copy.user.name = "newName"; 		// 改变的是同一个东西。 		Assert.assertEquals("newName", account.user.name);

class User implements Cloneable { 	String name; 	int age; 	@Override 	public Object clone() throws CloneNotSupportedException { 		return super.clone(); 	} }

		// user. 		User user = new User(); 		user.name = "user"; 		user.age = 20; 		// copy 		User copy = (User) user.clone(); 		// age因为是primitive，所以copy和原型是相等且独立的。 		Assert.assertEquals(copy.age, user.age); 		copy.age = 30; 		// 改变copy不影响原型。 		Assert.assertTrue(copy.age != user.age); 		// name因为是引用类型，所以copy和原型的引用是同一的。 		Assert.assertTrue(copy.name == user.name); 		// String为不可变类。没有办法可以通过对copy.name的字符串的操作改变这个字符串。 		// 改变引用新的对象不会影响原型。 		copy.name = "newname"; 		Assert.assertEquals("newname", copy.name); 		Assert.assertEquals("user", user.name);

class User implements Cloneable { 	String name; 	int age; 	@Override 	public User clone() throws CloneNotSupportedException { 		return (User) super.clone(); 	} } class Account implements Cloneable { 	User user; 	long balance; 	@Override 	public Account clone() throws CloneNotSupportedException { 		Account account = null; 		account = (Account) super.clone(); 		if (user != null) { 			account.user = user.clone(); 		} 		return account; 	} }

例子如下：

package com.instanceoftest;

 interface A{}
 class B implements A{
  
 }
 class C extends B {
  
 }
 
 class instanceoftest {
  public static void main(String[] args){
     A a=null;
     B b=null;
     boolean res; 
     
     System.out.println("instanceoftest test case 1: ------------------");
       res = a instanceof A; 
       System.out.println("a instanceof A: " + res);
       
       res = b instanceof B;
       System.out.println("b instanceof B: " + res);
       
     System.out.println("\ninstanceoftest test case 2: ------------------");   
     a=new B();
     b=new B();
     
     res = a instanceof A; 
     System.out.println("a instanceof A: " + res);
     
     res = a instanceof B;
     System.out.println("a instanceof B: " + res);

     res = b instanceof A;
     System.out.println("b instanceof A: " + res);
     
     res = b instanceof B;
     System.out.println("b instanceof B: " + res);
    
     System.out.println("\ninstanceoftest test case 3: ------------------");
     B b2=(C)new C();
     
     res = b2 instanceof A;
     System.out.println("b2 instanceof A: " + res);
     
     res = b2 instanceof B;
     System.out.println("b2 instanceof B: " + res);
     
     res = b2 instanceof C;
     System.out.println("b2 instanceof C: " + res);
  }
}

/*
result:

instanceoftest test case 1: ------------------
a instanceof A: false
b instanceof B: false

instanceoftest test case 2: ------------------
a instanceof A: true
a instanceof B: true
b instanceof A: true
b instanceof B: true

instanceoftest test case 3: ------------------
b2 instanceof A: true
b2 instanceof B: true
b2 instanceof C: true

　　代码重复几乎是最常见的异味了。他也是Refactoring的主要目标之一。代码重复往往来自于copy-and-paste的编程风格。与他相对应OAOO是一个好系统的重要标志。

　　2.Long method

　　它是传统结构化的“遗毒”。一个方法应当具有自我独立的意图，不要把几个意图放在一起。

　　3.Large Class

　　大类就是你把太多的责任交给了一个类。这里的规则是One Class One Responsibility.

　　4.Divergent Change

　　一个类里面的内容变化率不同。某些状态一个小时变一次，某些则几个月一年才变一次；某些状态因为这方面的原因发生变化，而另一些则因为其他方面的原因变一次。面向对象的抽象就是把相对不变的和相对变化相隔离。把问题变化的一方面和另一方面相隔离。这使得这些相对不变的可以重用。问题变化的每个方面都可以单独重用。这种相异变化的共存使得重用非常困难。

　　5.Shotgun Surgery

　　这正好和上面相反。对系统一个地方的改变涉及到其他许多地方的相关改变。这些变化率和变化内容相似的状态和行为通常应当放在同一个类中。

　　6.Feature Envy

　　对象的目的就是封装状态以及与这些状态紧密相关的行为。如果一个类的方法频繁用get 方法存取其他类的状态进行计算，那么你要考虑把行为移到涉及状态数目最多的那个类。

　　7.Data Clumps

　　某些数据通常像孩子一样成群玩耍：一起出现在很多类的成员变量中，一起出现在许多方法的参数中，这些数据或许应该自己独立形成对象。

　　8.Primitive Obsession

　　面向对象的新手通常习惯使用几个原始类型的数据来表示一个概念。譬如对于范围，他们会使用两个数字。对于Money，他们会用一个浮点数来表示。因为你没有使用对象来表达问题中存在的概念，这使得代码变的难以理解，解决问题的难度大大增加。好的习惯是扩充语言所能提供原始类型，用小对象来表示范围、金额、转化率、邮政编码等等。

　　9.Switch Statement

　　基于常量的开关语句是OO 的大敌，你应当把他变为子类、state或strategy.

　　10. Parallel Inheritance Hierarchies

　　并行的继承层次是shotgun surgery的特殊情况。因为当你改变一个层次中的某一个类时，你必须同时改变另外一个层次的并行子类。

　11. Lazy Class

　　一个干活不多的类。类的维护需要额外的开销，如果一个类承担了太少的责任，应当消除它。

　　12. Speculative Generality

　　一个类实现了从未用到的功能和通用性。通常这样的类或方法唯一的用户是testcase.不要犹豫，删除它。

　　13. Temporary Field

　　一个对象的属性可能只在某些情况下才有意义。这样的代码将难以理解。专门建立一个对象来持有这样的孤儿属性，把只和他相关的行为移到该类。最常见的是一个特定的算法需要某些只有该算法才有用的变量。

　　14. Message Chain

　　消息链发生于当一个客户向一个对象要求另一个对象，然后客户又向这另一对象要求另一个对象，再向这另一个对象要求另一个对象，如此如此。这时，你需要隐藏分派。

　　15. Middle Man

　　对象的基本特性之一就是封装，而你经常会通过分派去实现封装。但是这一步不能走得太远，如果你发现一个类接口的一大半方法都在做分派，你可能需要移去这个中间人。

　　16. Inappropriate Intimacy

　　某些类相互之间太亲密，它们花费了太多的时间去砖研别人的私有部分。对人类而言，我们也许不应该太假正经，但我们应当让自己的类严格遵守禁欲主义。

　　17. Alternative Classes with Different Interfaces

　　做相同事情的方法有不同的函数signature，一致把它们往类层次上移，直至协议一致。

　　18. Incomplete Library Class

　　要建立一个好的类库非常困难。我们大量的程序工作都基于类库实现。然而，如此广泛而又相异的目标对库构建者提出了苛刻的要求。库构建者也不是万能的。有时候我们会发现库类无法实现我们需要的功能。而直接对库类的修改有非常困难。这时候就需要用各种手段进行Refactoring.

　　19. Data Class

　　对象包括状态和行为。如果一个类只有状态没有行为，那么肯定有什么地方出问题了。

　　20. Refused Bequest

　　超类传下来很多行为和状态，而子类只是用了其中的很小一部分。这通常意味着你的类层次有问题。

　　21. Comments

　　经常觉得要写很多注释表示你的代码难以理解。如果这种感觉太多，表示你需要Refactoring.

举个例子，天鹅（Swan）是会飞的，而丑小鸭（UglyDuck）小时候是不会飞的，看看下面的代码，看看能够打印出什么。

class Swan {  
    public static void fly() {  
        System.out.println("swan can fly ...");  
    }  
}  
 
class UglyDuck extends Swan {     
    public static void fly() {  
        System.out.println("ugly duck can't fly ...");  
    }  
}  
 
public class TestFly {    
    public static void main(String [] args) {  
        Swan swan = new Swan();  
        Swan uglyDuck = new UglyDuck();  
        swan.fly();  
        uglyDuck.fly();  
    }  
} 
                       

按道理的话，我们认为应该是输出两句不同的结果，因为我们可能认为 UglyDuck 继承了 Swan 并且“重写”了 fly() 方法，而且在 main() 方法中 Swan uglyDuck = new UglyDuck();  也表明了 uglyduck 实际上是 UglyDuck 类型的，因此构成了多态行为。

其实，运行结果是两句“swan can fly ...”，为什么会这样子？原因有下：

1、父类 Swan 中的 static 静态方法 fly() 是不能被重写的，上一段我对重写二字用了双引号；

2、尽管子类 UglyDuck 中的 fly() 方法与父类中的有一致的参数列表，但是对于 static 方法来说，这叫隐藏（hide），而不是重写（override）；

3、对于 static 方法，根本不存在像多态那样的动态分派机制，JVM 不会根据对象引用的实际类型来调用对应的重写方法。这一点在个例子中是最重要的。

对于 static 方法，我们称之为类方法，不是实例方法，对 static 方法的调用直接用所属类名加个点就行，如 UglyDuck.fly() 。而实例方法就不得不使用对象引用来获得其可访问方法的调用权。在上面的例子 main() 中的 uglyDuck.fly() 语句，JVM 根本据不会去判断 uglyDuck 引用的究竟是什么类型，既然调用的是 fly() 方法，那么 JVM 只会根据 uglyDuck 的声明类型（即 Swan 类）去获得该 static 方法的调用。根本就谈不上多态…

这就说明，最好避免用对象引用的方式来访问一个 static 方法。此外，别以为在继承关系上的父类、子类只要方法名、参数列表一致就是重写（override）而构成多态，其实还得看看父类中的方法有没有被什么修饰符声明（在这个例子中是 static 修饰的）。再如 final 修饰符的方法则表明不可被子类重写，即方法名、参数列表不能和父类完全一致。在我看来，这一类修饰符就表明了方法、变量、字段等特有的性质，或者是身份。

对于隐藏（hide），实际上是为了使得父类中的该方法、字段、内部类等不允许再被下一级继承树的子子类所继承。说起隐藏，我想起《代码大全 2》当中刚好看过的内容，作者认为把握住信息隐藏的原则来思考软件构建要优于面向对象原则。有点抽象难懂，书中还讲到封装、模块化和抽象等几个概念，建议看看，我也要回过头去多啃啃这些抽象概念。

要修改上面代码，只需要去掉两个 static 则可，那就构成多态了。《Java 解惑》中其他谜题还讲到多种该注意的地方，可以看看。

小结：

1、注意掌握重写（override）与隐藏（hide）的异同点：相同点就是两者都是相对于继承树中父类、子类来说，而不同点就是其目的以及所造成的效果。别把重写和隐藏混淆在一起了；

2、对于 static 方法，要避免用具体的对象引用来调用，而应该简单的用其所属类名进行调用即可。

 遮蔽（shadow）：其实就是平时我们可能遇到的窄作用域的变量名、方法名、类名等将其他相同名字的变量、方法、类屏蔽掉的现象。

例如，最常见的就是局部变量将类实例变量屏蔽了。其实，遮蔽这个词我之前好像也没什么印象，不过作用域屏蔽这种情况我们大多应该会避免的了，因为课堂上、教材上对于变量作用域的内容已经讲解过了，尽管没有这么一个术语。此时如果想要获得被遮蔽实体的引用、调用，则只能通过完整的限定名去实现了。不过有一些情况可能是根本就引用不到的，被屏蔽得太严密了。

 遮掩（obscure）：一个变量可以遮掩具有相同名字的一个类，只要它们都在同一个范围内：如果这个名字被用于变量与类型都被许可的范围，那么它将引用到变量上。相似地，一个变量名或一个类名可以遮掩一个包。遮掩是唯一一种两个名字位于不同的名字空间的名字重用形式，这些名字空间包括：变量、包、方法或类。如果一个类型或一个包被遮掩了，那么你不能通过其简单名引用到它，除非是在这样一个上下文环境中，即语法只允许在其名字空间中出现一种名字。遵守命名习惯就可以极大地消除产生遮掩的可能性。

其实，遮掩这个术语我更是完全没听过了，上面这一段是从《Java 解惑》中引用过来的。我觉得，如果代码是一个人所写，或者团队中大家都遵守了一定的命名规范，而且也各自分配了一定职责，那么遮掩这种情况应该是可以避免的。同样，需要使用完全限定名来引用被遮掩掉的实体，如下：

用前面例子的代码大概就是这种情况：

public class TestFly {    
    // 如此变量名  
    static String System = "system";  
    public static void main(String [] args) {  
 
//      String System = "hao";    
        // 编译不通过  
//      System.out.println("No");  
        // 编译通过  
        java.lang.System.out.println("OK");  
    }  
}

小结：

1、我觉得，在文章标题当中的五个名词当中，尤为前面三个最为重要，陷阱炸弹也多多，而且文中所讲仅仅是那么一丁点儿相关的，大量更细节的还得慢慢发现；

2、就算后面两个名词，也就是这两种情况不常见，但了解一下记在脑里还是不错的，毕竟为自己增加了专业词汇量；

3、最后，就是建议各位也看看《Java 解惑》然后也告诉我一些炸弹型陷阱之类的，呵呵...学习快乐！加油！

本文出自 “蚂蚁” 博客，请务必保留此出处http://haolloyin.blog.51cto.com/1177454/372911

好在我记得自己电脑里下载过《Java 解惑（中文版）》的清晰电子版，于是改变路线，看起这本书来了。真是不看不知道，一看吓一跳！里面有 95 个 Java 谜题，一点点地看了之后，我是既惭愧又兴奋，因为里面的题真的是“莫名其妙”，直白点就是：十有八九是想都想不出来的，⊙﹏⊙b…想要真正掌握 Java ，我觉得《Java 解惑》是不得不看的。大多谜题可谓是前所未见的炸弹，一不小心就 over 了。

快点切入正题，如文章标题所示，我从《Java 解惑》中似乎认识到了几个名词，之所以用似乎修饰，因为重载、重写、隐藏这几个接触过了，而遮蔽、遮掩或许是见过但也就忘光了。就整理一下文中的一些与此相关的 Java 谜题用自己的理解描述一下吧。

重载（overload）：同一个类中名字相同但参数列表不同的多个方法之间的关系。

关于重载，是我们比较熟悉的了，最常见的就是运用在类的多个构造函数中，看一下 Java 帮助文档，就可以明白这一情况了。而在《Java 解惑》中，作者给出了下面一个谜题：

public class Confusing {   
      
    private Confusing(Object o) {   
        System.out.println("Object");   
    }   
      
    private Confusing(double[] dArray) {   
        System.out.println("double array");   
    }   
      
    public static void main(String[] args) {   
        new Confusing(null);   
    }   
}  
                       

问此时 main() 中将会输出什么？初初一看，并没有多分析就觉得应该是输出“Object”，虽然Java中的数组实际上也是引用类型，但毕竟Object 是所有类的最终父类，而且目前 JDK 就连参数中的基本数据类型变量也可以被自动想上转型成包装类而成为 Object 的子类。于是我保守一点地就认为参数 null 应该是匹配到 Object 那个重载方法去了。

可是这答案是错的，JVM 对于重载方法的解析是这样的：先找出方法名匹配的所有可能的方法；然后根据传进来的形参再次筛选出可能的重载方法；最后才是在这些方法中匹配到一个最精确的一个方法。于是，上面的那个谜题就变成确定哪一个才是最精确这一点子上了。

而关于如何判断最精确，有这样的机制：如果某个重载方法能够接收所有传递给另一个重载方法的实参类型，那么对于参数列表来看，显然后者至少是前者的子集，当然也就更精确了。

回到谜题上来，Confusing(Object)可以接受任何传递给 Confusing(double[ ])的参数（任何数组引用最终能够都是 Object 对象），因此 main() 中的 null 应该是被 JVM 匹配到 Confusing(double[ ]) 中，也就有了与我所认为的结果相反的输出了。

小结：这个谜题表明了我们在写重载方法时，最好是明确地区分出各个方法中的参数列表，不要让彼此之间有互相包含、模糊不清的关系。虽然重载是为了在相同名字的方法中传入实参，由 JVM 动态解析选择合适的方法，但有时也很容易陷入这种方便背后所带来的地雷区当中。其中一种可行的办法就是，提供不同的方法名。但是构造函数的名字一定得相同的啊？

实际上，在《重构与模式》第六章中，作者用他自身的项目经验对“创建”这一话题展开了讲解，就算是构造函数，也有很好的重构手法将其清晰地区分开来，不使用重载而是用不同名称的方法，将原本需要重载的构造函数委托给具有最大完整参数列表的私有构造函数中。又是一本经典，值得看哦…

重写（override）：父类中的实例方法被其子类重新实现。既然是实例方法，那就是非 static 修饰的了，否则就是 static 静态方法了，那叫做类方法。在我看来，正是重写这一机制的存在，才为多态机制提供了基础。或许 implements （实现）一个 interface （接口）中所声明的方法也能成为重写，因为 interface 的一部分存在原因也是为了多态。

对于重写，在《Java 解惑》中有下面这个谜题让我明白：绝对不能在构造函数中调用可能会被子类重写的方法。

class Point {  
    protected final int x, y;  
    private final String name;  
      
    Point(int x, int y) {  
        this.x = x;  
        this.y = y;  
        name = makeName();  
    }  
 
    protected String makeName() {  
        return "[" + x + "," + y + "]";  
    }  
      
    public final String toString() {  
        return name;  
    }  
}  
 
public class ColorPoint extends Point {  
    private final String color;  
      
    ColorPoint(int x, int y, String color) {  
        super(x, y);  
        this.color = color;  
    }  
      
    protected String makeName() {  
       return super.makeName() + ":" + color;  
    }  
      
    public static void main(String[] args) {  
        System.out.println(new ColorPoint(4, 2, "purple"));  
    }  
} 
                       

此时程序运行结果并不是我们所想的 [4,2]:purple ，而是 [4,2]:null 。为什么会这样？看看下面用流程标号注释过的代码，就能理解了。

class Point {  
    protected final int x, y;  
    private final String name;  
 
    Point(int x, int y) {  
        this.x = x;  
        this.y = y;  
        name = makeName();// 3. 由于被子类重写过的makeName()  
    }  
 
    protected String makeName() {  
        return "[" + x + "," + y + "]";  
    }  
      
    public final String toString() {  
        return name;  
    }  
}  
 
public class ColorPoint extends Point {  
    private final String color;  
 
    ColorPoint(int x, int y, String color) {  
        super(x, y); // 2. 调用Point父类构造函数  
        this.color = color; // 5. 初始化 color ，可是已经太晚了...  
    }  
 
    protected String makeName() {  
        // 4. 问题来了：它在子类构造函数之前调用了  
        // 而此时的 color 是 null 的啊！！！  
        return super.makeName() + ":" + color;  
    }  
 
    public static void main(String[] args) {  
        // 1. 调用ColorPoint子类构造函数  
        System.out.println(new ColorPoint(4, 2, "purple"));  
    }  
} 
                       

思路很清晰了，ColorPoint 子类中的构造函数中的 this.color = color; 还未被执行到就将 null 作为 String color 的值了。正是因为这种来来回回的调用使得程序变得不正常了，在我看来，有那么一点类似于“回调”的意思。

要去除这种代码结构的不合理，最好还是把 Point 父类构造函数中调用 makeName() 方法一句去掉，然后在 toString  中判断并调用 makeName() 来为 name 初始化，如下：

小结：重写对于多态固然重要，但是设计出不正确的代码结构的话，原本想要的多态就会被扭曲甚至造成反效果。于是，绝对不要在构造函数中调用可能会被子类重写的方法。

 好像文字太多的文章看了容易使人晕乎乎的，啰啰嗦嗦、模模糊糊地才写了两个词儿，还是分开来写吧。其实，看了一部分《Java 解惑》才明白还有好多好多 Java 里面该注意的要点。要想在适当的时候辨清各种语法上、机制上的知识点，难啊！

记得高中语文课上读过一片抒情的散文，标题为“哦——香雪！”而我看了《Java 解惑》，想说“噢——Java！”~~~~(>_<)~~~~

总结：

1、在我们编程领域，好书真的是一大把，就看自己有没时间、有没策略地去吸收了；

2、有时候看好书时留意作者对其他书籍的“友情链接”，或者出版社推荐的相关书籍，这样就能够免去自己慢慢搜寻好书的过程了，O(∩_∩)O哈！

本文出自 “蚂蚁” 博客，请务必保留此出处http://haolloyin.blog.51cto.com/1177454/372691

C、重写规则之三：
   返回类型必须与被重写方法的返回类型相同。
父类方法A：void eat(){} 子类方法B：int eat(){} 两者虽然参数相同，可是返回类型不同，所以不是重写。
父类方法A：int eat(){} 子类方法B：long eat(){} 返回类型虽然兼容父类，但是不同就是不同，所以不是重写。

D、重写规则之四：
   重写方法不能抛出新的异常或者比被重写方法声明的检查异常更广的检查异常。但是可以抛出更少，更有限或者不抛出异常。
import java.io.*;
public class Test {
  public static void main (String[] args) {
   Animal h = new Horse();
   try {
     h.eat(); 
   }
   catch (Exception e) {
   }
 }
}

class Animal {
  public void eat() throws Exception{
   System.out.println ("Animal is eating.");
   throw new Exception();
  }
}

class Horse extends Animal{
   public void eat() throws IOException{
    System.out.println ("Horse is eating.");
    throw new IOException();
  }
}

这个例子中，父类抛出了检查异常Exception，子类抛出的IOException是Exception的子类，也即是比被重写的方法抛出了更有限的异常，这是可以的。如果反过来，父类抛出IOException，子类抛出更为宽泛的Exception，那么不会通过编译的。
注意：这种限制只是针对检查异常，至于运行时异常RuntimeException及其子类不再这个限制之中。

E、重写规则之五：
   不能重写被标识为final的方法。

F、重写规则之六：
  如果一个方法不能被继承，则不能重写它。
比较典型的就是父类的private方法。下例会产生一个有趣的现象。
public class Test {
  public static void main (String[] args) {
   //Animal h = new Horse();
   Horse h = new Horse();
    h.eat();
   }
}

class Animal {
   private void eat(){
    System.out.println ("Animal is eating.");
    }
 }

class Horse extends Animal{
   public void eat(){
     System.out.println ("Horse is eating.");
   }
}
这段代码是能通过编译的。表面上看来违反了第六条规则，但实际上那是一点巧合。Animal类的eat()方法不能被继承，因此Horse类中的 eat()方法是一个全新的方法，不是重写也不是重载，只是一个只属于Horse类的全新的方法！这点让很多人迷惑了，但是也不是那么难以理解。
main()方法如果是这样：
Animal h = new Horse();
//Horse h = new Horse();
h.eat();
编译器会报错，为什么呢？Horse类的eat()方法是public的啊！应该可以调用啊！请牢记，多态只看父类引用的方法，而不看子类对象的方法！

public class NullInDepth {
   public static void helloThere(){
    System.out.println("Hello from null?!");
   }

   public static void main(String[] args) {
     //((NullInDepth)null).helloThere();
     NullInDepth nullIn = null;
     nullIn.helloThere();
     Object nullStr = null;
     NullInDepth nullOut = (NullInDepth) nullStr;
     System.out.println(nullIn);
   }

}

这里Hello from null?!会被打印出来，而后边一句会打印出null，
我们知道println一般是调用对象的toString来进行打印，但是null明显不是对象，
作为一个不确定引用它只是把自己的literal给打印了出来，因此我猜测null是预先存储在内存中的一个引用，
它是有值的，可能根据不同的jvm有不同的实现，但是jvm中会一致地将这个值打印为null。

另外按照我的猜测，null应该是栈里边的一个引用，null type是可以转换为所有其他type的引用，
所以我也猜测null type应该是所有其他引用类型的子类型。 
静态方法（也许需要是public的）应该是由类名来调用，但是也可以使用 类名(null).静态方法名的方式调用。

⑵深复制(深克隆)
   被复制对象的所有变量都含有与原来的对象相同的值，除去那些引用其他对象的变量。那些引用其他对象的变量将指向被复制过的新对象，而不再是原有的那些被引用的对象。换言之，深复制把要复制的对象所引用的对象都复制了一遍。

Java的clone()方法

⑴clone方法将对象复制了一份并返回给调用者。一般而言，clone()方法满足：

①对任何的对象x，都有x.clone() !=x//克隆对象与原对象不是同一个对象

②对任何的对象x，都有x.clone().getClass()= =x.getClass()//克隆对象与原对象的类型一样

③如果对象x的equals()方法定义恰当，那么x.clone().equals(x)应该成立。

⑵Java中对象的克隆

①为了获取对象的一份拷贝，我们可以利用Object类的clone()方法。

②在派生类中覆盖基类的clone()方法，并声明为public。

③在派生类的clone()方法中，调用super.clone()。

④在派生类中实现Cloneable接口。

    class Student implements Cloneable        {            String name;            int age;             Student(String name,int age)            {                this.name=name;                this.age=age;            }           public Object clone()           {              Object o=null;              try              {              o=(Student)super.clone();//Object中的clone()识别出你要复制的是哪一              // 个对象。               }               catch(CloneNotSupportedException e)              {                  System.out.println(e.toString());              }              return o;          }            public static void main(String[] args)          {            Student s1=new Student("zhangsan",18);            Student s2=(Student)s1.clone();            s2.name="lisi";            s2.age=20;          System.out.println("name="+s1.name+","+"age="+s1.age);//修改学生2后，不影响学生1的值。         }     }
运行结果：
C:\java>java   Student
name=zhangsan,age=18

说明：

①为什么我们在派生类中覆盖Object的clone()方法时，一定要调用super.clone()呢?在运行时刻，Object中的 clone()识别出你要复制的是哪一个对象，然后为此对象分配空间，并进行对象的复制，将原始对象的内容一一复制到新对象的存储空间中。

②继承自java.lang.Object类的clone()方法是浅复制。以下代码可以证明之。

    class Professor        {            String name;            int age;            Professor(String name,int age)            {                this.name=name;                this.age=age;            }       }        public class Student implements Cloneable     {         String name;//常量对象。         int age;         Professor p;//学生1和学生2的引用值都是一样的。         Student(String name,int age,Professor p)         {             this.name=name;             this.age=age;             this.p=p;         }        public Object clone()         {             Student o=null;            try             {                o=(Student)super.clone();             }             catch(CloneNotSupportedException e)            {                System.out.println(e.toString());            }             return o;         }           public static void main(String[] args)         {           Professor p=new Professor("wangwu",50);           Student s1=new Student("zhangsan",18,p);           Student s2=(Student)s1.clone();            s2.p.name="lisi";            s2.p.age=30;      System.out.println("name="+s1.p.name+","+"age="+s1.p.age);//学生1的教授成为lisi,age为30。      } }

那应该如何实现深层次的克隆，即修改s2的教授不会影响s1的教授，代码改进如下。

改进使学生1的Professor不改变(深层次的克隆)

    class Professor implements Cloneable        {            String name;            int age;         Professor(String name,int age)            {                this.name=name;                this.age=age;            }             public Object clone()           {               Object o=null;               try              {                   o=super.clone();              }              catch(CloneNotSupportedException e)              {                  System.out.println(e.toString());             }             return o;         }     }     public  class Student implements Cloneable       {           String name;           int age;           Professor p;           Student(String name,int age,Professor p)          {              this.name=name;              this.age=age;              this.p=p;          }       public Object clone()          {               Student o=null;               try               {                 o=(Student)super.clone();             }             catch(CloneNotSupportedException e)             {                 System.out.println(e.toString());             }            o.p=(Professor)p.clone();            return o;         }         public static void main(String[] args)        {          Professor p=new Professor("wangwu",50);          Student s1=new Student("zhangsan",18,p);          Student s2=(Student)s1.clone();           s2.p.name="lisi";           s2.p.age=30;      System.out.println("name="+s1.p.name+","+"age="+s1.p.age);//学生1的教授不改变。      } }   

3.利用串行化来做深复制

  把对象写到流里的过程是串行化(Serilization)过程，但是在Java程序师圈子里又非常形象地称为“冷冻”或者“腌咸菜 (picking)”过程;而把对象从流中读出来的并行化(Deserialization)过程则叫做“解冻”或者“回鲜(depicking)”过程。应当指出的是，写在流里的是对象的一个拷贝，而原对象仍然存在于JVM里面，因此“腌成咸菜”的只是对象的一个拷贝，Java咸菜还可以回鲜。

在Java语言里深复制一个对象，常常可以先使对象实现Serializable接口，然后把对象(实际上只是对象的一个拷贝)写到一个流里(腌成咸菜)，再从流里读出来(把咸菜回鲜)，便可以重建对象。

如下为深复制源代码。

public Object deepClone() 
{ 
  //将对象写到流里 
  ByteArrayOutputStream bo=new ByteArrayOutputStream(); 
  ObjectOutputStream oo=new ObjectOutputStream(bo); 
  oo.writeObject(this); 

  //从流里读出来 
  ByteArrayInputStream bi=new ByteArrayInputStream(bo.toByteArray()); 
  ObjectInputStream oi=new ObjectInputStream(bi); 
  return(oi.readObject()); 
}

这样做的前提是对象以及对象内部所有引用到的对象都是可串行化的，否则，就需要仔细考察那些不可串行化的对象可否设成transient，从而将之排除在复制过程之外。上例代码改进如下。

import java.io.*;         class Professor implements Serializable        {            String name;            int age;            Professor(String name,int age)            {                this.name=name;                this.age=age;            }        }        public  class Student implements Serializable       {           String name;//常量对象。           int age;           Professor p;//学生1和学生2的引用值都是一样的。            Student(String name,int age,Professor p)         {             this.name=name;             this.age=age;             this.p=p;        }      public Object deepClone() throws IOException, OptionalDataException,ClassNotFoundException       {       //将对象写到流里       ByteArrayOutputStream bo=new ByteArrayOutputStream();       ObjectOutputStream oo=new ObjectOutputStream(bo);       oo.writeObject(this);          //从流里读出来       ByteArrayInputStream bi=new ByteArrayInputStream(bo.toByteArray());       ObjectInputStream oi=new ObjectInputStream(bi);       return(oi.readObject());       }                  public static void main(String[] args) throws IOException,ClassNotFoundException       {            Professor p=new Professor("wangwu",50);            Student s1=new Student("zhangsan",18,p);            Student s2=(Student)s1.deepClone();            s2.p.name="lisi";            s2.p.age=30;           System.out.println("name="+s1.p.name+","+"age="+s1.p.age); //学生1的教授不改变。      }   }

Java基本功——Reference

有这样一种说法，如今争锋于IT战场的两大势力，MS一族偏重于底层实现，Java一族偏重于系统架构。说法根据无从考证，但从两大势力各自的社区力量和图书市场已有佳作不难看出，此说法不虚。于是，事情的另一面让人忽略了。
偏巧，我是一个喜欢探究底层实现的Java程序员，虽然我的喜好并非纯正咖啡，剑走偏锋却别是一番风味。

Reference
Java世界泰山北斗级大作《Thinking In Java》切入Java就提出“Everything is Object”。在Java这个充满Object的世界中，reference是一切谜题的根源，所有的故事都是从这里开始的。

Reference是什么？
如果你和我一样在进入Java世界之前曾经浪迹于C/C++世界，就一定不会对指针陌生。谈到指针，往日种种不堪回首的经历一下子涌上心头，这里不是抱怨的地方，让我们暂时忘记指针的痛苦，回忆一下最初接触指针的甜蜜吧！还记得你看过的教科书中，如何讲解指针吗？留在我印象中的一种说法是，指针就是地址，如同门牌号码一样，有了地址，你可以轻而易举找到一个人家，而不必费尽心力的大海捞针。
C++登上历史舞台，reference也随之而来，容我问个小问题，指针和reference区别何在？我的答案来自于在C++世界享誉盛名的《More Effective C++》。

1. 没有null reference。
2. reference必须有初值。
3. 使用reference要比使用指针效率高。因为reference不需要测试其有效性。
4. 指针可以重新赋值，而reference总是指向它最初获得的对象

设计选择：
当你指向你需要指向的某个东西，而且绝不会改指向其它东西，或是当你实作一个运算符而其语法需要无法有指针达成，你就应该选择reference。其它任何时候，请采用指针。

这和Java有什么关系？
初学Java，鉴于reference的名称，我毫不犹豫的将它和C++中的reference等同起来。不过，我错了。在Java中，reference可以随心所欲的赋值置空，对比一下上面列出的差异，就不难发现，Java的reference如果要与C/C++对应，它不过是一个穿着reference外衣的指针而已。
于是，所有关于C中关于指针的理解方式，可以照搬到Java中，简而言之，reference就是一个地址。我们可以把它想象成一个把手，抓住它，就抓住了我们想要操纵的数据。如同掌握C的关键在于掌握指针，探索Java的钥匙就是reference。

一段小程序
我知道，太多的文字总是令人犯困，那就来段代码吧！
public class ReferenceTricks {
  public static void main(String[] args) {
    ReferenceTricks r = new ReferenceTricks();
    // reset integer
    r.i = 0;
    System.out.println("Before changeInteger:" + r.i);
    changeInteger(r);
    System.out.println("After changeInteger:" + r.i);

    // just for format
    System.out.println();
  
    // reset integer
    r.i = 0;
    System.out.println("Before changeReference:" + r.i);
    changeReference(r);
    System.out.println("After changeReference:" + r.i);
  }

  private static void changeReference(ReferenceTricks r) {
   r = new ReferenceTricks();
   r.i = 5;
   System.out.println("In changeReference: " + r.i);
  }

  private static void changeInteger(ReferenceTricks r) {
   r.i = 5;
   System.out.println("In changeInteger:" + r.i);
  }

  public int i;
}

对不起，我知道，把一个字段设成public是一种不好的编码习惯，这里只是为了说明问题。
如果你有兴趣自己运行一下这个程序，我等你！

OK，你已经运行过了吗？结果如何？是否如你预期？下面是我在自己的机器上运行的结果：
Before changeInteger:0
In changeInteger:5
After changeInteger:5

Before changeReference:0
In changeReference: 5
After changeReference:0
这里，我们关注的是两个change——changeReference和changeInteger。从输出的内容中，我们可以看出，两个方法在调用前和调用中完全一样，差异出现在调用后的结果。

糊涂的讲解
先让我们来分析一下changeInteger的行为。
前面说过了，Java中的reference就是一个地址，它指向了一个内存空间，这个空间存放着一个对象的相关信息。这里我们暂时不去关心这个内存具体如何排布，只要知道，通过地址，我们可以找到r这个对象的i字段，然后我们给它赋成5。既然这个字段的内容得到了修改，从函数中返回之后，它自然就是改动后的结果了，所以调用之后，r对象的i字段依然是5。下图展示了changeInteger调用前后内存变化。

     Reference +--------+                Reference +--------+
    ---------->| i = 0  |               ---------->| i = 5  |
               |--------|                          |--------|
               | Memory |                          | Memory |
               |        |                          |        | 
               |        |                          |        |
               +--------+                          +--------+

    调用changeInteger之前               调用changeInteger之后

让我们把目光转向changeReference。
从代码上，我们可以看出，同changeInteger之间的差别仅仅在于多了这么一句。
r = new ReferenceTricks();
这条语句的作用是分配一块新的内存，然后将r指向它。
执行完这条语句，r就不再是原来的r，但它依然是一个ReferenceTricks的对象，所以我们依然可以对这个r的i字段赋值。到此为止，一切都是那么自然。

     Reference +--------+                          +--------+
    ---------->| i = 0  |                          | i = 0  |
               |--------|                          |--------|
               | Memory |                          | Memory |
               |        |                Reference |--------| 
               |        |               ---------->| i = 5  |
               +--------+                          +--------+

    调用changeReference之前              调用changeReference之后

顺着这个思路继续下去的话，执行完changeReference，输出的r的i字段，那么应该是应该是新内存中的i，所以应该是5。至于那块被我们抛弃的内存，Java的GC功能自然会替我们善后的。
事与愿违。
实际的结果我们已经看到了，输出的是0。
肯定哪个地方错了，究竟是哪个地方呢？

参数传递的秘密
知道方法参数如何传递吗？
记得刚开始学编程那会儿，老师教导，所谓参数，有形式参数和实际参数之分，参数列表中写的那些东西都叫形式参数，在实际调用的时候，它们会被实际参数所替代。
编译程序不可能知道每次调用的实际参数都是什么，于是写编译器的高手就出个办法，让实际参数按照一定顺序放到一个大家都可以找得到的地方，以此作为方法调用的一种约定。所谓“没有规矩，不成方圆”，有了这个规矩，大家协作起来就容易多了。这个公共数据区，现在编译器的选择通常是“栈”，而所谓的顺序就是形式参数声明的顺序。
显然，程序运行的过程中，作为实际参数的变量可能遍布于内存的各个位置，而并不一定要老老实实的呆在栈里。为了守“规矩”，程序只好将变量复制一份到栈中，也就是通常所说的将参数压入栈中。
打起精神，谜底就要揭晓了。
我刚才说什么来着？将变量复制一份到栈中，没错，“复制”！
这就是所谓的值传递。
C语言的旷世经典《The C Programming Language》开篇的第一章中，谈到实际参数时说，“在C中，所有函数的实际参数都是传‘值'的”。
马上会有人站出来，“错了，还有传地址，比如以指针传递就是传地址”。
不错，传指针就是传地址。在把指针视为地址的时候，是否考虑过这样一个问题，它也是一个变量。前面的讨论中说过了，参数传递必须要把参数压入栈中，作为地址的指针也不例外。所以，必须把这个指针也复制一份。函数中对于指针操作实际上是对于这个指针副本的操作。
Java的reference等于C的指针。所以，在Java的方法调用中，reference也要复制一份压入堆栈。在方法中对reference的操作就是对这个reference副本的操作。
谜底揭晓
好，让我们回到最初的问题上。
在changeReference中对于reference的赋值实际上是对这个reference的副本进行赋值，而对于reference的本尊没有产生丝毫的影响。
回到调用点，本尊醒来，它并不知道自己睡去的这段时间内发生过什么，所以只好当作什么都没发生过一般。就这样，副本消失了，在方法中对它的修改也就烟消云散了。
 
也许你会问出这样的问题，“听了你的解释，我反而对changeInteger感到迷惑了，既然是对于副本的操作，为什么changeInteger可以运作正常？”
呵呵，很有趣的大脑短路现象。
好，那我就用前面的说法解释一下changeInteger的运作。
所谓复制，其结果必然是副本完全等同于本尊。reference复制的结果必然是两个reference指向同一块内存空间。
虽然在方法中对于副本的操作并不会影响到本尊，但对内存空间的修改确实实实在在的。
回到调用点，虽然本尊依然不知道曾经发生过的一切，但它按照原来的方式访问内存的时候，取到的确是经过方法修改之后的内容。
于是方法可以把自己的影响扩展到方法之外。
 
多说几句
这个问题起源于我对C/C++中同样问题的思考。同C/C++相比，在changeReference中对reference赋值可能并不会造成什么很严重的后果，而在C/C++中，这么做却会造成臭名昭著的“内存泄漏”，根本的原因在于Java拥有了可爱的GC功能。即便这样，我仍不推荐使用这种的手法，毕竟GC已经很忙了，我们怎么好意思再麻烦人家。
在C/C++中，这个问题还可以继续引申。既然在函数中对于指针直接赋值行不通，那么如何在函数中修改指针呢？答案很简单，指针的指针，也就是把原来的指针看作一个普通的数据，把一个指向它的指针传到函数中就可以了。
同样的问题到了Java中就没有那么美妙的解决方案了，因为Java中可没有reference的reference这样的语法。可能的变通就是将reference进行封装成类。至于值不值，公道自在人心。