在网上看了很多有关序列化的文 章，我自己也写了两篇，现在感觉这些文章都没有很好的把序列化说清楚(包括我自己在内)，所以在此我将总结前人以及自己的经验，用更浅显易懂的语言来描述 该机制，当然，仍然会有不好的地方，希望你看后可以指出，作为一名程序员应该具有不断探索的精神和强烈的求知欲望！

序列化概述：

      简单来说序列化就是一种用来处理对象流的机制，所谓对象流也就是将对象的内容进行流化，流的概念这里不用多说(就是I/O)，我们可以对流化后的对象进行 读写操作，也可将流化后的对象传输于网络之间(注：要想将对象传输于网络必须进行流化)！在对对象流进行读写操作时会引发一些问题，而序列化机制正是用来 解决这些问题的！

问题的引出：

      如上所述，读写对象会有什么问题呢？比如：我要将对象写入一个磁盘文件而后再将其读出来会有什么问题吗？别急，其中一个最大的问题就是对象引用！举个例子 来说：假如我有两个类，分别是A和B，B类中含有一个指向A类对象的引用，现在我们对两个类进行实例化{ A a = new A(); B b = new B(); }，这时在内存中实际上分配了两个空间，一个存储对象a，一个存储对象b，接下来我们想将它们写入到磁盘的一个文件中去，就在写入文件时出现了问题！因为 对象b包含对对象a的引用，所以系统会自动的将a的数据复制一份到b中，这样的话当我们从文件中恢复对象时(也就是重新加载到内存中)时，内存分配了三个 空间，而对象a同时在内存中存在两份，想一想后果吧，如果我想修改对象a的数据的话，那不是还要搜索它的每一份拷贝来达到对象数据的一致性，这不是我们所 希望的！

以下序列化机制的解决方案：

1.保存到磁盘的所有对象都获得一个序列号(1, 2, 3等等)

2.当要保存一个对象时，先检查该对象是否被保存了。

3.如果以前保存过，只需写入"与已经保存的具有序列号x的对象相同"的标记，否则，保存该对象

通过以上的步骤序列化机制解决了对象引用的问题！

序列化的实现：

      将需要被序列化的类实现Serializable接口，该接口没有需要实现的方法，implements Serializable只是为了标注该对象是可被序列化的，然后使用一个输出流(如：FileOutputStream)来构造一个 ObjectOutputStream(对象流)对象，接着，使用ObjectOutputStream对象的writeObject(Object obj)方法就可以将参数为obj的对象写出(即保存其状态)，要恢复的话则用输入流。

例子：

import java.io.*;

public class Test
{
    public static void main(String[] args)
    {
        Employee harry = new Employee("Harry Hacker", 50000);
        Manager manager1 = new Manager("Tony Tester", 80000);
        manager1.setSecretary(harry);
       
        Employee[] staff = new Employee[2];
       
        staff[0] = harry;
        staff[1] = manager1;
        try
        {
            ObjectOutputStream out = new ObjectOutputStream(
                new FileOutputStream("employee.dat"));
            out.writeObject(staff);
            out.close();
           
            ObjectInputStream in = new ObjectInputStream(
                new FileInputStream("employee.dat"));
            Employee[] newStaff = (Employee[])in.readObject();
            in.close();
  
            /**
             *通过harry对象来加薪
             *将在secretary上反映出来
             */
            newStaff[0].raiseSalary(10);
           
            for (int i = 0; i < newStaff.length; i++)
                System.out.println(newStaff[i]);
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }
   
}

class Employee implements Serializable
{
    public Employee(String n, double s)
    {
        name = n;
        salary = s;
    }
   
    /**
     *加薪水
     */
    public void raiseSalary(double byPercent)
    {
        double raise = salary * byPercent / 100;
        salary += raise;
    }
   
    public String toString()
    {
        return getClass().getName()
            + "[name = "+ name
            + ",salary = "+ salary
            + "]";
    }
   
    private String name;
    private double salary;
}

class Manager extends Employee
{
    public Manager(String n, double s)
    {
        super(n, s);
        secretary = null;
    }
   
    /**
     *设置秘书
     */
    public void setSecretary(Employee s)
    {
        secretary = s;
    }
   
    public String toString()
    {
        return super.toString()
            + "[secretary = "+ secretary
            + "]";
    }
   
    //secretary代表秘书
    private Employee secretary; 
}

修改默认的序列化机制：   

      在 序列化的过程中，有些数据字段我们不想将其序列化，对于此类字段我们只需要在定义时给它加上transient关键字即可，对于transient字段序 列化机制会跳过不会将其写入文件，当然也不可被恢复。但有时我们想将某一字段序列化，但它在SDK中的定义却是不可序列化的类型，这样的话我们也必须把他 标注为transient，可是不能写入又怎么恢复呢？好在序列化机制为包含这种特殊问题的类提供了如下的方法定义：

private void readObject(ObjectInputStream in) throws

         IOException, ClassNotFoundException;

private void writeObject(ObjectOutputStream out) throws

         IOException;

(注：这些方法定义时必须是私有的，因为不需要你显示调用，序列化机制会自动调用的)

使用以上方法我们可以手动对那些你又想序列化又不可以被序列化的数据字段进行写出和读入操作。

      下面是一个典型的例子，java.awt.geom包中的Point2D.Double类就是不可序列化的，因为该类没有实现Serializable接口，在我的例子中将把它当作LabeledPoint类中的一个数据字段，并演示如何将其序列化！

import java.io.*;
import java.awt.geom.*;

public class TransientTest
{
    public static void main(String[] args)
    {
        LabeledPoint label = new LabeledPoint("Book", 5.00, 5.00);
        try
        {
            System.out.println(label);//写入前
            ObjectOutputStream out = new ObjectOutputStream(new
                FileOutputStream("Label.txt"));
            out.writeObject(label);
            out.close();
           
            System.out.println(label);//写入后
           
            ObjectInputStream in = new ObjectInputStream(new
                FileInputStream("Label.txt"));
            LabeledPoint label1 = (LabeledPoint)in.readObject();
            in.close();
            System.out.println(label1);//读出并加1.0后
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }
   
}

class LabeledPoint implements Serializable
{
    public LabeledPoint(String str, double x, double y)
    {
        label = str;
        point = new Point2D.Double(x, y);
    }
   
    private void writeObject(ObjectOutputStream out) throws IOException
    {
        /**
         *必须通过调用defaultWriteObject()方法来写入
         *对象的描述以及那些可以被序列化的字段
         */
        out.defaultWriteObject();
        out.writeDouble(point.getX());
        out.writeDouble(point.getY());
    }
   
    private void readObject(ObjectInputStream in)
        throws IOException, ClassNotFoundException
    {
        /**
         *必须调用defaultReadObject()方法
         */
        in.defaultReadObject();
        double x = in.readDouble() + 1.0;
        double y = in.readDouble() + 1.0;
        point = new Point2D.Double(x, y);
    }
   
    public String toString()
    {
        return getClass().getName()
            + "[label = "+ label
            + ", point.getX() = "+ point.getX()
            + ", point.getY() = "+ point.getY()
            + "]";
    }
   
    private  String label;
    transient private Point2D.Double point;
}
 

Comparator cmp = Collator.getInstance(java.util.Locale.CHINA); 

TreeMap tree=new TreeMap(cmp);    

  String[] arr = {"张三", "李四", "王五"};       

// 使根据指定比较器产生的顺序对指定对象数组进行排序。      

   Arrays.sort(arr, cmp);      

  for (int i = 0; i < arr.length; i++)         

    System.out.println(arr[i]);

<script>
 names = ["张三", "李四", "王五", "刘六"];
 names.sort(function(a,b){return a.localeCompare(b)});//a,b 为数组a的某两个值，自动传入
 alert(names);
</script>

另:

示例文本：

String [] test = new String[] {
                "作业",
                "测试",
                "test",
                "我们",
                "。空",
                "镂空",
                "[",
                "浏",
                "皙"
        };

jdk 版本：

 1.5.6

开发平台：

 Eclipse 3.1

关键字： 中文排序

概述

我们在应用程序中可能会经常遇到对中文排序的问题，例如姓名列表，词汇表等等。对中文排序，我们使用比较多的是根据汉语拼音发音来确定顺序。

我们可能会经常使用 

 接口，

 等类或方法对含有中文字符的对象进行排序，但是这些在默认情况下都是调用 

方法，这个方法是比较2个字符的 codepoint value，如果第一个字符的值小于第二个，则在排序结果中第一个会在前面，反之亦然。

1. java.text.Collator

接口及其实现类

其实 java 中提供了和语言相关的类，即 Collator 接口及其实现类。

