1.静态方法什么时候初始化，在main前还是main后
 在main方法后，静态方法是属于类的，只有在调用时才初始化（main例外，main的调用是在初始化工作完成后程序进入运行状态时），但静态方法在内存中只有一份；

2.构造函数与继承的关系
子类的构造函数内会包含一个父类构造函数，因为在子类构造函数第一行会默认调用父类构造函数，如果覆写该行则可以自行控制父类构造函数版本；可见得父类构造函数和子类构造函数得关系是“继承”不是“覆写”，（每个）子类构造函数继承（包含）父类构造函数的一个版本，并可以有自己的部分，类似继承，子类不完全继承父类方法并可由自己的方法，父类私有不能继承。

3.接口没有构造函数的原因
1.接口里的方法完全抽象构造函数没有实现体，无意义
2.接口为了实现多继承，子类构造函数必须调用父类构造函数，如果接口有构造函数子类不知道调用哪个父类构造函数

String类用来表示那些创建后就不会再改变的字符串，它是immutable的。
而StringBuffer类用来表示内容可变的字符串，并提供了修改底层字符串的方法。

－－当我们进行字符拼接时，请使用StringBuffer类而非String类，因为前者将比后者快上百倍。

的确，在程序的太多场合我们都会进行字符串拼接工作，简单的代码示例如下：

String str="You are nice.";
str+="I love you so much.";

如果用StringBuffer类的话，代码如下：

StringBuffer str= new StringBuffer("You are nice.");
str.append("I love you so much.");

        从表面看来String类只用一个加号（+）便完成了字符串的拼接，
而StringBuffer类却要调用一个append()方法，是否实现起来更简洁，更单纯呢？其实不然，
让我们了解一下程序运行内部发生了哪些事情：

        经编译后程序的bytecode（字节码）展示出了实质：  在用String类对象直接拼接时，
JVM会创建一个临时的StringBuffer类对象，并调用其append()方法完成字符串的拼接，
这是因为String类是不可变的，拼接操作不得不使用StringBuffer类（并且－－JVM会将"You are nice."和"I love you so much."
创建为两个新的String对象）。
之后，再将这个临时StringBuffer对象转型为一个String，代价不菲！可见，在这一个简单的一次拼接过程中，
我们让程序创建了四个对象：两个待拼接的String，一个临时StringBuffer，
和最后将StringBuffer转型成为的String－－它当然不是最初的str了，这个引用的名称没变，但它指向了新的String对象。

        而如果直接使用StringBuffer类，程序将只产生两个对象：
最初的StringBuffer和拼接时的String（"I love you so much."），
也不再需要创建临时的StringBuffer类对象而后还得将其转换回String对象。

        可以想象，当我们的字符串要被循环拼接若干段时，
用String类直接操作会带来多少额外的系统开销，生成多少无用的临时StringBuffer对象，
并处理多少次无谓的强制类型转换哪。

5. equals() 和 == 
   equals() 比对象值，即属性是否相等 
   ==比引用，地址
   在编译时期确定的两个字符串对象引用相等（＝＝）
   不在编译期确定的两个字符串字符串引用不相等

/**
 *默认得克隆方法为浅克隆只克隆对象得非引用类型(或者非对象型）成员
 *要做深克隆有两种方法：
 *a.覆写克隆方法（引用型成员的克隆方法）并且克隆时掉一次引用型成员的克隆方法！
 *b.序列化对象时默认为深克隆
 *
 */
 
 class Friend implements Cloneable {
   int age;
   String name;
  
  public Friend(int age, String name) {
   this.age = age;
   this.name = name; 
  }
  
  public Object clone () throws CloneNotSupportedException {
   return super.clone(); 
  }
   
 }
 
 class Person implements Cloneable  {
   int age;
  /* *
   *String 类型特殊，因为他为引用型，而且他指向的值为常量，克隆出来的对象改变他的
   *值实际上是改变了克隆出来对象String类型成员的指向不会影响被克隆对象的值及其指向?
   *因为引用被克隆了，我改变的是引用的指向！
  */
   String name;
  
   Friend f;
  
  public Person(int age, String name, Friend f) {
   this.age = age;
   this.name = name;
   this.f = f;
  }
  
  public Object clone () throws CloneNotSupportedException {
   Person p = (Person)super.clone();
   p.f = (Friend)p.f.clone();
   return p; 
  }
  
  public String toString(){
  StringBuffer sb = new StringBuffer();
  return super.toString()+sb.append("age=").append(age).
   append(",name=").append(name).
   append("friend=").append("f.name=").
   append(f.name).append("f.age=").append(f.age).toString();
 }
 }
 
 
 public class Clonetest {
  public static void main(String [] args)  throws CloneNotSupportedException {
   Person p = new Person(4,"haha",new Friend(5,"hehe"));
   Person p1 = (Person)p.clone();
   p1.name = "oop";
   p1.age = 10;
   p1.f.name = "ooad";
   p1.f.age = 56;
   System.out.println (p);
  System.out.println (p1);
  } 
 }

                            关于 Spring 的模版机制

看了 Spring In Action 感觉，对于依赖注入的应用始终贯穿着一个思想“模版机制”，从 jdbc 到 rmi,jms,ejb 与 Spring 的结合使用，都以模版来为我们避免每次繁琐的初始化和异常处理工作。。。。，使我们的写程序的精力集中专著到业务。。。。感觉模版就象我们现实生活中的工具我们只需要专注加工后的结果和需要的原料，经过工具出来的就是成品。。。我们不需要关注工具怎么为我们加工物品，需要几道工序。。。

1 、调用 EJB 时拿到 Home 接口直接转型为远程对象

会报转型异常。。。应该转换为远程接口

2 、 实体 Bean 在数据库端没有创建主键  

       会导致生成的实体 Bean 的 ejbcreate 方法返回值为 Object

3 、 给 Bean 添加方法的时候忘记选择方法的类型

会导致方法无法调用（即导致远程接口没有此方法签名），方法类型要和 bean 类型相同，远程或本地方法的时候

4 、 更改实体 Bean 的 Create 方法方法签名时只修改了一个方法

       应该同时更改 ejbCreate 和 ejbPsotCreate, 还有远程接口的 ejbCreate 方法

5 、 实体Bean设定了标识列而数据库字段没有设定标识列

       会导致调用实体 Bean 的 Ejbcreate 方法报错