 是一个具体类，它实现了 Comparator 接口中的 compare(Object, Object) 方法。 RuleBasedCollator 根据根据特定语言的默认规则比较字符，也可以按照指定的规则来比较，请参阅 java API 获取此类的详细信 息。
如果我们需要对一个有中文的数组进行排序，则可以使用这个类。请看如下示例代码：

以上代码的输出结果为：

============
[
test
。空
测试
我们
作业
浏
镂空
皙


大家可能会发现只有一部分汉字是按照汉语拼音排序了，还有几个没有。

问题分析：

GB2312:
在简体中文中我们使用比较多的字符集是 GB2312-80，简称为 GB2312，这个字符集包含了目前最常用的汉字共计 6736 个。其中的汉字分为两大类：

常用汉字

次常用汉字

常用汉字按照汉语拼音来排序，而次常用汉字按照笔画部首进行排序。

简体汉字在 Unicode 中一般是按照 gb2312 的码点值的顺序来放置的，所以如果是常用汉字 java 就能够很准确的进行排序，但如果是次常用汉字，则就会出现问题。在以上示例中，"镂"，"皙" 属于次常用字。

解决方案：

RuleBasedCollator 类 getRules() 方法可以返回对应语言的规则设置。简体中文对应的规则是 gb2312 所对应的字符。

我们可以把其中的全部汉字提取出来

对这些汉字重新排序

利用RuleBasedCollator(String rules) 构造器新建一个定制的 RuleBasedCollator

参考代码

在以下的代码中，我把排过序的汉字直接作为 String 对象放在类里面了，如果要让代码变得简洁一些，则可以把完整的规则（特殊字符＋排序汉字）存为文件。

javac

有两种方法可将源代码文件名传递给 javac：

• 如果源文件数量少，在命令行上列出文件名即可。
• 如果源文件数量多，则将源文件名列在一个文件中，名称间用空格或回车行来进行分隔。然后在 javac 命令行中使用该列表文件名，文件名前冠以 @ 字符。

源代码文件名称必须含有 .java 后缀，类文件名称必须含有 .class 后缀，源文件和类文件都必须有识别该类的根名。例如，名为 MyClass 的类将写在名为 MyClass.java的源文件中，并被编译为字节码类文件 MyClass.class。

内部类定义产生附加的类文件。这些类文件的名称将内部类和外部类的名称结合在一起，例如MyClass$MyInnerClass.class。

应当将源文件安排在反映其包树结构的目录树中。例如，如果将所有的源文件放在 /workspace 中，那么 com.mysoft.mypack.MyClass 的代码应该在 \workspace\com\mysoft\mypack\MyClass.java 中。

缺省情况下，编译器将每个类文件与其源文件放在同一目录中。可用 -d 选项（请参阅后面的选项）指定其它目标目录。

工具读取用 Java 编程语言编写的类和接口定义，并将它们编译成字节码类文件。

下面的讨论以Windows平台的Sun MicroSystem实现的java5虚拟机为蓝本，其他操作系统或其他公司实现的虚拟机参数会有部分不同，但大部分含义都和Windows上的类似。Java5与以前版本相比，虚拟机参数大部分保持了向前兼容，同时也增加了一些新的参数，本文将对这些参数的作用作详细描述，使虚拟机能更符合运行环境的需要，获得更好的性能和稳定性。

Java在运行已编译完成的类时，是通过java虚拟机来装载和执行的，java虚拟机通过操作系统命令JAVA_HOME\bin\java –option 来启动，-option为虚拟机参数，JAVA_HOME为JDK安装路径，通过这些参数可对虚拟机的运行状态进行调整，掌握参数的含义可对虚拟机的运行模式有更深入理解。


虚拟机参数分为基本和扩展两类，在命令行中输入JAVA_HOME\bin\java 就可得到基本参数列表，

在命令行输入JAVA_HOME\bin\java –X 就可得到扩展参数列表。

基本参数说明：


-client，-server

这两个参数用于设置虚拟机使用何种运行模式，client模式启动比较快，但运行时性能和内存管理效率不如server模式，通常用于客户端应用程序。相反，server模式启动比client慢，但可获得更高的运行性能。

在windows上，缺省的虚拟机类型为client模式，如果要使用server模式，就需要在启动虚拟机时加-server参数，以获得更高性能，对服务器端应用，推荐采用server模式，尤其是多个CPU的系统。在Linux，Solaris上缺省采用server模式。


-hotspot

含义与client相同，jdk1.4以前使用的参数，jdk1.4开始不再使用，代之以client。


-classpath,-cp

虚拟机在运行一个类时，需要将其装入内存，虚拟机搜索类的方式和顺序如下：

Bootstrap classes，Extension classes，User classes。

Bootstrap 中的路径是虚拟机自带的jar或zip文件，虚拟机首先搜索这些包文件，用System.getProperty("sun.boot.class.path")可得到虚拟机搜索的包名。


Extension是位于jre\lib\ext目录下的jar文件，虚拟机在搜索完Bootstrap后就搜索该目录下的jar文件。用System. getProperty("java.ext.dirs”)可得到虚拟机使用Extension搜索路径。

User classes搜索顺序为当前目录、环境变量 CLASSPATH、-classpath。

-classpath告知虚拟机搜索目录名、jar文档名、zip文档名，之间用分号;分隔。

例如当你自己开发了公共类并包装成一个common.jar包，在使用common.jar中的类时，就需要用-classpath common.jar 告诉虚拟机从common.jar中查找该类，否则虚拟机就会抛出java.lang.NoClassDefFoundError异常，表明未找到类定义。

在运行时可用System.getProperty(“java.class.path”)得到虚拟机查找类的路径。


使用-classpath后虚拟机将不再使用CLASSPATH中的类搜索路径，如果-classpath和CLASSPATH都没有设置，则虚拟机使用当前路径(.)作为类搜索路径。


推荐使用-classpath来定义虚拟机要搜索的类路径，而不要使用环境变量CLASSPATH的搜索路径，以减少多个项目同时使用CLASSPATH时存在的潜在冲突。例如应用1要使用a1.0.jar中的类G，应用2要使用a2.0.jar中的类G,a2.0.jar是a1.0.jar的升级包，当a1.0.jar，a2.0.jar都在CLASSPATH中，虚拟机搜索到第一个包中的类G时就停止搜索，如果应用1应用2的虚拟机都从CLASSPATH中搜索，就会有一个应用得不到正确版本的类G。



-D<propertyName>=value

在虚拟机的系统属性中设置属性名/值对，运行在此虚拟机之上的应用程序可用System.getProperty(“propertyName”)得到value的值。

如果value中有空格，则需要用双引号将该值括起来，如-Dname=”space string”。

该参数通常用于设置系统级全局变量值，如配置文件路径，应为该属性在程序中任何地方都可访问。


-verbose[:class|gc|jni]

在输出设备上显示虚拟机运行信息。

verbose和verbose:class含义相同，输出虚拟机装入的类的信息，显示的信息格式如下：

[Loaded java.io.FilePermission$1 from shared objects file]

当虚拟机报告类找不到或类冲突时可用此参数来诊断来查看虚拟机从装入类的情况。


-verbose:gc在虚拟机发生内存回收时在输出设备显示信息，格式如下：

[Full GC 268K->168K(1984K), 0.0187390 secs]

该参数用来监视虚拟机内存回收的情况。


-verbose:jni在虚拟机调用native方法时输出设备显示信息，格式如下：

[Dynamic-linking native method HelloNative.sum ... JNI]

该参数用来监视虚拟机调用本地方法的情况，在发生jni错误时可为诊断提供便利。



-version

显示可运行的虚拟机版本信息然后退出。一台机器上装有不同版本的JDK时



-showversion

显示版本信息以及帮助信息。



-ea[:<packagename>...|:<classname>]

-enableassertions[:<packagename>...|:<classname>]

从JDK1.4开始，java可支持断言机制，用于诊断运行时问题。通常在测试阶段使断言有效，在正式运行时不需要运行断言。断言后的表达式的值是一个逻辑值，为true时断言不运行，为false时断言运行，抛出java.lang.AssertionError错误。

上述参数就用来设置虚拟机是否启动断言机制，缺省时虚拟机关闭断言机制，用-ea可打开断言机制，不加<packagename>和classname时运行所有包和类中的断言，如果希望只运行某些包或类中的断言，可将包名或类名加到-ea之后。例如要启动包com.foo.util中的断言，可用命令 –ea:com.foo.util 。


-da[:<packagename>...|:<classname>]

-disableassertions[:<packagename>...|:<classname>]

用来设置虚拟机关闭断言处理，packagename和classname的使用方法和-ea相同。



-esa | -enablesystemassertions

设置虚拟机显示系统类的断言。


-dsa | -disablesystemassertions

设置虚拟机关闭系统类的断言。


-agentlib:<libname>[=<options>]

该参数是JDK5新引入的，用于虚拟机装载本地代理库。

Libname为本地代理库文件名，虚拟机的搜索路径为环境变量PATH中的路径，options为传给本地库启动时的参数，多个参数之间用逗号分隔。在Windows平台上虚拟机搜索本地库名为libname.dll的文件，在Unix上虚拟机搜索本地库名为libname.so的文件，搜索路径环境变量在不同系统上有所不同，Linux、SunOS、IRIX上为LD_LIBRARY_PATH，AIX上为LIBPATH，HP-UX上为SHLIB_PATH。


例如可使用-agentlib:hprof来获取虚拟机的运行情况，包括CPU、内存、线程等的运行数据，并可输出到指定文件中，可用-agentlib:hprof=help来得到使用帮助列表。在jre\bin目录下可发现hprof.dll文件。


-agentpath:<pathname>[=<options>]

设置虚拟机按全路径装载本地库，不再搜索PATH中的路径。其他功能和agentlib相同。



-javaagent:<jarpath>[=<options>]

虚拟机启动时装入java语言设备代理。Jarpath文件中的mainfest文件必须有Agent-Class属性。代理类要实现public static void premain(String agentArgs, Instrumentation inst)方法。当虚拟机初始化时，将按代理类的说明顺序调用premain方法。

参见：java.lang.instrument



扩展参数说明


-Xmixed

设置-client模式虚拟机对使用频率高的方式进行Just-In-Time编译和执行，对其他方法使用解释方式执行。该方式是虚拟机缺省模式。



-Xint

设置-client模式下运行的虚拟机以解释方式执行类的字节码，不将字节码编译为本机码。


-Xbootclasspath:path

-Xbootclasspath/a:path

-Xbootclasspath/p:path

改变虚拟机装载缺省系统运行包rt.jar而从-Xbootclasspath中设定的搜索路径中装载系统运行类。除非你自己能写一个运行时，否则不会用到该参数。

/a:将在缺省搜索路径后加上path 中的搜索路径。

/p:在缺省搜索路径前先搜索path中的搜索路径。


-Xnoclassgc

关闭虚拟机对class的垃圾回收功能。


-Xincgc

启动增量垃圾收集器，缺省是关闭的。增量垃圾收集器能减少偶然发生的长时间的垃圾回收造成的暂停时间。但增量垃圾收集器和应用程序并发执行，因此会占用部分CPU在应用程序上的功能。


-Xloggc:<file>

将虚拟机每次垃圾回收的信息写到日志文件中，文件名由file指定，文件格式是平文件，内容和-verbose:gc输出内容相同。




-Xbatch

虚拟机的缺省运行方式是在后台编译类代码，然后在前台执行代码，使用-Xbatch参数将关闭虚拟机后台编译，在前台编译完成后再执行。



-Xms<size>

设置虚拟机可用内存堆的初始大小，缺省单位为字节，该大小为1024的整数倍并且要大于1MB，可用k(K)或m(M)为单位来设置较大的内存数。初始堆大小为2MB。

例如：-Xms6400K，-Xms256M



-Xmx<size>

设置虚拟机内存堆的最大可用大小，缺省单位为字节。该值必须为1024整数倍，并且要大于2MB。可用k(K)或m(M)为单位来设置较大的内存数。缺省堆最大值为64MB。

例如：-Xmx81920K，-Xmx80M

当应用程序申请了大内存运行时虚拟机抛出java.lang.OutOfMemoryError: Java heap space错误，就需要使用-Xmx设置较大的可用内存堆。


-Xss<size>

设置线程栈的大小，缺省单位为字节。与-Xmx类似，也可用K或M来设置较大的值。通常操作系统分配给线程栈的缺省大小为1MB。

另外也可在java中创建线程对象时设置栈的大小，构造函数原型为Thread(ThreadGroup group, Runnable target, String name, long stackSize)。



-Xprof

输出CPU运行时的诊断信息。



-Xfuture

对类文件进行严格格式检查，以保证类代码符合类代码规范。为保持向后兼容，虚拟机缺省不进行严格的格式检查。


-Xrs

减少虚拟机中操作系统的信号（singals）的使用。该参数通常用在虚拟机以后台服务方式运行时使用（如Servlet）。



-Xcheck:jni

调用JNI函数时进行附加的检查，特别地虚拟机将校验传递给JNI函数参数的合法性，在本地代码中遇到非法数据时，虚拟机将报一个致命错误而终止。使用该参数后将造成性能下降。

web.xml里面可以定义两种参数：
(1)application范围内的参数，存放在servletcontext中，在web.xml中配置如下：  <context-param>
           <param-name>context/param</param-name>
           <param-value>avalible during application</param-value>

           <param-name>name1</param-name>
           <param-value>value1</param-value>
  </context-param>

(2)servlet范围内的参数，只能在servlet的init()方法中取得，在web.xml中配置如下：

 <servlet>
    <servlet-name>MainServlet</servlet-name>
    <servlet-class>com.wes.controller.MainServlet</servlet-class>
    <init-param>
       <param-name>param1</param-name>
       <param-value>avalible in servlet init()</param-value>
    </init-param>
    <load-on-startup>0</load-on-startup>
 </servlet>

在servlet中可以通过代码分别取用：

package com.wes.controller;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;

public class MainServlet extends HttpServlet ...{

    public MainServlet() ...{
        super();
     }
    public void init() throws ServletException ...{
         System.out.println("下面的两个参数param1是在servlet中存放的");
         System.out.println(this.getInitParameter("param1"));
         System.out.println("下面的参数是存放在servletcontext中的");
         System.out.println(getServletContext().getInitParameter("context/param"));
      }
}

第 一种参数在servlet里面可以通过getServletContext().getInitParameter("context/param")得 到?(在servlet的init()方法中通过this.getInitParameter("param1")取得)

第二种参数只能在servlet的init()方法中通过this.getInitParameter("param1")取得

---------------------------------------------------------------------

ServletContextListener实现读取web.xml中context-param信息      2009年03月27日 星期五 22:37
  用部署文件来存储配置参数在Java中是一种很流行的做法。

配置参数一般存放在context-param元素中，每一个context-param元素代表了一个键值对。

我 们可以通过实现ServletContextListener接口读取该键值对中的值，在web应用程序初始化的时候，调用 ServletContextListener的contextInitialized()方法，所以我们我们可以重写该方法，实现读取操作。可以这样实 现：

public class AppListener implements ServletContextListener {

public void contextInitialized(ServletContextEvent sce) {
   try {
          
            MyConfig config = new MyConfig();//存放配置信息，用Map实现
            Enumeration parameters =  sce.getServletContext().getInitParameterNames();
           
            while(parameters.hasMoreElements()){
               String name =  (String) parameters.nextElement();
               config.addKeyTValue(name, sce.getServletContext().getInitParameter(name));
            } 

        //相应的键值对存到map中
          config.addKeyValue(parameter, sc.getInitParameter(parameter));
    }
   } catch(Exception e) {
    System.out.println("com.shou error:" + e.getMessage());
   }
}

public void contextDestroyed(ServletContextEvent arg0) {

}
}

 MyConfig类：(Singleton Config)
package com.myapp;

import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;

/**
 *
 * @author Administrator
 */

public class MyConfig{
    public static MyConfig myconfig;
   
    public static HashMap config = new HashMap();

    public static HashMap getConfig() {
        return config;
    }
   
    public static MyConfig getInstance(){
        if(myconfig==null){
            myconfig = new MyConfig();
           
        }
        return myconfig;
    }
    public static void setConfig(HashMap config) {
       
        MyConfig.config = config;
    }

     public HashMap addKeyTValue(String name,String value){
           this.config.put(name, value);
           return this.config;
          
     }
}

接着，必须在web.xml中配置相应的监听类，才能在初始化的时候，自动调用该方法。如：

<listener>
<listener-class>com.myapp.MyListener</listener-class>
</listener>

这样就可以在任何一个JSP页面，通过EL表达式或JSTL读到context-param中的内容。

有的网友说在web.xml内定义<listener>元素时得注意下列两点：
<listener>元素必须出现在任何Context起始参数（由<context-param>元素所定义）之后。
<listener>元素必须出现在任何Servlet实体（由<servlet>元素所定义）之前。

但是我在TOMCAT5.5 +　J2EE 5下配置web.xml并没有按照上述的严格限制也能成功读取信息。

难道是版本的问题吗。

在Struts 1.X下，通过一个自定义的Singleton Config类，可以让web.xml中的配置参数在整个应用程序里都能被共享。

<display-name>Sample Application</display-name>

<description>
This is a Sample Application
</description>

<!--
filter 配置Servlet过滤器
filter-name 定义过滤器的名字。当有多个过滤器时，不能同名
filter-class 指定实现这一过滤的类，这个类负责具体的过滤事务
-->
<filter>
<filter-name>SampleFilter</filter-name>
<filter-class>mypack.SampleFilter</filter-class>
</filter>

<!--
filter-mapping 设定过滤器负责过滤的URL
filter-name 过滤器名。这里的名字一定要和filter中的过滤器名匹配
url-pattern 指定过滤器负责过滤的URL
-->
<filter-mapping>
<filter-name>SampleFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>

<!--
servlet 配置Servlet.
servlet-name 定义Servlet的名字
servlet-class 指定实现这个servlet的类
init-param 定义Servlet的初始化参数和参数值，可有多个init-param。在servlet类中通过getInitParamenter(String name)方法访问初始化参数
load-on-startup 指定当Web应用启动时，装载Servlet的次序。
当值为正数或零时：Servlet容器先加载数值小的servlet，再依次加载其他数值大的servlet.
当值为负或未定义：Servlet容器将在Web客户首次访问这个servlet时加载它
-->
<servlet>
<servlet-name>SampleServlet</servlet-name>
<servlet-class>mypack.SampleServlet</servlet-class>
<init-param>
<param-name>initParam1</param-name>
<param-value>2</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

<!--
配置servlet映射（下面代码为SampleServlet指定的相对URL为"/sample":
servlet-name 指定servlet的名字，这里的名字应该和<Servlet>元素中定义的名字匹配。
url-pattern 指定访问这个servlet的URL。只需给出相对路径。
-->
<servlet-mapping>
<servlet-name>SampleServlet</servlet-name>
<url-pattern>/sample</url-pattern>
</servlet-mapping>

<!--配置session session用来设定HttpSession的生命周期。单位（秒）-->
<session-config>
<session-timeout>30</session-timeout>
</session-config>

<!--配置Wel0come0文件清单-->
<welcome-file-list>
<welcome-file>login.jsp</welcome-file>
<welcome-file>index.htm</welcome-file>
</welcome-file-list>

<!--
配置Tag Library
taglib-uri 设定Tag Library的唯一标识符，在Web应用中将根据这一标识符来引用Tag Library
taglib-location 指定和Tag Library对应的TLD文件的位置
-->
<taglib>
<taglib-uri>/mytaglib</taglib-uri>
<taglib-location>/WEB-INF/mytaglib.tld</taglib-location>
</taglib>

<!--
配置资源引用
description 对所引用的资源的说明
res-ref-name 指定所引用资源的JNDI名字
res-type 指定所引用资源的类名字
res-auth 指定管理所引用资源的Manager,它有两个可选值：
Container：由容器来创建和管理resource
Application:同WEB应用来创建和管理Resource
-->
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/sampleDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

<!--
配置安全约束（以下代码指定当用户访问该WEB应用下的所有资源时，必须具备guest角色）
web-resource-collection 声明受保护的WEB资源
auth-constraint 声明可以访问受保护资源的角色，可以包含多个<role-name>子元素

web-resource-name 标识受保护的WEB资源
url-pattern 指定受保护的URL路径
-->
<Security-constraint>
<web-resource-collection>
<web-resource-name>sample appliction</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>guest</role-name>
</auth-constraint>
</Security-constraint>

<!--
配置安全验证登录界面：指定当WEB客户访问受保护的WEB资源时，系统弹出的登录对话框的类型。
auth-method 指定验证方法，它有三个可选值：BASIC(基本验证)、DIGEST(摘要验证)、FORM(表单验证)
realm-name 设定安全域的名称
form-login-config 当验证方法为FORM时，配置验证网页和出错网页
form-login-page 当验证方法为FORM时，设定验证网页
form-error-page 当验证方法为FORM时，设定出错网页
-->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>
Tomcat Server Configuration form-Based Authentication Area
</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>

<!--配置对安全验证角色的引用-->
<security-role>
<description>
The role that is required to log into the sample application
</description>
<role-name>guest</role-name>
</security-role>
</web-app>

Java定时器在Web中的应用

在web中,定时器的启动一般随web server的启动而启动,一般有两种方法.

方法一：在web.xml里配置一个Servlet，并设置其随web server的启动而启动。然后在该Servlet的init()方法里启动定时器，在destory()方法里销毁定时器。
方法二：在web.xml里配置一个Listener,然后在该Listener的初始化方法里启动定时器，在其销毁的方法朝左销毁定时器。

 定时执行操作

在web.xml配置这个servlet为服务启动时就调用servlet

<servlet></servlet>

在web中,定时器的启动一般随web server的启动而启动,一般有两种方法.

方法一：在web.xml里配置一个Servlet，并设置其随web server的启动而启动。然后在该Servlet的init()方法里启动定时器，在destory()方法里销毁定时器。
方法二：在web.xml里配置一个Listener,然后在该Listener的初始化方法里启动定时器，在其销毁的方法朝左销毁定时器。

 定时执行操作

在web.xml配置这个servlet为服务启动时就调用servlet

<servlet></servlet>

   为啥很多地方说“覆写equals的时候一定要覆写hashCode”。说到这里我知道很多人知道有个原则：如果a.equals(b)那么要确保a.hashCode()==b.hashCode()。为什么？hashCode和我写的程序的业务逻辑毫无关系，为啥我要override? 要我说如果你的class永远不可能放在hash code为基础的容器内，不必劳神，您真的不必override hashCode() :)

    说得准确一点放在HashMap和Hashtable里面如果是作为value而不是作为key的话也是不必override hashCode了。至于HashSet，实际上它只是忽略value的HashMap,每次HashSet.add(o)其实就是 HashMap.put(o, dummyObject)。

    那为什么放到Hash容器里面要overide hashCode呢？因为每次get的时候HashMap既要看equals是不是true也要看hash code是不是一致，put的时候也是要看equals和hash code。

    如果说到这里您还是不太明白，咱就举个例子：

    譬如把一个自己定义的class Foo{...}放到HashMap。实际上HashMap也是把数据存在一个数组里面，所以在put函数里面，HashMap会调 Foo.hashCode()算出作为这个元素在数组里面的下标，然后把key和value封装成一个对象放到数组。等一下，万一2个对象算出来的 hash code一样怎么办？会不会冲掉？先回答第2个问题，会不会冲掉就要看Foo.equals()了，如果equals()也是true那就要冲掉了。万一 是false,就是所谓的collision了。当2个元素hashCode一样但是equals为false的时候，那个HashMap里面的数组的这 个元素就变成了链表。也就是hash code一样的元素在一个链表里面，链表的头在那个数组里面。

回过来说get的时候，HashMap也先调key.hashCode()算出数组下标，然后看equals是不是true，所以就涉及了equals。

    反观假设如果a.equals(b)但是a.hashCode()!=b.hashCode()的话，在put元素a之后，我们又用一个 a.equals(b)但是b.hashCode()!=a.hashCode()的b元素作为key来get的时候就找不到a了。如果 a.hashCode()==b.hashCode()但是!a.equals(b)倒是不要紧，这2个元素会collision然后被放到链表，只是效 率变差。

  这里有个非常简化版的HashMap实现帮助大家理解。

这个问题的权威阐释可以参考Bloch的<Effective Java>的 Item 9: Always override hashCode when you override equals

引言

数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除 （delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。

设计范式是不是很难懂呢？非也，大学教材上给我们一堆数学公式我们当然看不懂，也记不住。所以我们很多人就根本不按照范式来设计数据库。

实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这 些范式应用于实际工程。

范式说明

第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性 由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

例如，如下的数据库表是符合第一范式的：

很显然，在当前的任何关系数据库管理系 统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中 设计出不符合第一范式的数据库都是不可能的。

第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部 分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

　假设仓库管理关系表为 StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以， (仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以 其不符合BCNF范式。它会出现如下异常情况：

(1) 删除异常：

当仓库被清空后，所有"存储物品ID"和"数 量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。

(2) 插入异常：

当仓库没有存储任何物 品时，无法给仓库分配管理员。

(3) 更新异常：

如果仓库换了管理员，则表中所有行的管理员ID都要修改。

把仓库管理关系表分解为二个关系表：

仓库管理：StorehouseManage(仓库ID, 管理员ID)；

仓库：Storehouse(仓库ID, 存储物品ID, 数量)。

这样的数据库表是符合BCNF范式的，消除了删除异常、插入异 常和更新异常。

范式应用

我们来逐步搞定一个论 坛的数据库，有如下信息：

（1） 用户：用户名，email，主页，电话，联系地址

（2） 帖子：发帖标题，发帖内容，回复标题，回复内容 

第一次我们将数据库设计为仅仅存在表：

• 一致性：可以参考数据库的一致性。每次信息的读取都需要反映最新更新后的数据。
• 可用性：高可用性意味着每一次请求都可以成功完成并受到响应数据
• 分区宽容度：这个是容错机制的要求。一个服务需要在局部出错的情况下，没有出错的那部分被复制的数据分区仍然可以支持部分服务的操作，可以简单的 理解为可以很容易的在线增减机器以达到更高的扩展性，即所谓的横向扩展能力。

      面向海量级的分布式服务设计，基本上分区容忍性(Partition tolerance)是第一要素，因此根据业务的情况，我们需要在一致性(Consistency)和可用性(Availability)之间做取舍。对 于一些业务，譬如支付宝或财付通，一致性会是第一考虑要素，即使是延迟的不一致也是不可接受的，这种时候只能牺牲可用性以保证一致性。对于一些应用，譬如 淘宝或拍拍交易中的评价信息，一般用户是可以接受延迟的一致性，这种时候可以优先考虑可用性，而用最终一致性来保证数据一致，譬如通过某种对帐机制。对于 一些应用，甚至一致性都并非要求，只需要保证差不多一致性即可，譬如Q-zone中的农场游戏中的偷菜。
      根据我们应用的业务需求，选择合适的一致性级别，以更好地保证系统的分区容忍性和可用性。
      2．柔性可用
      面向海量级的分布式服务设计，我们要意识到，一切都是不可靠的，在不可靠的环境的环境中构建可靠的应用，其中最重要的一点就是保持系统的柔性。
      1）不可靠的环境
      我们可能已经见惯一个远程服务提供不了服务了，运行一段时间后WebServer突然不响应了，数据库随着负载的不断增加再放上一条SQL语句就会垮掉。 但是，硬盘坏掉、电源断掉、光纤中断，听起来似乎多么不可思议，然而，当一个海量服务需要成千上万台服务器、需要部署全国各地的数十个数据中心、需要横跨 电信网通教育网三大网络的时候，一切听起来不可思议的事情会变成常态。一切都是不可靠的，唯一可靠的就是不可靠本身。
      2）划分服务级别
      我们应该意识到，在这种不可靠的环境中提供完美的服务，本身就是一个神话，即使不是说完全不可能，但至少是代价高昂的，因此，当某些问题发生（环境变地不 可靠的时候），我们必须做出取舍，选择为用户提供用户最关心的服务，这种服务虽然听起来是有损的（至少是不完美的），但却能在一定程度上满足用户大部分的 需求。譬如，当网络带宽无法为用户提供最好的体验而扩容又不是短期可以达到的时候，选择降低一些非重要服务的体验是一个比较好的选择。
      在面向海量互联网的设计当中，对服务进行分级，当系统变地不可靠的时候，优先提供重要优先级的服务。
      3）尽快响应
      互联网用户的耐心是非常有限的，如果一个页面需要3秒以上才能看到，也许大部分用户的第一选择就是关掉浏览器。在构建柔性可用的互联网服务的时候，响应时 间大部分情况下都是需要最优先考虑。还是一句话，环境是不可靠的，当我们无法尽快从远程服务获得数据、当数据库已经慢如蜗牛，也许当后台还在吭哧吭哧干活 的时候，用户老早已经关闭了页面，处理返回的数据也只是在浪费表情，面向互联网用户，响应就是生命。
       二、策略
       如何让我们的应用提供更高质量的服务呢，这里是一些在日常开发使用到或者观察到的一些策略的总结：

       1．数据sharding
      海量服务相应也意味着海量的用户和海量的用户数据，大家都知道，即使是再强大的数据库、再强大服务器，在单表上亿规模的数据足够让一条简单的SQL语句慢 如蜗牛（甚至于在百万、千万级别上，如果没有采取合适的策略，都无法满足服务要求），一般处理这种千万上亿级数据的大家基本上都会想到的就是数据 sharding，将数据切割成多个数据集，分散到多个数据库的多个表中（譬如将用户数据按用户ID切割成4个数据库每个数据库100个表共400个 表），由于每个表数据足够小可以让我们的SQL语句快速地执行。而至于如何切割，实际上跟具体的业务策略有关系。
       当然，我们要认识到，这种数据sharding并非全无代价的，这也意味着我们需要做出一些折中，譬如可能很难进行跨表数据集的查询、联表和排序也变地非 常困难、同时数据库client程序编写也会变地更加复杂、保证数据一致性在某些情况下会变地困难重重。sharding并非万能药，选择是否 sharding、如何sharding、为sharding如何换用一个近似的业务描述方式，这是业务设计需要仔细考虑的问题。
       2．Cache
       经验会告诉我们，基本上大部分系统的瓶颈会集中在IO/数据库上，常识也告诉我们，网络和内存的速度比IO/数据库会提升甚至不止一个数量级。面向海量服 务，Cache基本上是一个必选项，分布式Cache更是一个不二选择，根据我们的需要，我们可以选择memcached（非持久化）、 memcachedb/Tokyo Tyrant（持久化），甚至构建自己的cache平台。
       在使用Cache上，下面是需要仔细考虑的点：

• 选择合适的Cache分布算法，基本上我们会发现使用取模方式决定Cache位置是不可靠的，因为坏节点的摘除或者节点扩量会让我们的Cache 命中率在短时间内下降到冰点，甚至会导致系统在短期内的负载迅速增长甚至于崩溃，选择一种合适的分布算法非常重要，譬如稳定的一致性哈希
• Cache管理：为每个应用配置独立的Cache通常不是一个好主意，我们可以选择在大量的机器上，只要有空闲内存，则运行Cache实例，将 Cache实例分成多个组，每个组就是一个完整的Cache池，而多个应用共享一个Cache池
• 合理的序列化格式：使用紧凑的序列化方案存储Cache数据，尽量少存储冗余数据，一方面可以最大能力地榨取Cache的存储利用率，另一方面， 可以更方便地进行容量预估。此外，不可避免地，随着业务的升级，存储的数据的格式有可能会变更，序列化也需要注意向上兼容的问题，让新格式的客户端能够支 持旧的数据格式。
• 容量估算：在开始运行之前，先为自己的应用可能使用到的容量做一个容量预估，以合理地分配合适的Cache池，同时为可能的容量扩充提供参考。
• 容量监控：Cache命中率怎么样，Cache的存储饱和度怎么样，Client的Socket连接数等等，对这些数据的采集和监控，将为业务的 调整和容量的扩充提供了数据支持。
• 选择在哪层上进行Cache，譬如数据层Cache、应用层Cache和Web层Cache，越靠近数据，Cache的通用性越高，越容易保持 Cache数据的一致性，但相应的处理流程也越长，而越靠近用户，Cache的通用性越差，越难保证Cache数据的一致性，但是响应也越快，根据业务的 特点，选择合适的Cache层是非常重要的。一般而言，我们会选择将粗粒度、极少变更、数据对用户不敏感（即可以一定程度上接受误差）、并且非针对用户级 的数据，在最靠近用户的层面上Cache，譬如图片Cache、TOP X等数据；而将一些细粒度、变更相对频繁、用户相对敏感的数据或者是针对用户级的数据放在靠近数据的一段，譬如用户的Profile、关系链等。

       3．服务集群
       面向海量服务，系统的横向扩展基本上是第一要素，在我的经验和经历中，服务集群需要考虑如下因素：

• 分层：合理地对系统进行分层，将系统资源要求不同的部分进行合理地逻辑/物理分层，一般对于简单业务，Client层、WebServer层和 DB层已经足够，对于更复杂业务，可能要切分成Client层、WebServer层、业务层、数据访问层（业务层和数据访问层一般倾向于在物理上处于同 一层）、数据存储层（DB），太多的分层会导致处理流程变长，但相应系统地灵活性和部署性会更强。
• 功能细粒度化：将功能进行细粒度的划分，并使用独立的进程部署，一方面能更有利于错误的隔离，另一方面在功能变更的时候避免一个功能对其他功能产 生影响
• 按数据集部署：如果每一层都允许对下一层所有的服务接口进行访问，将存在几个严重的缺陷，一是随着部署服务的增长，会发现下一层必须允许数量非常 庞大的Socket连接进来，二是我们可能必须把不同的服务部署在不同的数据中心(DC)的不同机房上，即便是上G的光纤专线，机房间的穿梭流量也会变地 不可接受，三是每个服务节点都是全数据容量接入，并不利于做一些有效的内部优化机制，四是只能采用代码级控制的灰度发布和部署。当部署规模达到一定数量级 的时候，按数据集横向切割成多组服务集合，每组服务集合只为特定的数据集服务，在部署上，每组服务集合可以部署在独立的相同的数据中心(DC)上。
• 无状态：状态将为系统的横向扩容带来无穷尽的烦恼。对于状态信息比少的情况，可以选择将全部状态信息放在请求发器端，对于状态信息比较多的情况， 可以考虑维持一个统一的Session中心。
• 选择合适的负载均衡器和负载均衡策略：譬如在L4上负载均衡的LVS、L7上负载均衡的Nginx、甚至是专用的负载均衡硬件F5（L4），对于 在L7上工作的负载均衡器，选择合适的负载均衡策略也非常重要，一般让用户总是负载均衡到同一台后端Server是一个很好的方式

      4．灰度发布
      当系统的用户增长到一定的规模，一个小小功能的发布也会产生非常大的影响，这个时候，将功能先对一小部分用户开放，并慢慢扩展到全量用户是一个稳妥的做 法，使用灰度化的发布将避免功能的BUG产生大面积的错误。如下是一些常见的灰度控制策略：

• 白名单控制：只有白名单上的用户才允许访问，一般用于全新功能Alpha阶段，只向被邀请的用户开放功能
• 准入门槛控制：常见的譬如gmail出来之初的邀请码、QQ农场开始阶段的X级的黄钻准入，同样一般用于新功能的Beta阶段，慢慢通过一步一步 降低门槛，避免在开始之处由于系统可能潜在的问题或者容量无法支撑导致整个系统的崩溃。
• 按数据集开放：一般常用于成熟的功能的新功能开发，避免新功能的错误产生大面积的影响

      5．设计自己的通信协议：二进制协议、向上/下兼容
      随着系统的稳定运行访问量的上涨，慢慢会发现，一些看起来工作良好的协议性能变地不可接受，譬如基于xml的协议xml-rpc，将会发现xml解析和包 体的增大变地不可接受，即便是接近于二进制的hessian协议，多出来的字段描述信息(按我的理解，hessian协议是类似于map结构的，包含字段 的名称信息)和基于文本的http头将会使协议效率变地低下。也许，在开始合适的时候而不是到最后不得已的时候，去设计一个良好的基于二进制的高效的内部 通信协议是一个好的方式。按我的经验，设计自己的通信协议需要注意如下几点：

• 协议紧凑性，否则早晚你会为你浪费的空间痛心疾首
• 协议扩展性，早晚会发现旧的协议格式不能适应新的业务需求，而在早期预留变地非常地重要，基本上，参见一些常用的规范，魔术数（对于无效果的请求 可以迅速丢弃）、协议版本信息、协议头、协议Body、每个部分（包括结构体信息中的对象）的长度这些信息是不能省的
• 向下兼容和向上兼容：但功能被大规模地调用的时候，发布一个新的版本，让所有的client同时升级基本上是不可接受的，因此在设计之处就需要考 虑好兼容性的问题

      6．设计自己的Application Server
      事情进行到需要自己设计通信协议，自己构建Application Server也变地顺理成章，下面是在自己开发Application Server的时候需要处理的常见的问题：

• 过载保护：当系统的某个部件出现问题的时候，最常见的情况是整个系统的负载出现爆炸性的增长而导致雪崩效应，在设计application server的时候，必须注意进行系统的过载保护，当请求可以预期无法处理的时候(譬如排队满载或者排队时间过长)，丢弃是一个明智的选择，TCP的 backlog参数是一个典型的范例。
• 频率控制：即便是同一系统中的其他应用在调用，一个糟糕的程序可能会将服务的所有资源占完，因此，应用端必须对此做防范措施，频率控制是其中比较 重要的一个
• 异步化/无响应返回：对于一些业务，只需要保证请求会被处理即可，客户端并不关心什么时候处理完，只要最终保证处理就行，甚至最终没有处理也不是 很严重的事情，譬如邮件，对于这种应用，应快速响应避免占着宝贵的连接资源，而将请求进入异步处理队列慢慢处理。
• 自我监控：Application Server本身应该具备自我监控的功能，譬如性能数据采集、为外部提供内部状态的查询（譬如排队情况、处理线程、等待线程）等
• 预警：譬如当处理变慢、排队太多、发生请求丢弃的情况、并发请求太多的时候，Application Server应该具备预警的能力以快速地对问题进行处理
• 模块化、模块间松耦合、机制和策略分离：如果不想一下子面对所有的复杂性或不希望在修改小部分而不得不对所有的测试进行回归的话，模块化是一个很 好的选择，将问题进行模块切割，每个模块保持合理的复杂度，譬如对于这里的Application Server，可以切分成请求接收/管理/响应、协议解析、业务处理、数据采集、监控和预警等等模块。这里同时要注意块间使用松耦合的方式交互，譬如，请 求接收和业务处理之间则可以使用阻塞队列通信的方式降低耦合。另外还需要注意的是机制和策略的分离，譬如协议可能会变更、性能采集和告警的方式可能会变化 等等，事先的机制和策略分离，策略变更的处理将变地更加简单。

       7．Client
      很多应用会作为服务的Client，去调用其他的服务，如下是在做为Client应该注意的一些问题：

• 服务不可靠：作为Client永远要记住的一点就是，远程服务永远是不可靠的，因此作为Client自己要注意做自我保护，当远程服务如果无法访 问时，做折中处理
• 超时保护：还是上面所说的，远程服务永远都是不可靠的，永远也无法预测到远程什么时候会响应，甚至可能不会响应（譬如远程主机宕机），请求方要做 好超时保护，譬如对于主机不可达的情况，在linux环境下，有时会让客户端等上几分钟TCP层才会最终告诉你服务不可到达。
• 并发/异步：为了提速响应，对于很多可以并行获取的数据，我们总是应该并行地去获取，对于一些我们无法控制的同步接口——譬如读数据库或同步读 cache——虽然不是很完美，但多线程并行去获取是一个可用的选择，而对于服务端都是使用自构建的Application Server，使用异步Client接口至关重要，将请求全部发送出去，使用异步IO设置超时等待返回即可，甚至于更进一步异步anywhere，在将 client与application server整合到一块的时候，请求发送出去之后立即返回，将线程/进程资源归还，而在请求响应回来符合条件的时候，触发回调做后续处理。

      8．监控和预警
      基本上我们会见惯了各种网络设备或服务器的监控，譬如网络流量、IO、CPU、内存等监控数据，然而除了这些总体的运行数据，应用的细粒度化的数据也需要 被监控，服务的访问压力怎么样、处理速度怎么样、性能瓶颈在哪里、带宽主要是被什么应用占、Java虚拟机的CPU占用情况怎么样、各内存区的内存占用情 况如何，这些数据将有利于我们更好的了解系统的运行情况，并对系统的优化和扩容提供数据指导。

      除了应用总体监控，特定业务的监控也是一个可选项，譬如定时检查每个业务的每个具体功能点(url)访问是否正常、访问速度如何、页面访问速度如何（用户 角度，包括服务响应时间、页面渲染时间等，即网页测速）、每个页面的PV、每个页面（特别是图片）每天占用的总带宽等等。这些数据将为系统预警和优化提供 数据上的支持，例如对于图片，如果我们知道哪些图片占用的带宽非常大（不一定是图片本身比较大，而可能是访问比较大），则一个小小的优化会节省大量的网络 带宽开销，当然，这些事情对于小规模的访问是没有意义的，网络带宽开销节省的成本可能都没有人力成本高。
      除了监控，有效的预警机制也是必不可少，应用是否在很好地提供服务、响应时间是否能够达到要求、系统容量是否达到一个阀值。有效的预警机制将让我们尽快地 对问题进行处理。
      9．配置中心化
      当系统错误的时候，我们如何尽快地恢复呢，当新增服务节点的时候，如何尽快地让真个系统感知到呢？当系统膨胀之后，如果每次摘除服务节点或者新增节点都需 要修改每台应用配置，那么配置和系统的维护将变地越来越困难。
     配置中心化是一个很好的处理这个问题的方案，将所有配置进行统一地存储，而当发生变更的时候（摘除问题节点或者扩量增加服务节点或新增服务），使用一些通 知机制让各应用刷新配置。甚至于，我们可以自动地检测出问题节点并进行智能化的切换。
      三、最后
      构建面向海量用户的服务，可以说是困难重重挑战重重，一些原则和前人的设计思路可以让我们获得一些帮助，但是更大的挑战会来源于细节部分，按我们技术老大 的说法，原则和思路只要看几本书是个技术人员都会，但决定一个系统架构师能力的，往往却是对细节的处理能力。因此，在掌握原则和前人的设计思路的基础上， 更深入地挖掘技术的细节，才是面向海量用户的服务的制胜之道。

Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应 (response)，例如送回一个HTML页面。为了处理一个请求(request)，Web服务器可以响应(response)一个静态页面或图片， 进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本，JSP(JavaServer Pages)脚本，servlets，ASP(Active Server Pages)脚本，服务器端(server-side)JavaScript，或者一些其它的服务器端(server-side)技术。无论它们(译者 注：脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。

要知道，Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注：服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响 应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。

虽然 Web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。

应用程序服务器(The Application Server)
根据我们的定义，作为应用程序服务器， 它通过各种协议，可以包括HTTP，把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览，而应用程序 服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法(或过程语言中的一个函数)一样。

应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务 器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑(program logic)。 正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。

在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的，例 如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)， 和消息(messaging)。就象Web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。

一个例子
例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后，网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序 服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。

情景 1：不带应用程序服务器的Web服务器

在此种情景下，一个Web服务器独立提供在线商店的功能。Web服务器获 得你的请求(request)，然后发送给服务器端(server-side)可以处理请求(request)的程序。此程序从数据库或文本文件 (flat file，译者注：flat file是指没有特殊格式的非二进制的文件，如properties和XML文件等)中查找定价信息。一旦找到，服务器端(server-side)程序 把结果信息表示成(formulate)HTML形式，最后Web服务器把会它发送到你的Web浏览器。

简而言之，Web服务器只是简 单的通过响应(response)HTML页面来处理HTTP请求(request)。

情景2：带应用程序服务器的 Web服务器

情景2和情景1相同的是Web服务器还是把响应(response)的产生委托 (delegates)给脚本(译者注：服务器端(server-side)程序)。然而，你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。 这时当该脚本程序产生HTML响应(response)时就可以使用该服务的返回结果了。

在此情景中，应用程序服务器提供 (serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细 节，相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。

通过从响应产生(response-generating)HTML的 代码中分离出来，在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端，例如收款机，也可以调用同样的服务(service)来作为一个店员 给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在HTML页中了。

总而言之，在情景2的模型中，在Web服务器 通过回应HTML页面来处理HTTP请求(request)，而应用程序服务器则是通过处理定价和有效性(availability)请求 (request)来提供应用程序逻辑的。

警告(Caveats)
现在，XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器，Web服务器现在可以处理数 据和响应(response)的能力与以前的应用程序服务器同样多了。

另外，现在大多数应用程序服务器也包含了Web服务器，这就意味 着可以把Web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了Web服务器的功能，但是开发者很少把应用程序服务器部 署(deploy)成这种功能(capacity)(译者注：这种功能是指既有应用程序服务器的功能又有Web服务器的功能)。相反，如果需要，他们通常 会把Web服务器独立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的Web请求(request)就不会影响应用程序服务器 了)，分开配置(专门的Web服务器，集群(clustering)等等)，而且给最佳产品的选取留有余地。

连日下来的笔试彻底印证了师兄们的话，笔试基本不过。最可惜的是淘宝，笔试中发挥不错终于能进一面，一开始聊家常聊框架聊开源技术还聊得不错，突然 间，连续问了三个问题：

1.多线程访问hashtable和hashmap有什么不一样？我只答出线程安全不一样，具体怎么不一样就有一句每一句了（回来google一 下，这种java基础还真TM简单，枉称精通java了）

2.平衡二叉树查找算法的复杂度？再次雷响，随便蒙了个归并排序的复杂度给他。

3.对于100W条数据的排序和查找有什么效率高的方式？完了，结结巴巴的说一通，最后自认不会……

原本以为技术面会比笔试好过的，回学校的路上我泪流满面啊我。这些都不是RP问题了，铁了心恶补数据结构……

Java线 程安全同步解决方案 

1、 问题描述：

　　如果一个资源或对象可能被多个线程同时访问，它就是一个共享资源；例如 类的成员变量，包括类变量和实例变量，再比如对一个文件进行写操作等。一般情况下，对共享资源的访问需要考虑线程安全的问题。

　　如果一个对象的完整生命周期只在一个线程内，则不需要考虑线程安全，例 如一个局部变量。下面为一个示例代码：

　　假如在一个JSP中这样的去调用：

　　则这样的代码不是线程安全的。因为java.text.SimpleDateFormat 不是线程安全的，a.jsp中的代码将会有若干个线程同时执行，而都访问的是同一个线程不安全的对象，这样就不是一个线程安全的代码。正确的写法应该如 下：

2、 原因分析：

　　此时，sdf对象从创建到销毁都位于一个方法中，相当于一个局部变量，不是一个共享资源，因此则没有线程不安全的问题。

3、 解决方法或过程：

1） 如果对象是immutable，则是线程安全的，例如:String，可以放心使用。
2） 如果对象是线程安全的，则放心使用
3） 有 条件线程安全，对于Vector和Hashtable一般情况下是线程安全的，但是对于某些特殊情况，需要通过额外的synchronized保证线程安 全。
4） 使用synchronized关键字；

　　对于上例中可以改写jsp代码，在sdf上进行同步，而不需要每次创建一个新的对象来保证线程安全，代码如下：

　　这种写法是在一个对象级别上进行同步，也就是说任何时候，对于这个对象，最多只能有一个线程在执行同步方法。

　　另外一种写法是在Class级别上进行同步，写法如下：

　　这种写法表示无论C1有多少个实例，在任何一个时间点，最多只能有一个线程和一个实例进入同步块中。这种同步会比较大的影响性能。

　　5） 有些对象不能在多线程间共享，则只能在方法内部使用，或者只在一个线程内部使用。

synchronized详解

Java对多线程的支持与同步机制深受大家的喜爱，似乎看起来使用了synchronized关键字就可以轻松地解决多线程共享数据同步问题。到底如何？――还得对synchronized关键字的作用进行深入了解才可定论。

总的说来，synchronized关键字可以作为函数的修饰符，也可作为函数内的语句，也就是平时说的同步方法和同步语句块。如果再细的分类，synchronized可作用于instance变量、object reference（对象引用）、static函数和class literals(类名称字面常量)身上。

在进一步阐述之前，我们需要明确几点：

A．无论synchronized关键字加在方法上还是对象上，它取得的锁都是对象，而不是把一段代码或函数当作锁――而且同步方法很可能还会被其他线程的对象访问。

B．每个对象只有一个锁（lock）与之相关联。

C．实现同步是要很大的系统开销作为代价的，甚至可能 造成死锁，所以尽量避免无谓的同步控制。

接着来讨论synchronized

用到不同地方对代码产生的影响：

假设P1、P2是同一个类的不同对象，这个类中定义了以下几种情况的同步块或同步方法，P1、P2就都可以调用它们。

1． 把synchronized当作函数修饰符时，示例代码如下：

Public synchronized void methodAAA()

{

//….

}

这也就是同步方法，那这时synchronized锁定的是哪个对象呢？它锁定的是调用这个同步方法对象。也就是说，当一个对象P1在不 同的线程中执行这个同步方法时，它们之间会形成互斥，达到同步的效果。但是这个对象所属的Class所 产生的另一对象P2却可以任意调用这个被加了synchronized关键字的方法。

上边的示例代码等同于如下代码：

public void methodAAA()

{

synchronized (this)      // (1)

{

       //…..

}

}

 (1)处 的this指的是什么呢？它指的就是调用这个方法的对象，如P1。可见 同步方法实质是将synchronized作用于object reference。――那个拿到了P1对象 锁的线程，才可以调用P1的同步方法，而对P2而 言，P1这个锁与它毫不相干，程序也可能在这种情形下摆脱同步机制的控制，造成数据混乱：（

2．同步块，示例代码如下：

           public void method3(SomeObject so)

              {

                     synchronized(so)

{

       //…..

}

}

这时，锁就是so这个对象，谁拿到这个锁谁就可以运行它所控制的那段代码。当有一个明确的对象作为锁时，就可以这样写程序，但当没有明确的对象作为 锁，只是想让一段代码同步时，可以创建一个特殊的instance变量（它得是一个对象）来充当锁：

class Foo implements Runnable

{

       private byte[] lock = new byte[0]; // 特殊的instance变量

    Public void methodA()

{

       synchronized(lock) { //… }

}

//…..

}

注：零长度的byte数 组对象创建起来将比任何对象都经济――查看编译后的字节码：生成零长度的byte[]对 象只需3条操作码，而Object lock = new Object()则 需要7行操作码。

3．将synchronized作用于static 函数，示例代码如下：

      Class Foo

{

public synchronized static void methodAAA()   // 同步的static 函数

{

//….

}

public void methodBBB()

{

       synchronized(Foo.class)   // class literal(类名称字面常量)

}

       }

   代码中的methodBBB()方法是把class literal作为锁的情况，它和同步的static函 数产生的效果是一样的，取得的锁很特别，是当前调用这个方法的对象所属的类（Class， 而不再是由这个Class产生的某个具体对象了）。

记得在《Effective Java》一书中看到过将 Foo.class和 P1.getClass()用于作同步锁还不一样，不能用P1.getClass()来达到锁这个Class的目的。P1指的是由Foo类产生的对象。

可以推断：如果一个类中定义了一个synchronized的static函数A，也定 义了一个synchronized 的instance函数B，那么这个类的同一对象Obj在多线程中分别访问A和B两个方法时，不会构成同步，因为它们的锁都不一样。A方法的锁 是Obj这个对象，而B的锁是Obj所属的那个Class。

小结如下：

搞清楚synchronized锁定的是哪个对象，就能帮助我们设计更安全的多线程程序。

还有一些技巧可以让我们对共享资源的同步访问更加安全：

1． 定义private 的instance变量+它的 get方法，而不要定义public/protected的instance变量。如果将变量定义为public，对象在外界可以绕过同步方法的控制而 直接取得它，并改动它。这也是JavaBean的标准实现方式之一。

2． 如果instance变量是一个对象，如数组或ArrayList什么的，那上述方法仍然不安全， 因为当外界对象通过get方法拿到这个instance对象的引用后，又将其指向另一个对象，那么这个private变量也就变了，岂不是很危险。这个时候就需要将get方法 也加上synchronized同步，并且，只返回这个private对象的clone()――这样，调用端得到的就是对象副本的引用了。

详细论述：eqauls 与 = =之异同

1）比较方式角度：

= =是面向过程的操作符；equals是面向对象的操作符

= =不属于任何类，equals则是任何类（在Java中）的一个方法；

我们可以1）Primitive1 (基本类型)= = Primitive2(基本类型)；

         2）Object Reference1(对象引用)= = Object Reference2(对象引用)

         3）Object Reference1 (对象引用) .equals(Object Reference2 (对象引用))

           这三种比较

           但却不能Primitive1 (基本类型).equals( Primitive2(基本类型))；

 对于基本类型，没有面向对象中发送消息一说，自然也不会有

方法成员。

2）比较目的角度:

1）    如果要比较两个基本类型是否相等，请用= =；

2）    如果要比较两个对象引用是否相等，请用= =；

3）    如果要比较两个对象（逻辑上）是否一致，请用equals；

对两个对象（逻辑上）是否一致的阐释：

   有人会问:在C++中, 比较两个对象相等不是也可以用==吗？我知道您是指运算符重载，但是很遗憾，Java中不支持运算符重载（java中亦有重载过运算符，他们是“+”，“+=”，不过也仅此两个，而且是内置实现的）；所以，对象的是否相等的比较这份责任就交由  equals()来实现 。   

这个“逻辑上”其实就取决于人类的看法，实际开发中，就取决于用户的需求；

第三节：equals()缘起：

        equals()是每个对象与生俱来的方法，因为所有类的最终基类就是Object(除去Object本身)；而equals()是Object的方法之一。

        我们不妨观察一下Object中equals()的source code:

         public boolean equals(Object obj) {

                      return (this == obj);

          }

        注意 “return (this == obj)”

        this与obj都是对象引用，而不是对象本身。所以equals()的缺省实现就是比较

        对象引用是否一致；为何要如此实现呢？ 前面我们说过：对象是否相等，是由我们的需求决定的，世界上的类千奇百怪（当然，这些类都是我们根据模拟现实世界而创造的），虽然Object是他们共同的祖先，可他又怎能知道他的子孙类比较相等的标准呢？但是他明白，任何一个对象，自己总是等于自己的，何谓“自己总是等于自己”呢，又如何判断“自己总是等于自己”呢？一个对象在内存中只有一份，但他的引用却可以有无穷多个，“对象自己的引用1=对象自己的引用2”，不就能判断“自己总是等于自己”吗？所以缺省实现实现自然也就是

        “return (this == obj)”；

        而到了我们自己编写的类，对象相等的标准由我们确立，于是就不可避免的要覆写

        继承而来的public boolean equals(Object obj)；

        如果您有过编覆写过equals（）的经验（没有过也不要紧），请您思考一个问题：

         “两个对象（逻辑上）是否一致”实际上是比较什么？没错，或许您已脱口而出：

       就是对象的属性（即field，或称数据成员）的比较。方法是不可比较的哦。（这个问题是不是有些弱智呢？哈哈）

 第四节：对一个推论的思考

推论如下：一言以蔽之：欲比较栈中数据是否相等，请用= =；

                      欲比较堆中数据是否相等，请用equals；

因为（根）基本类型，（根）对象引用都在栈中； 而对象本身在堆中；

         这句话又对又不对，问题出在哪，就是“数据”二字，先看栈中，数据或为基本类型，或为对象引用，用==比较当然没错；但是堆中呢？对象不是堆中吗？不是应该用equals比较吗？可是，我们比较的是堆中“数据”，堆中有对象，对象由什么构成呢？可能是对象引用，可能是基本类型，或两者兼而有之。如果我们要比较他们，该用什么呢，用”equals()”?不对吧，只能是”= =”!所以正确的结论是：欲比较栈中数据是否相等，请用= =； 欲比较堆中数据是否相等，请用equals；

因为（根）基本类型，（根）对象引用都在栈中（所谓“根”，指未被任何其他对象所包含）； 而对象本身在堆中。

文章出处：DIY部落(http://www.diybl.com/course/3_program/java/javajs/2007917/71587.html#)

JAVA语言中的反射机制：
    在Java 运行时 环境中，对于任意一个类，能否知道这个类有哪些属性和方法？
    对于任意一个对象，能否调用他的方法？这些答案是肯定的，这种动态获取类的信息，以及动态调用类的方法的功能来源于JAVA的反射。从而使java具有动态语言的特性。

  JAVA反射机制主要提供了以下功能：
      1.在运行时判断任意一个对象所属的类
      2.在运行时构造任意一个类的对象
      3.在运行时判断任意一个类所具有的成员变量和方法（通过反射甚至可以调用private方法）
      4.在运行时调用任意一个对象的方法（*****注意：前提都是在运行时，而不是在编译时）

  Java 反射相关的API简介：
      位于java。lang。reflect包中
        --Class类：代表一个类
        --Filed类：代表类的成员变量
        --Method类：代表类的方法
        --Constructor类：代表类的构造方法
        --Array类：提供了动态创建数组，以及访问数组的元素的静态方法。该类中的所有方法都是静态方法

----Class类
     在 java 的Object类中的申明了数个应该在所有的java类中被改写的methods：
hashCode(), equals(),clone(),toString(),getClass()等，其中的getClass()返回yige
Class 类型的对象。
     Class类十分的特殊，它和一般的类一样继承自Object，其实体用以表达java程序运行
时的 class和 interface，也用来表达 enum，array，primitive，Java Types 以及关键字void
，当加载一个类，或者当加载器（class loader）的defineClass（）被JVM调用，便产生一个Class
对象，
     Class是Reflection起源，针对任何你想探勘的class（类），唯有现为他产生一个Class
的对象，接下来才能经由后者唤起为数十多个的反射API。

     Java允许我们从多种途径为一个类class生成对应的Class对象。
          --运用 getClass（）：Object类中的方法，每个类都拥有此方法
                                String str="abc";
                                Class cl=str.getClass();

         --运用 Class。getSuperclass（）：Class类中的方法，返回该Class的父类的Class
         --运用 Class。forName（）静态方法：
         --运用 ,Class：类名.class
         --运用primitive wrapper classes的TYPE语法： 基本类型包装类的TYPE，如：Integer.TYPE
                      注意：TYPE的使用，只适合原生（基本）数据类型

----运行时生成instance
     想生成对象的实体，在反射动态机制中有两种方法，一个针对无变量的构造方法，一个针对带参数的
构造方法，，如果想调用带参数的构造方法，就比较的麻烦，不能直接调用Class类中的newInstance（）
，而是调用Constructor类中newInstance（）方法，首先准备一个Class[]作为Constructor的参数类型。
然后调用该Class对象的getConstructor（）方法获得一个专属的Constructor的对象，最后再准备一个
Object[]作为Constructor对象昂的newInstance（）方法的实参。
      在这里需要说明的是 只有两个类拥有newInstance（）方法，分别是Class类和Constructor类
Class类中的newInstance（）方法是不带参数的，而Constructro类中的newInstance（）方法是带参数的
需要提供必要的参数。
    例:
      Class c=Class.forName("DynTest");
      Class[] ptype=new Class[]{double.class,int.class}；
      Constructor ctor=c.getConstructor(ptypr);
      Object[] obj=new Object[]{new Double(3.1415),new Integer(123)};
      Object object=ctor.newInstance(obj);
      System.out.println(object);

----运行时调用Method
    这个动作首先准备一个Class[]{}作为getMethod（String name，Class[]）方法的参数类型，接下来准备一个
Obeject[]放置自变量，然后调用Method对象的invoke（Object obj，Object[]）方法。
     注意，在这里调用

----运行时调用Field内容
    变更Field不需要参数和自变量，首先调用Class的getField（）并指定field名称，获得特定的Field对象后
便可以直接调用Field的 get（Object obj）和set(Object obj,Object value)方法