摩根Java面试准备要点

JVM架构

     主要包括两个子系统和两个组件： Class loader(类装载器) 子系统，Execution engine(执行引擎) 子系统；Runtime data area (运行时数据区域)组件， Native interface(本地接口)组件。
     Class loader子系统的作用 ：根据给定的全限定名类名(如 java.lang.Object)来装载class文件的内容到 Runtime data area中的method area(方法区域)。Javsa程序员可以extends java.lang.ClassLoader类来写自己的Class loader。
      Execution engine子系统的作用 ：执行classes中的指令。任何JVM specification实现(JDK)的核心是Execution engine，换句话说：Sun 的JDK 和IBM的JDK好坏主要取决于他们各自实现的Execution engine的好坏。每个运行中的线程都有一个Execution engine的实例。
     Native interface组件 ：与native libraries交互，是其它编程语言交互的接口。
     Runtime data area 组件：这个组件就是JVM中的内存。下面对这个部分进行详细介绍。

Runtime data area的整体架构图

Runtime data area 主要包括五个部分：Heap (堆), Method Area(方法区域), Java Stack(java的栈), Program Counter(程序计数器), Native method stack(本地方法栈)。Heap 和Method Area是被所有线程的共享使用的；而Java stack, Program counter 和Native method stack是以线程为粒度的，每个线程独自拥有。

Heap

Java程序在运行时创建的所有类实或数组都放在同一个堆中。而一个Java虚拟实例中只存在一个堆空间，因此所有线程都将共享这个堆。每一个java程序独占一个JVM实例，因而每个java程序都有它自己的堆空间，它们不会彼此干扰。但是同一java程序的多个线程都共享着同一个堆空间，就得考虑多线程访问对象（堆数据）的同步问题。（这里可能出现的异常java.lang.OutOfMemoryError: Java heap space）

Method area

在Java虚拟机中，被装载的class的信息存储在Method area的内存中。当虚拟机装载某个类型时，它使用类装载器定位相应的class文件，然后读入这个class文件内容并把它传输到虚拟机中。紧接着虚拟机提取其中的类型信息，并将这些信息存储到方法区。该类型中的类（静态）变量同样也存储在方法区中。与Heap 一样，method area是多线程共享的，因此要考虑多线程访问的同步问题。比如，假设同时两个线程都企图访问一个名为Lava的类，而这个类还没有内装载入虚拟机，那么，这时应该只有一个线程去装载它，而另一个线程则只能等待。（这里可能出现的异常java.lang.OutOfMemoryError: PermGen full）

Java stack

Java stack以帧为单位保存线程的运行状态。虚拟机只会直接对Java stack执行两种操作：以帧为单位的压栈或出栈。每当线程调用一个方法的时候，就对当前状态作为一个帧保存到java stack中(压栈)；当一个方法调用返回时，从java stack弹出一个帧(出栈)。栈的大小是有一定的限制，这个可能出现StackOverFlow问题。下面的程序可以说明这个问题。

public class TestStackOverFlow {

    public static void main(String[] args) {

        Recursive r = new Recursive();

        r.doit(10000);

        // Exception in thread "main" java.lang.StackOverflowError

class Recursive {

    public int doit(int t) {

        if (t <= 1) {

            return 1;

        return t + doit(t - 1);

Program counter

每个运行中的Java程序，每一个线程都有它自己的PC寄存器，也是该线程启动时创建的。PC寄存器的内容总是指向下一条将被执行指令的地址;，这里的地址可以是一个本地指针，也可以是在方法区中相对应于该方法起始指令的偏移量。

Native method stack

对于一个运行中的Java程序而言，它还能会用到一些跟本地方法相关的数据区。当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。本地方法可以通过本地方法接口来访问虚拟机的运行时数据区，不止与此，它还可以做任何它想做的事情。比如，可以调用寄存器，或在操作系统中分配内存等。总之，本地方法具有和JVM相同的能力和权限。 (这里出现JVM无法控制的内存溢出问题native heap OutOfMemory )

CLassLoader (Vincent)

Java的可执行文件不同于C/C++，Java编译器只产生中间字节码文件(.class文件)，由Java虚拟机（java.exe）解释执行。Java发布的程序（JAR包）也多半是一堆class文件，运行时由ClassLoader加载到Java虚拟机中执行。ClassLoader是Java虚拟机的主要组成部分，由Java语言编写，用户可以实现自定义的ClassLoader来完成特定的功能。下面我们用例子说明ClassLoader。

JVM规范定义了两种类型的ClassLoader：Bootstrap ClassLoader和User-defined ClassLoader。

JVM在运行时会产生三个ClassLoader:Bootstrap ClassLoader、Extension ClassLoader和AppClassLoader。Bootstrap是用C++编写的，我们在Java中看不到它，是null,是JVM自带的类装载器，用来装载核心类库，如java.lang.*等。AppClassLoader的Parent是ExtClassLoader，而ExtClassLoader的Parent为Bootstrap ClassLoader。

java中，什么叫不可更改的类（immutable class）（Kevin Tam）

从字面意思来理解就是不会发生变化的类，那么是什么不会发生变化呢，其实就是类的状态，也就是不变类的实例一旦被创建，其状态就不会发生变化，举个例子：如果人是一个class，那么我们中的每一个都是人这个类的具体的instance，如果人这个类只有一个状态就是生身父母，那么它就是一个不变类，因为每一个人在出生的那一刹那，生身父母就已经被设置了值，而且终生都不会发生变化。

不变类有什么好处呢？

1）
不变类是线程安全的，由于不变类的状态在创建以后不再发生变化，所以它可以在线程之间共享，而不需要同步。

2）
不变类的instance可以被reuse

创建类的实例需要耗费CPU的时间，当这个实例不再被引用时，将会被垃圾回收掉，这时候，又需要耗费CPU的时间。对于不变类而言，一个好处就是可以将常用的实例进行缓存，从而减少了对象的创建。举个例子，对于布尔型，最常用的便是true and false。JDK中的Boolean类就是一个不变类，并且对这两个实例进行了缓冲。

public final class Boolean implements java.io.Serializable{

public static final Boolean TRUE = new Boolean(true);

public static final Boolean FALSE = new Boolean(false);

// 这个方法不会创建新的对象，而是重用已经创建好的instance

public static Boolean valueOf(boolean b) {

return (b ? TRUE : FALSE);

}

3）
不变类的某些方法可以缓存计算的结果

hashCode这个方法来自于Object这个类，这个方法用来返回对象的hashCode,主要用于将对象放置到hashtable中时，来确定这个对象的存储位置。对于一个不变类的实例，它的hashCode也是不变的，所以就可以缓存这个计算的结果，来提高性能，避免不必要的运算，JDK中的String类就是一个例子。

public final class String{

private int hash; // Default to 0

public int hashCode() {

int h = hash;

if (h == 0) {

// compute the value

hash = h; // cache the value

}

return h;

}

在JDK中， String, the primitive wrapper classes, and BigInteger and BigDecimal都是不变类。

如果一个类是不变类，这个类是不是就不能有改变状态的方法呢？

答案当然是否定的，String是一个不变类，仍然有replace，replaceAll这样的方法，而String仍然是一个不变类，那是因为在这些改变状态的方法中，每次都是新创建一个String对象。

如果大家理解了不变类，那也就不难理解为什么在做String的concatenate时，应当用StringBuffer而不是用+的操作符。

如何正确使用String呢?

1）
不要用new去创建String对象。

如果使用new去创建String，那么每次都会创建一个新对象。

public static void main(String[] args) {

String A1 = “A”;

String A2 = “A”; // It won’t create a new object

checkInstance(A1, A2); // Result: They are same instances

String B1 = new String(“A”); // create a new object

String B2 = new String(“A”); // creat a new object

checkInstance(B1, B2); // Result: They are different instances

}

private static void checkInstance(String a1, String a2) {

if (a1 == a2) {

System.out.println(“They are same instances”);

} else {

System.out.println(“They are different instances”);

}

2）
应当用StringBuffer来做连接操作

因为String是一个不变类，那么在做连接操作时，就会创建临时对象来保存中间的运算结果，而StringBuffer是一个mutable class,这样就不需要创建临时的对象来保存结果，从而提高了性能。

JAVA Garbage Collection (Vincent)

垃圾分代回收算法（Generational Collecting）
基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。

如上图所示，为Java堆中的各代分布。
1. Young（年轻代）JVM specification中的 Heap的一部份

年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制年老区(Tenured);。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。
2. Tenured（年老代）JVM specification中的 Heap的一部份

年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
3. Perm（持久代） JVM specification中的 Method area
用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

采用分区管理机制的JVM将JVM所管理的所有内存资源分为2个大的部分。永久存储区（Permanent Space）和堆空间（The Heap Space）。其中堆空间又分为新生区（Young (New) generation space）和养老区（Tenure (Old) generation space），新生区又分为伊甸园（Eden space），幸存者0区（Survivor 0 space）和幸存者1区（Survivor 1 space）。具体分区如下图：

那JVM他的这些分区各有什么用途，请看下面的解说。
永久存储区（Permanent Space）：永久存储区是JVM的驻留内存，用于存放JDK自身所携带的Class,Interface的元数据，应用服务器允许必须的Class,Interface的元数据和Java程序运行时需要的Class和Interface的元数据。被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM时，释放此区域所控制的内存。

堆空间（The Heap Space）：是JAVA对象生死存亡的地区，JAVA对象的出生，成长，死亡都在这个区域完成。堆空间又分别按JAVA对象的创建和年龄特征分为养老区和新生区。

新生区（Young (New) generation space）：新生区的作用包括JAVA对象的创建和从JAVA对象中筛选出能进入养老区的JAVA对象。

伊甸园（Eden space）：JAVA对空间中的所有对象在此出生，该区的名字因此而得名。也即是说当你的JAVA程序运行时，需要创建新的对象，JVM将在该区为你创建一个指定的对象供程序使用。创建对象的依据即是永久存储区中的元数据。

幸存者0区（Survivor 0 space）和幸存者1区（Survivor1 space）：当伊甸园的空间用完时，程序又需要创建对象；此时JVM的垃圾回收器将对伊甸园区进行垃圾回收，将伊甸园区中的不再被其他对象所引用的对象进行销毁工作。同时将伊甸园中的还有其他对象引用的对象移动到幸存者0区。幸存者0区就是用于存放伊甸园垃圾回收时所幸存下来的JAVA对象。当将伊甸园中的还有其他对象引用的对象移动到幸存者0区时，如果幸存者0区也没有空间来存放这些对象时，JVM的垃圾回收器将对幸存者0区进行垃圾回收处理，将幸存者0区中不在有其他对象引用的JAVA对象进行销毁，将幸存者0区中还有其他对象引用的对象移动到幸存者1区。幸存者1区的作用就是用于存放幸存者0区垃圾回收处理所幸存下来的JAVA对象。

养老区（Tenure (Old) generation space）：用于保存从新生区筛选出来的JAVA对象。
上面我们看了JVM的内存分区管理，现在我们来看JVM的垃圾回收工作是怎样运作的。首先当启动J2EE应用服务器时，JVM随之启动，并将JDK的类和接口，应用服务器运行时需要的类和接口以及J2EE应用的类和接口定义文件也及编译后的Class文件或JAR包中的Class文件装载到JVM的永久存储区。在伊甸园中创建JVM，应用服务器运行时必须的JAVA对象，创建J2EE应用启动时必须创建的JAVA对象；J2EE应用启动完毕，可对外提供服务。
JVM在伊甸园区根据用户的每次请求创建相应的JAVA对象，当伊甸园的空间不足以用来创建新JAVA对象的时候，JVM的垃圾回收器执行对伊甸园区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到幸存者0区。
如果幸存者0区有足够控件存放则直接放到幸存者0区；如果幸存者0区没有足够空间存放，则JVM的垃圾回收器执行对幸存者0区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到幸存者1区。
如果幸存者1区有足够控件存放则直接放到幸存者1区；如果幸存者0区没有足够空间存放，则JVM的垃圾回收器执行对幸存者0区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到养老区。
如果养老区有足够控件存放则直接放到养老区；如果养老区没有足够空间存放，则JVM的垃圾回收器执行对养老区区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并保留那些被其他对象所引用的JAVA对象。如果到最后养老区，幸存者1区，幸存者0区和伊甸园区都没有空间的话，则JVM会报告”JVM堆空间溢出（java.lang.OutOfMemoryError: Java heap space）”，也即是在堆空间没有空间来创建对象。
这就是JVM的内存分区管理，相比不分区来说；一般情况下，垃圾回收的速度要快很多；因为在没有必要的时候不用扫描整片内存而节省了大量时间。
通常大家还会遇到另外一种内存溢出错误”永久存储区溢出（java.lang.OutOfMemoryError: Java Permanent Space）”。

所有的垃圾收集算法都面临同一个问题，那就是找出应用程序不可到达的内存块，将其释放，这里面得不可到达主要是指应用程序已经没有内存块的引用了，而在JAVA中，某个对象对应用程序是可到达的是指：这个对象被根（根主要是指类的静态变量，或者活跃在所有线程栈的对象的引用）引用或者对象被另一个可到达的对象引用。

Reference Counting(引用计数）

引用计数是最简单直接的一种方式，这种方式在每一个对象中增加一个引用的计数，这个计数代表当前程序有多少个引用引用了此对象，如果此对象的引用计数变为0，那么此对象就可以作为垃圾收集器的目标对象来收集。

优点：

简单，直接，不需要暂停整个应用

缺点：

1.需要编译器的配合，编译器要生成特殊的指令来进行引用计数的操作，比如每次将对象赋值给新的引用，或者者对象的引用超出了作用域等。

2.不能处理循环引用的问题

跟踪收集器

跟踪收集器首先要暂停整个应用程序，然后开始从根对象扫描整个堆，判断扫描的对象是否有对象引用，这里面有三个问题需要搞清楚：

1．如果每次扫描整个堆，那么势必让GC的时间变长，从而影响了应用本身的执行。因此在JVM里面采用了分代收集，在新生代收集的时候minor gc只需要扫描新生代，而不需要扫描老生代。

2．JVM采用了分代收集以后，minor gc只扫描新生代，但是minor gc怎么判断是否有老生代的对象引用了新生代的对象，JVM采用了卡片标记的策略，卡片标记将老生代分成了一块一块的，划分以后的每一个块就叫做一个卡片，JVM采用卡表维护了每一个块的状态，当JAVA程序运行的时候，如果发现老生代对象引用或者释放了新生代对象的引用，那么就JVM就将卡表的状态设置为脏状态，这样每次minor gc的时候就会只扫描被标记为脏状态的卡片，而不需要扫描整个堆。具体如下图：

3．GC在收集一个对象的时候会判断是否有引用指向对象，在JAVA中的引用主要有四种：Strong reference,Soft reference,Weak reference,Phantom reference.

Strong Reference

强引用是JAVA中默认采用的一种方式，我们平时创建的引用都属于强引用。如果一个对象没有强引用，那么对象就会被回收。

public void testStrongReference(){

Object referent = new Object();

Object strongReference = referent;

referent = null;

System.gc();

assertNotNull(strongReference);

}

Soft Reference

软引用的对象在GC的时候不会被回收，只有当内存不够用的时候才会真正的回收，因此软引用适合缓存的场合，这样使得缓存中的对象可以尽量的再内存中待长久一点。

Public void testSoftReference(){

String str = “test”;

SoftReference<String> softreference = new SoftReference<String>(str);

str=null;

System.gc();

assertNotNull(softreference.get());

}

Weak reference

弱引用有利于对象更快的被回收，假如一个对象没有强引用只有弱引用，那么在GC后，这个对象肯定会被回收。

Public void testWeakReference(){

String str = “test”;

WeakReference<String> weakReference = new WeakReference<String>(str);

str=null;

System.gc();

assertNull(weakReference.get());

}

Phantom reference

Mark-Sweep Collector(标记–清除收集器）

标记清除收集器最早由Lisp的发明人于1960年提出，标记清除收集器停止所有的工作，从根扫描每个活跃的对象，然后标记扫描过的对象，标记完成以后，清除那些没有被标记的对象。

优点：

1 解决循环引用的问题

2 不需要编译器的配合，从而就不执行额外的指令

缺点：

1．每个活跃的对象都要进行扫描，收集暂停的时间比较长。

Copying Collector(复制收集器）

复制收集器将内存分为两块一样大小空间，某一个时刻，只有一个空间处于活跃的状态，当活跃的空间满的时候，GC就会将活跃的对象复制到未使用的空间中去，原来不活跃的空间就变为了活跃的空间。

复制收集器具体过程可以参考下图：

优点：

1 只扫描可以到达的对象，不需要扫描所有的对象，从而减少了应用暂停的时间

缺点：

1．需要额外的空间消耗，某一个时刻，总是有一块内存处于未使用状态

2．复制对象需要一定的开销

Mark-Compact Collector(标记–整理收集器）

标记整理收集器汲取了标记清除和复制收集器的优点，它分两个阶段执行，在第一个阶段，首先扫描所有活跃的对象，并标记所有活跃的对象，第二个阶段首先清除未标记的对象，然后将活跃的的对象复制到堆得底部。标记整理收集器的过程示意图请参考下图：

Mark-compact策略极大的减少了内存碎片，并且不需要像Copy Collector一样需要两倍的空间。

JVM的垃圾收集策略

GC的执行时要耗费一定的CPU资源和时间的，因此在JDK1.2以后，JVM引入了分代收集的策略，其中对新生代采用“Mark-Compact”策略，而对老生代采用了”Mark-Sweep”的策略。其中新生代的垃圾收集器命名为”minor gc“，老生代的GC命名为“Full Gc 或者Major GC”.其中用System.gc()强制执行的是Full Gc.

Spring IOC and AOP(Minjin)

IoC和AOP都是Spring的核心思想

当然，最为一个框架级的轻量组件，大量的配置文件是不可缺少的，但是核心是要把这些配置文件，配置节组装起来，并将核心代码编写为完全业务无关的。我们看看Spring是怎么做的。

首先，IoC，控制反转。Spring 开发的基本思想：面向接口的编程模式。框架做的越多，应该越能发现接口在其中起到的作用，而Spring将这种想法，开始贯彻到业务的开发中了。Bean 的Set方法使用接口作为参数，保证其扩展性，实现依赖关系的松偶尔。所谓的控制反转，作为中文更好理解的一个翻译应该是依赖注入，把依赖的类采用接口的方式，利用Set函数，传入Bean的内部，实现与外界的解耦合。这种注入也可作用于构造函数。

其次，AOP，面向切面的编程方式，我觉得更通俗的说法应该是对容器内的Bean进行方法干涉。被容器中创建的类，看起来执行一个普通的函数调用，因为被容器预处理，而会在方法执行前/后进行一些其他的、可配置的操作。当然，这种方法也同样是面向接口的，或者直接使用反射的。利用java.lang.reflect.InvocationHandler接口可以达到这种干涉的效果。下面是转载的一个简单示例。

Java代码

import java.lang.reflect.InvocationHandler;

import java.lang.reflect.Method;

import java.lang.reflect.Proxy;

public class DynaProxyHello implements InvocationHandler

{

private Object proxy;

private Object delegate;

public Object bind(Object delegate,Object proxy) {

this.proxy = proxy;

this.delegate = delegate;

return Proxy.newProxyInstance(

this.delegate.getClass().getClassLoader(), this.delegate

.getClass().getInterfaces(), this);

public Object invoke(Object proxy, Method method, Object[] args)

throws Throwable {

Object result = null;

try {

//反射得到操作者的实例

Class clazz = this.proxy.getClass();

//反射得到操作者的Start方法

Method start = clazz.getDeclaredMethod(“start”,

new Class[] { Method.class });

//反射执行start方法

start.invoke(this.proxy, new Object[] { method });

//执行要处理对象的原本方法

result = method.invoke(this.delegate, args);

// 反射得到操作者的end方法

Method end = clazz.getDeclaredMethod(“end”,

new Class[] { Method.class });

// 反射执行end方法

end.invoke(this.proxy, new Object[] { method });

} catch (Exception e) {

e.printStackTrace();

}

return result;

}

public class Test {

public static void main(String[] args) {

IHello hello = (IHello)new DynaProxyHello().bind(new Hello(),new LoggerOperation());

hello.sayGoogBye(“Double J”);

hello.sayHello(“Double J”);

}

import java.lang.reflect.InvocationHandler;

2. 4 import java.lang.reflect.Method;

3. 5 import java.lang.reflect.Proxy;

4. 6

5. 7 public class DynaProxyHello implements InvocationHandler {

6. 8

7.11 private Object proxy;

8.12

9.15 private Object delegate;

10.16

11.17

12.24 public Object bind(Object delegate,Object proxy) {

13.25

14.26 this.proxy = proxy;

15.27 this.delegate = delegate;

16.28 return Proxy.newProxyInstance(

17.29 this.delegate.getClass().getClassLoader(), this.delegate

18.30 .getClass().getInterfaces(), this);

19.31 }

20.32

21.36 public Object invoke(Object proxy, Method method, Object[] args)

22.37 throws Throwable {

23.38 Object result = null;

24.39 try {

25.40 //反射得到操作者的实例

26.41 Class clazz = this.proxy.getClass();

27.42 //反射得到操作者的Start方法

28.43 Method start = clazz.getDeclaredMethod(“start”,

29.44 new Class[] { Method.class });

30.45 //反射执行start方法

31.46 start.invoke(this.proxy, new Object[] { method });

32.47 //执行要处理对象的原本方法

result = method.invoke(this.delegate, args);

// 反射得到操作者的end方法

Method end = clazz.getDeclaredMethod(“end”,

new Class[] { Method.class });

// 反射执行end方法

end.invoke(this.proxy, new Object[] { method });

} catch (Exception e) {

e.printStackTrace();

}

return result;

}

public class Test {

public static void main(String[] args) {

IHello hello = (IHello)new DynaProxyHello().bind(new Hello(),new LoggerOperation());

hello.sayGoogBye(“Double J”);

hello.sayHello(“Double J”);

}

当然，不是只有这一个实现方式，java的代理功能只能代理接口，如果要代理类的化，可以使用cglib。

Spring框架当然不会是上述的那么简单（实际上它非常复杂），不过我关注的是核心的实现方式和设计思想。在有些时候，我们不需要使用Spring，甚至不能使用Spring（比如不用Java开发），但是这种思想和方式是可以复用的。使用这种设计思想，按照当前的语言和环境要求，实现自己的IoC和 AOP框架。

Spring框架 (Minjin)

Spring 框架是一个分层架构，由 7 个定义良好的模块组成。Spring 模块构建在核心容器之上，核心容器定义了创建、配置和管理 bean 的方式，如图 1 所示。

图 1. Spring 框架的 7 个模块

组成 Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下：

核心容器：核心容器提供 Spring 框架的基本功能。核心容器的主要组件是
BeanFactory，它是工厂模式的实现。BeanFactory
使用控制反转
（IOC）
模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。
Spring 上下文：Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、校验和调度功能。
Spring AOP：通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何对象支持 AOP。Spring AOP 模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。
Spring DAO：JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向 JDBC 的异常遵从通用的 DAO 异常层次结构。
Spring ORM：Spring 框架插入了若干个 ORM 框架，从而提供了 ORM 的对象关系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。
Spring Web 模块：Web 上下文模块建立在应用程序上下文模块之上，为基于 Web 的应用程序提供了上下文。所以，Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。
Spring MVC 框架：MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText 和 POI。

Spring 框架的功能可以用在任何 J2EE 服务器中，大多数功能也适用于不受管理的环境。Spring 的核心要点是：支持不绑定到特定 J2EE 服务的可重用业务和数据访问对象。毫无疑问，这样的对象可以在不同 J2EE 环境
（Web 或 EJB）、独立应用程序、测试环境之间重用。

Spring AOP两种实现机制 (Baoming Chai)

SPRING是通过动态代理来实现AOP的,SPRING内部提供了2种实现机制
1.如果是有接口声明的类进行AOP,spring调用的是java.lang.reflection.Proxy类来做处理

org.springframework.aop.framework.JdkDynamicAopProxy

public Object getProxy(ClassLoader classLoader) {

if (logger.isDebugEnabled()) {

Class targetClass = this.advised.getTargetSource().getTargetClass();

logger.debug(“Creating JDK dynamic proxy” +

(targetClass != null ? ” for [” + targetClass.getName() + “]” : “”));

}

Class[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised);

return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);

}

org.springframework.aop.framework.ReflectiveMethodInvocation

public Object proceed() throws Throwable {

// We start with an index of -1 and increment early.

if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() – 1) {

return invokeJoinpoint();

}

Object interceptorOrInterceptionAdvice =

this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);

if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {

// evaluate dynamic method matcher here: static part will already have

// been evaluated and found to match.

InterceptorAndDynamicMethodMatcher dm =

(InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;

if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {

return dm.interceptor.invoke(this);

}

else {

// Dynamic matching failed.

// Skip this interceptor and invoke the next in the chain.

return proceed();

}

else {

// It’s an interceptor, so we just invoke it: The pointcut will have

// been evaluated statically before this object was constructed.

return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);

}

2.如果是没有接口声明的类呢?SPRING通过CGLIB包和内部类来实现

private static class StaticUnadvisedInterceptor implements MethodInterceptor, Serializable {

private final Object target;

public StaticUnadvisedInterceptor(Object target) {

this.target = target;

}

public Object intercept(Object proxy, Method method, Object[] args,

MethodProxy methodProxy) throws Throwable {

Object retVal = methodProxy.invoke(target, args);

return massageReturnTypeIfNecessary(proxy, target, retVal);

}

private static class StaticUnadvisedExposedInterceptor implements MethodInterceptor, Serializable {

private final Object target;

public StaticUnadvisedExposedInterceptor(Object target) {

this.target = target;

}

public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {

Object oldProxy = null;

try {

oldProxy = AopContext.setCurrentProxy(proxy);

Object retVal = methodProxy.invoke(target, args);

return massageReturnTypeIfNecessary(proxy, target, retVal);

}

finally {

AopContext.setCurrentProxy(oldProxy);

}

private class DynamicUnadvisedInterceptor implements MethodInterceptor, Serializable {

public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {

Object target = advised.getTargetSource().getTarget();

try {

Object retVal = methodProxy.invoke(target, args);

return massageReturnTypeIfNecessary(proxy, target, retVal);

}

finally {

advised.getTargetSource().releaseTarget(target);

}

private class DynamicUnadvisedExposedInterceptor implements MethodInterceptor, Serializable {

public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {

Object oldProxy = null;

Object target = advised.getTargetSource().getTarget();

try {

oldProxy = AopContext.setCurrentProxy(proxy);

Object retVal = methodProxy.invoke(target, args);

return massageReturnTypeIfNecessary(proxy, target, retVal);

}

finally {

AopContext.setCurrentProxy(oldProxy);

advised.getTargetSource().releaseTarget(target);

}

我们自己也可以来试试
1.jdk proxy方式

先来一个接口
IHelloWorld.java

package kris.aop.test;

public interface IHelloWorld {

public void print(String name);

public void write(String sth);

}

再来一个实现

HelloWorld.java

package kris.aop.test;

public class HelloWorld implements IHelloWorld {

public void print(String name){

System.out.println(“HelloWorld “+name);

}

public void write(String sth) {

System.out.println(“write “+sth);

}

代理类

DefaultInvocationHandler.java

package kris.aop.test;

import java.lang.reflect.InvocationHandler;

import java.lang.reflect.Method;

public class DefaultInvocationHandler implements InvocationHandler {

public Object invoke(Object obj, Method method, Object[] args)

throws Throwable {

String s1 []={“kris”};

String s2 []={“anyone”};

IHelloWorld ihw=new HelloWorld();

System.out.println(“start!”);

method.invoke(ihw,args);

method.invoke(ihw,s1);

Object o=method.invoke(ihw,s2);

System.out.println(“stop!”);

return o;

}

测试类
Test.java

package kris.aop.test;

import java.lang.reflect.InvocationHandler;

import java.lang.reflect.Proxy;

public class Test {

public static void main(String args []){

Class clazz = new HelloWorld().getClass();

ClassLoader cl = clazz.getClassLoader();

Class classes [] = clazz.getInterfaces();

InvocationHandler ih=new DefaultInvocationHandler();

//用InvocationHandler给HelloWorld进行AOP包装

IHelloWorld ihw=(IHelloWorld) Proxy.newProxyInstance(cl,classes,ih);

ihw.print(“test”);

ihw.write(“test”);

}

2.用CGLIB包实现,首先不要忘了引入那个包

package kris.aop.cglib.test;

public class HelloWorld {

public void print(String name){

System.out.println(“HelloWorld “+name);

}

public void write(String sth) {

System.out.println(“write “+sth);

}

public void print(){

System.out.println(“HelloWorld”);

}

代理类(没用内部类,看起来清楚点)

package kris.aop.cglib.test;

import java.lang.reflect.Method;

import net.sf.cglib.proxy.MethodInterceptor;

import net.sf.cglib.proxy.MethodProxy;

public class MethodInterceptorImpl implements MethodInterceptor {

public Object intercept(Object obj, Method method, Object[] args,

MethodProxy proxy) throws Throwable {

System.out.println(method);

proxy.invokeSuper(obj, args);

return null;

}

测试类

package kris.aop.cglib.test;

import net.sf.cglib.proxy.Enhancer;

public class Test {

public static void main(String[] args) {

Enhancer enhancer = new Enhancer();

enhancer.setSuperclass(HelloWorld.class);

//设置回调方法实现类

enhancer.setCallback(new MethodInterceptorImpl());

//实例化已经添加回调实现的HELLOWORLD实例

HelloWorld my = (HelloWorld) enhancer.create();

my.print();

}

Spring AOP的底层实现技术(Baoming Chai, Stephen Yu)

AOP概述

软件的编程语言最终的目的就是用更自然更灵活的方式模拟世界，从原始机器语言到过程语言再到面向对象的语言，我们看到编程语言在一步步用更自然、更强大的方式描述软件。AOP是软件开发思想的一个飞跃，AOP的引入将有效弥补OOP的不足，OOP和AOP分别从纵向和横向对软件进行抽象，有效地消除重复性的代码，使代码以更优雅的更有效的方式进行逻辑表达。

AOP有三种植入切面的方法：其一是编译期织入，这要求使用特殊的Java编译器，AspectJ是其中的代表者；其二是类装载期织入，而这要求使用特殊的类装载器，AspectJ和AspectWerkz是其中的代表者；其三为动态代理织入，在运行期为目标类添加增强生成子类的方式，Spring AOP采用动态代理织入切面。

Spring AOP使用了两种代理机制，一种是基于JDK的动态代理，另一种是基于CGLib的动态代理，之所以需要两种代理机制，很大程度上是因为JDK本身只提供基于接口的代理，不支持类的代理。

基于JDK的代理和基于CGLib的代理是Spring AOP的核心实现技术，认识这两代理技术，有助于探究Spring AOP的实现机理。只要你愿意，你甚至可以抛开Spring，提供自己的AOP实现。

带有横切逻辑的实例

首先，我们来看一个无法通过OOP进行抽象的重复代码逻辑，它们就是AOP改造的主要对象。下面，我们通过一个业务方法性能监视的实例了解横切逻辑。业务方法性能监视，在每一个业务方法调用之前开始监视，业务方法结束后结束监视并给出性能报告：

代码清单 2 ForumService：包含性能监视横切代码

package com.baobaotao.proxy;
public class ForumServiceImpl implements ForumService …{

public void removeTopic(int topicId) …{
          //开始性能监视
PerformanceMonitor.begin(“com.baobaotao.proxy.ForumServiceImpl.removeTopic”);
System.out.println(“模拟删除Topic记录:”+topicId);
try …{
   Thread.currentThread().sleep(20);
} catch (Exception e) …{
   throw new RuntimeException(e);
}
//结束监视、并给出性能报告信息
PerformanceMonitor.end();
}

public void removeForum(int forumId) …{
//开始性能监视
PerformanceMonitor.begin(“com.baobaotao.proxy.ForumServiceImpl.removeForum”);
System.out.println(“模拟删除Forum记录:”+forumId);
try …{
   Thread.currentThread().sleep(40);
} catch (Exception e) …{
   throw new RuntimeException(e);
}
         //结束监视、并给出性能报告信息
PerformanceMonitor.end();
}
}

代码清单 2中粗体表示的代码就是具有横切特征的代码，需要进行性能监视的每个业务方法的前后都需要添加类似的性能监视语句。

我们保证实例的完整性，我们提供了一个非常简单的性能监视实现类，如所示代码清单 3所示：

代码清单 3 PerformanceMonitor

package com.baobaotao.proxy;

public class PerformanceMonitor {
//通过一个ThreadLocal保存线程相关的性能监视信息
private static ThreadLocal<MethodPerformace> performaceRecord =
new ThreadLocal<MethodPerformace>();
public static void begin(String method) {
System.out.println(“begin monitor…”);
MethodPerformace mp = new MethodPerformace(method);
performaceRecord.set(mp);
}
public static void end() {
System.out.println(“end monitor…”);
MethodPerformace mp = performaceRecord.get();
mp.printPerformace(); //打印出业务方法性能监视的信息
}
}

PerformanceMonitor提供了两个方法，begin(String method)方法开始对某个业务类方法的监视，method为业务方法的签名，而end()方法结束对业务方法的监视，并给出性能监视的信息。由于每一个业务方法都必须单独记录性能监视数据，所以我们使用了ThreadLocal，ThreadLocal是削除非线程安全状态的不二法宝。ThreadLocal中的元素为方法性能记录对象MethodPerformace，它的代码如下所示：

代码清单 4 MethodPerformace

package com.baobaotao.proxy;
public class MethodPerformace {
private long begin;
private long end;
private String serviceMethod;
    public MethodPerformace(String serviceMethod){
       this.serviceMethod = serviceMethod;
       this.begin = System.currentTimeMillis();//记录方法调用开始时的系统时间
    }
    public void printPerformace(){
        //以下两行程序得到方法调用后的系统时间，并计算出方法执行花费时间
        end = System.currentTimeMillis();
        long elapse = end – begin;
        //报告业务方法执行时间
        System.out.println(serviceMethod+”花费”+elapse+”毫秒。”);
    }
}

通过下面代码测试这个拥有方法性能监视能力的业务方法：

package com.baobaotao.proxy;
public class TestForumService {
public static void main(String[] args) {
        ForumService forumService = new ForumServiceImpl();
        forumService .removeForum(10);
    forumService .removeTopic(1012);
}
}

我们得到以下的输出信息：

begin monitor…
模拟删除Forum记录:10
end monitor…
com.baobaotao.proxy.ForumServiceImpl.removeForum花费47毫秒。

begin monitor…
模拟删除Topic记录:1012
end monitor…
com.baobaotao.proxy.ForumServiceImpl.removeTopic花费16毫秒。

如实例所示，要对业务类进行性能监视，就必须在每个业务类方法的前后两处添加上重复性的开启性能监视和结束性能监视的代码。这些非业务逻辑的性能监视代码破坏了作为业务类ForumServiceImpl的纯粹性。下面，我们分别JDK动态代理和CGLib动态代理技术，将业务方法中开启和结束性能监视的这些横切代码从业务类中完成移除。

JDK动态代理

在JDK 1.3以后提供了动态代理的技术，允许开发者在运行期创建接口的代理实例。在Sun刚推出动态代理时，还很难想象它有多大的实际用途，现在我们终于发现动态代理是实现AOP的绝好底层技术。

JDK的动态代理主要涉及到java.lang.reflect包中的两个类：Proxy和InvocationHandler。其中InvocationHandler是一个接口，可以通过实现该接口定义横切逻辑，在并通过反射机制调用目标类的代码，动态将横切逻辑和业务逻辑编织在一起。

而Proxy为InvocationHandler实现类动态创建一个符合某一接口的代理实例。这样讲一定很抽象，我们马上着手动用Proxy和InvocationHandler这两个魔法戒对上一节中的性能监视代码进行AOP式的改造。

首先，我们从业务类ForumServiceImpl 中删除性能监视的横切代码，使ForumServiceImpl只负责具体的业务逻辑，如所示：

代码清单 5 ForumServiceImpl：移除性能监视横切代码

package com.baobaotao.proxy;
public class ForumServiceImpl implements ForumService {
public void removeTopic(int topicId) {
         ①
System.out.println(“模拟删除Topic记录:”+topicId);
try {
   Thread.currentThread().sleep(20);
} catch (Exception e) {
   throw new RuntimeException(e);
}
   ②
}
public void removeForum(int forumId) {
         ①
System.out.println(“模拟删除Forum记录:”+forumId);
try {
   Thread.currentThread().sleep(40);
} catch (Exception e) {
   throw new RuntimeException(e);
}
         ②
}
}

在代码清单 5中的①和②处，原来的性能监视代码被移除了，我们只保留了真正的业务逻辑。

从业务类中移除的横切代码当然还得找到一个寄居之所，InvocationHandler就是横切代码的家园乐土，我们将性能监视的代码安置在PerformaceHandler中，如代码清单 6所示：

代码清单 6 PerformaceHandler

package com.baobaotao.proxy;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class PerformaceHandler implements InvocationHandler {
private Object target;
public PerformaceHandler(Object target){//①target为目标的业务类
this.target = target;
}
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
PerformanceMonitor.begin(target.getClass().getName()+”.”+ method.getName());
Object obj = method.invoke(target, args);//②通过反射方法调用目标业务类的业务方法
PerformanceMonitor.end();
return obj;
}
}

粗体部分的代码为性能监视的横切代码，我们发现，横切代码只出现一次，而不是原来那样星洒各处。大家注意②处的method.invoke()，该语句通过反射的机制调用目标对象的方法，这样InvocationHandler的invoke(Object proxy, Method method, Object[] args)方法就将横切代码和目标业务类代码编织到一起了，所以我们可以将InvocationHandler看成是业务逻辑和横切逻辑的编织器。下面，我们对这段代码做进一步的说明。

首先，我们实现InvocationHandler接口，该接口定义了一个 invoke(Object proxy, Method method, Object[] args)的方法，proxy是代理实例，一般不会用到；method是代理实例上的方法，通过它可以发起对目标类的反射调用；args是通过代理类传入的方法参数，在反射调用时使用。

此外，我们在构造函数里通过target传入真实的目标对象，如①处所示，在接口方法invoke(Object proxy, Method method, Object[] args)里，将目标类实例传给method.invoke()方法，通过反射调用目标类方法，如②所示。

下面，我们通过Proxy结合PerformaceHandler创建ForumService接口的代理实例，如代码清单 7所示：

代码清单 7 TestForumService：创建代理实例

package com.baobaotao.proxy;
import java.lang.reflect.Proxy;
public class TestForumService {
public static void main(String[] args) {
ForumService target = new ForumServiceImpl();//①目标业务类
//② 将目标业务类和横切代码编织到一起
PerformaceHandler handler = new PerformaceHandler(target);
         //③为编织了目标业务类逻辑和性能监视横切逻辑的handler创建代理类
ForumService proxy = (ForumService) Proxy.newProxyInstance(
target.getClass().getClassLoader(),
    target.getClass().getInterfaces(),
handler);
         //④ 操作代理实例
proxy.removeForum(10);
proxy.removeTopic(1012);
}
}

上面的代码完成了业务类代码和横切代码编织和接口代理实例生成的工作，其中在②处，我们将ForumService实例编织为一个包含性能监视逻辑的PerformaceHandler实例，然后在③处，通过Proxy的静态方法newProxyInstance()为融合了业务类逻辑和性能监视逻辑的handler创建一个ForumService接口的代理实例，该方法的第一个入参为类加载器，第二个入参为创建的代理实例所要实现的一组接口，第三个参数是整合了业务逻辑和横切逻辑的编织器对象。

按照③处的设置方式，这个代理实例就实现了目标业务类的所有接口，也即ForumServiceImpl的ForumService接口。这样，我们就可以按照调用ForumService接口的实例相同的方式调用代理实例，如④所示。运行以上的代码，输出以下的信息：

begin monitor…
模拟删除Forum记录:10
end monitor…
com.baobaotao.proxy.ForumServiceImpl.removeForum花费47毫秒。

begin monitor…
模拟删除Topic记录:1012
end monitor…
com.baobaotao.proxy.ForumServiceImpl.removeTopic花费26毫秒。

我们发现，程序的运行效果和直接在业务类中编写性能监视逻辑的效果一致，但是在这里，原来分散的横切逻辑代码已经被我们抽取到PerformaceHandler中。当其它业务类（如UserService、SystemService等）的业务方法也需要使用性能监视时，我们只要按照以上的方式，分别为它们创建代理对象就可以了。下面，我们用时序图描述调用关系，进一步代理实例的本质，如图1所示：

图1：代理实例的时序图

我们在上图中特别使用虚线阴影的方式对通过代理器创建的ForumService实例进行凸显，该实例内部利用PerformaceHandler整合横切逻辑和业务逻辑。调用者调用代理对象的的removeForum()和removeTopic()方法时，上图的内部调用时序清晰地告诉了我们实际上所发生的一切。

CGLib动态代理

使用JDK创建代理有一个限制，即它只能为接口创建代理，这一点我们从Proxy的接口方法newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h)就看得很清楚，第三个入参interfaces就是为代理实例指定的实现接口。虽然，面向接口的编程被很多很有影响力人（包括Rod Johnson）的推崇，但在实际开发中，开发者也遇到了很多困惑：难道对一个简单业务表的操作真的需要创建5个类（领域对象类、Dao接口，Dao实现类，Service接口和Service实现类）吗？对于这一问题，我们还是留待大家进一步讨论。现在的问题是：对于没有通过接口定义业务方法的类，如何动态创建代理实例呢？JDK的代理技术显然已经黔驴技穷，CGLib作为一个替代者，填补了这个空缺。你可以从http://cglib.sourceforge.net/获取CGLib的类包，也可以直接从Spring的关联类库lib/cglib中获取类包。

CGLib采用非常底层的字节码技术，可以为一个类创建子类，并在子类中采用方法拦截的技术拦截所有父类方法的调用，并在拦截方法相应地织入横切逻辑。下面，我们采用CGLib技术，编写一个可以为任何类创建织入性能监视横切逻辑的代理对象的代理器，如代码清单 8所示：

代码清单 8 CglibProxy

package com.baobaotao.proxy;
import java.lang.reflect.Method;
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

public class CglibProxy implements MethodInterceptor {
private Enhancer enhancer = new Enhancer();
public Object getProxy(Class clazz) {
enhancer.setSuperclass(clazz); ① 设置需要创建子类的类
enhancer.setCallback(this);
return enhancer.create(); ②通过字节码技术动态创建子类实例
}
public Object intercept(Object obj, Method method, Object[] args,
MethodProxy proxy) throws Throwable {
PerformanceMonitor.begin(obj.getClass().getName()+”.”+method.getName());
Object result=proxy.invokeSuper(obj, args); ③ 通过代理类调用父类中的方法
PerformanceMonitor.end();
return result;
}
}

在上面代码中，你可以通过getProxy(Class clazz)为一个类创建动态代理对象，该代理对象是指定类clazz的子类。在这个代理对象中，我们织入性能监视的横切逻辑（粗体部分）。intercept(Object obj, Method method, Object[] args,MethodProxy proxy)是CGLib定义的Inerceptor接口的方法，obj表示父类的实例，method为父类方法的反射对象，args为方法的动态入参，而proxy为代理类实例。

下面，我们通过CglibProxy为ForumServiceImpl类创建代理对象，并测试代理对象的方法，如代码清单 9所示：

代码清单 9 TestForumService：测试Cglib创建的代理类

package com.baobaotao.proxy;
import java.lang.reflect.Proxy;
public class TestForumService {
public static void main(String[] args) {
   CglibProxy proxy = new CglibProxy();
   ForumServiceImpl forumService = //① 通过动态生成子类的方式创建代理对象
(ForumServiceImpl )proxy.getProxy(ForumServiceImpl.class);
   forumService.removeForum(10);
   forumService.removeTopic(1023);
}
}

在①中，我们通过CglibProxy为ForumServiceImpl动态创建了一个织入性能监视逻辑的代理对象，并调用了代理对象的业务方法。运行上面的代码，输入以下的信息：

begin monitor…
模拟删除Forum记录:10
end monitor…
com.baobaotao.proxy.ForumServiceImpl$$EnhancerByCGLIB$$2a9199c0.removeForum花费47毫秒。
begin monitor…
模拟删除Topic记录:1023
end monitor…
com.baobaotao.proxy.ForumServiceImpl$$EnhancerByCGLIB$$2a9199c0.removeTopic花费16毫秒。

观察以上的输出，除了发现两个业务方法中都织入了性能监控的逻辑外，我们还发现代理类的名字是com.baobaotao.proxy.ForumServiceImpl$$EnhancerByCGLIB$$2a9199c0，这个特殊的类就是CGLib为ForumServiceImpl所动态创建的子类。

小结

Spring AOP在底层就是利用JDK动态代理或CGLib动态代理技术为目标Bean织入横切逻辑。在这里，我们对以上两节动态创建代理对象做一个小结。

在PerformaceHandler和CglibProxy中，有三点值得注意的地方是：第一，目标类的所有方法都被添加了性能监视横切的代码，而有时，这并不是我们所期望的，我们可能只希望对业务类中的某些方法织入横切代码；第二，我们手工指定了织入横切代码的织入点，即在目标类业务方法的开始和结束前调用；第三，我们手工编写横切代码。以上三个问题，在AOP中占用重要的地位，因为Spring AOP的主要工作就是围绕以上三点展开：Spring AOP通过Pointcut（切点）指定在哪些类的哪些方法上施加横切逻辑，通过Advice（增强）描述横切逻辑和方法的具体织入点（方法前、方法后、方法的两端等），此外，Spring还通过Advisor（切面）组合Pointcut和Advice。有了Advisor的信息，Spring就可以利用JDK或CGLib的动态代理技术为目标Bean创建织入切面的代理对象了。

JDK动态代理所创建的代理对象，在JDK 1.3下，性能强差人意。虽然在高版本的JDK中，动态代理对象的性能得到了很大的提高，但是有研究表明，CGLib所创建的动态代理对象的性能依旧比JDK的所创建的代理对象的性能高不少（大概10倍）。而CGLib在创建代理对象时性能却比JDK动态代理慢很多（大概8倍），所以对于singleton的代理对象或者具有实例池的代理，因为不需要频繁创建代理对象，所以比较适合用CGLib动态代理技术，反之适合用JDK动态代理技术。此外，由于CGLib采用生成子类的技术创建代理对象，所以不能对目标类中的final方法进行代理。

Java String

Java代码

String s = new String(“abc”);
String s1 = “abc”;
String s2 = new String(“abc”);
System.out.println(s == s1);
System.out.println(s == s2);
System.out.println(s1 == s2);

String s = new String(“abc”);

String s1 = “abc”;

String s2 = new String(“abc”);

System.out.println(s == s1);

System.out.println(s == s2);

System.out.println(s1 == s2);

请问以上程序执行结果是什么？

第一句执行后内存中有两个对象，而不是一个。一个由new String(“abc”)中的”abc”在String Pool里生成一个值为”abc”的对象；第二个由new在堆里产生一个值为”abc”的对象，该对象完全是String Pool里的”abc”的一个拷贝。变量s最后指向堆中产生的”abc”对象；
第二句执行时，s1先去String Pool找是否有值为”abc”的对象，很显然在上一步中java已经在String Pool里生成一个”abc”对象了，所以s1直接指向String Pool中的这个”abc”；
第三句中又有一个new，在java中凡遇到new时，都会在堆里产生一个新的对象。因此，该句执行后堆里又多了一个”abc”对象，这与执行第一句后生成的”abc”是不同的两个对象，s2最后指向这个新生成的对象。
因此，执行后面的打印语句的结果是三个false

问题2:

Java代码

System.out.println(s == s.intern());
System.out.println(s1 == s1.intern());
System.out.println(s1.intern() == s2.intern());

System.out.println(s == s.intern());

System.out.println(s1 == s1.intern());

System.out.println(s1.intern() == s2.intern());

请问以上程序执行结果是什么？

设s为String类型的变量，当执行s.intern()时，java先在String Pool里找与字符串变量s相等(用equals()方法)的字符串，若有则将其引用返回；若没有则在String Pool里创建一个与s的值相等的字符串对象，并将其引用返回。从中我们可以总结出intern()方法无论如何都将返回String Pool里的字符串对象的引用。
因此，以上程序执行的结果是false，true，true。
PS:设s和t为两个字符串变量，若有s.equals(t)，必有s.intern() == t.intern()；
PS:”==”永远比较的是两边对象的地址是否相等。

问题3：

Java代码

String hello = “hello”;
String hel = “hel”;
String lo = “lo”;
System.out.println(hello == “hel” + “lo”);
System.out.println(hello == “hel” + lo);

String hello = “hello”;

String hel = “hel”;

String lo = “lo”;

System.out.println(hello == “hel” + “lo”);

System.out.println(hello == “hel” + lo);

请问以上程序执行结果是什么？

前三句在String Pool里分别产生”hello”、”hel”、”lo”三个常量字符串对象
当做第一个加法连接时，+号两边都是常量字符串，java就会将两者拼起来后到String Pool里找与之相等（用equals）的字符串，若存在则将其地址返回；不存在则在String Pool里新建一个常量对象，其值等于拼接后的字符串，并将其地址返回。
第二个+号两边有一个是变量，此时，java会在堆里新建一个对象，其值是两字符串拼接后的值，此时返回的地址是堆中新对象的地址。
所以，第一句做+连接后返回String Pool中”hello”的地址，显然与变量hello的地址相等；
第二句返回的是堆中地址，显然与变量hello的地址不等；

Java的String，StringBuffer，StringBuilder有什么区别？
那就是：String是不可变类（immutable），每次在String对象上的操作都会生成一个新的对象；StringBuffer和StringBuilder则允许在原来对象上进行操作，而不用每次增加对象；StringBuffer是线程安全的，但效率较低，而StringBuilder则不是效率最高。
这个答案我是很早都知道的，而且实际应用中也是这样做的，经常变化的时候用StringBuilder或者StringBuffer。但是为什么是这样的是最近才晓得的，而了解的方法非常简单，就是阅读jdk的源代码：
String和StringBuffer，StringBuilder都是用字符数组来表示的。但是在String中这个字符数组是这样定义的：

private final char value[];

而在StringBuffer和StringBuilder中，这个字符数组都是继承于java.lang.AbstractStringBuilder中的

char value[];
这样答案就很明显了，原因就在这个final关键字上。
而同时通过源代码可以发现StringBuffer的很多方法和属性都有synchronized关键字修饰，而StringBuilder则没有。
就是这样的，源代码胜过一切文档和专家老师的讲解。

Java Object

方法摘要
protected Object clone()
创建并返回此对象的一个副本。
boolean equals(Object obj)
指示某个其他对象是否与此对象”相等”。
protected void finalize()
当垃圾回收器确定不存在对该对象的更多引用时，由对象的垃圾回收器调用此方法。
Class getClass()
返回一个对象的运行时类。
int hashCode()
返回该对象的哈希码值。
void notify()
唤醒在此对象监视器上等待的单个线程。
void notifyAll()
唤醒在此对象监视器上等待的所有线程。
String toString()
返回该对象的字符串表示。
void wait()
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法。
void wait(long timeout)
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者超过指定的时间量。
void wait(long timeout, int nanos)
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者其他某个线程中断当前线程，或者已超过某个实际时间量。

构造方法详细信息

Object
public Object()
方法详细信息

getClass
public final Class getClass()
返回一个对象的运行时类。该 Class 对象是由所表示类的 static synchronized 方法锁定的对象。

返回：
表示该对象的运行时类的 java.lang.Class 对象。此结果属于类型 Class，其中 X 表示清除表达式中的静态类型，该表达式调用 getClass。

——————————————————————————–

hashCode
public int hashCode()
返回该对象的哈希码值。支持该方法是为哈希表提供一些优点，例如，java.util.Hashtable 提供的哈希表。
hashCode 的常规协定是：

在 Java 应用程序执行期间，在同一对象上多次调用 hashCode 方法时，必须一致地返回相同的整数，前提是对象上 equals 比较中所用的信息没有被修改。从某一应用程序的一次执行到同一应用程序的另一次执行，该整数无需保持一致。
如果根据 equals(Object) 方法，两个对象是相等的，那么在两个对象中的每个对象上调用 hashCode 方法都必须生成相同的整数结果。
以下情况不是必需的：如果根据 equals(java.lang.Object) 方法，两个对象不相等，那么在两个对象中的任一对象上调用 hashCode 方法必定会生成不同的整数结果。但是，程序员应该知道，为不相等的对象生成不同整数结果可以提高哈希表的性能。
实际上，由 Object 类定义的 hashCode 方法确实会针对不同的对象返回不同的整数。（这一般是通过将该对象的内部地址转换成一个整数来实现的，但是 JavaTM 编程语言不需要这种实现技巧。）

返回：
此对象的一个哈希码值。
另请参见：
equals(java.lang.Object), Hashtable

——————————————————————————–

equals
public boolean equals(Object obj)
指示某个其他对象是否与此对象”相等”。
equals 方法在非空对象引用上实现相等关系：

自反性：对于任何非空引用值 x，x.equals(x) 都应返回 true。
对称性：对于任何非空引用值 x 和 y，当且仅当 y.equals(x) 返回 true 时，x.equals(y) 才应返回 true。
传递性：对于任何非空引用值 x、y 和 z，如果 x.equals(y) 返回 true，并且 y.equals(z) 返回 true，那么 x.equals(z) 应返回 true。
一致性：对于任何非空引用值 x 和 y，多次调用 x.equals(y) 始终返回 true 或始终返回 false，前提是对象上 equals 比较中所用的信息没有被修改。
对于任何非空引用值 x，x.equals(null) 都应返回 false。
Object 类的 equals 方法实现对象上差别可能性最大的相等关系；即，对于任何非空引用值 x 和 y，当且仅当 x 和 y 引用同一个对象时，此方法才返回 true（x == y 具有值 true）。

注意：当此方法被重写时，通常有必要重写 hashCode 方法，以维护 hashCode 方法的常规协定，该协定声明相等对象必须具有相等的哈希码。

参数：
obj – 要与之比较的引用对象。
返回：
如果此对象与 obj 参数相同，则返回 true；否则返回 false。
另请参见：
hashCode(), Hashtable

——————————————————————————–

clone
protected Object clone()
throws CloneNotSupportedException
创建并返回此对象的一个副本。”副本”的准确含义可能依赖于对象的类。一般来说，对于任何对象 x，如果表达式：
x.clone() != x
是正确的，则表达式：
x.clone().getClass() == x.getClass()
将为 true，但这些不是绝对条件。一般情况下是：
x.clone().equals(x)
将为 true，但这不是绝对条件。
按照惯例，返回的对象应该通过调用 super.clone 获得。如果一个类及其所有的超类（Object 除外）都遵守此约定，则 x.clone().getClass() == x.getClass()。

按照惯例，此方法返回的对象应该独立于该对象（正被克隆的对象）。要获得此独立性，在 super.clone 返回对象之前，有必要对该对象的一个或多个字段进行修改。这通常意味着要复制包含正在被克隆对象的内部”深层结构”的所有可变对象，并使用对副本的引用替换对这些对象的引用。如果一个类只包含基本字段或对不变对象的引用，那么通常不需要修改 super.clone 返回的对象中的字段。

Object 类的 clone 方法执行特定的克隆操作。首先，如果此对象的类不能实现接口 Cloneable，则会抛出 CloneNotSupportedException。注意：所有的数组都被视为实现接口 Cloneable。否则，此方法会创建此对象的类的一个新实例，并像通过分配那样，严格使用此对象相应字段的内容初始化该对象的所有字段；这些字段的内容没有被自我克隆。所以，此方法执行的是该对象的”浅表复制”，而不”深层复制”操作。

Object 类本身不实现接口 Cloneable，所以在类为 Object 的对象上调用 clone 方法将会导致在运行时抛出异常。

返回：
此实例的一个克隆。
抛出：
CloneNotSupportedException – 如果对象的类不支持 Cloneable 接口，则重写 clone 方法的子类也会抛出此异常，以指示无法克隆某个实例。
另请参见：
Cloneable

——————————————————————————–

toString
public String toString()
返回该对象的字符串表示。通常，toString 方法会返回一个”以文本方式表示”此对象的字符串。结果应是一个简明但易于读懂。建议所有子类都重写此方法。
Object 类的 toString 方法返回一个字符串，该字符串由类名（对象是该类的一个实例）、at 标记符”@”和此对象哈希码的无符号十六进制表示组成。换句话说，该方法返回一个字符串，它的值等于：

getClass().getName() + ‘@’ + Integer.toHexString(hashCode())

返回：
该对象的字符串表示形式。

——————————————————————————–

notify
public final void notify()
唤醒在此对象监视器上等待的单个线程。如果所有线程都在此对象上等待，则会选择唤醒其中一个线程。选择是任意性的，并在对实现做出决定时发生。线程通过调用其中一个 wait 方法，在对象的监视器上等待。
直到当前的线程放弃此对象上的锁定，才能继续执行被唤醒的线程。被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争；例如，唤醒的线程在作为锁定此对象的下一个线程方面没有可靠的特权或劣势。

此方法只应由作为此对象监视器的所有者的线程来调用。通过以下三种方法之一，线程可以成为此对象监视器的所有者：

通过执行此对象的同步 (Sychronized) 实例方法。
通过执行在此对象上进行同步的 synchronized 语句的正文。
对于 Class 类型的对象，可以通过执行该类的同步静态方法。
一次只能有一个线程拥有对象的监视器。

抛出：
IllegalMonitorStateException – 如果当前的线程不是此对象监视器的所有者。
另请参见：
notifyAll(), wait()

——————————————————————————–

notifyAll
public final void notifyAll()
唤醒在此对象监视器上等待的所有线程。线程通过调用其中一个 wait 方法，在对象的监视器上等待。
直到当前的线程放弃此对象上的锁定，才能继续执行被唤醒的线程。被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争；例如，唤醒的线程在作为锁定此对象的下一个线程方面没有可靠的特权或劣势。

此方法只应由作为此对象监视器的所有者的线程来调用。请参阅 notify 方法，了解线程能够成为监视器所有者的方法的描述。

抛出：
IllegalMonitorStateException – 如果当前的线程不是此对象监视器的所有者。
另请参见：
notify(), wait()

——————————————————————————–

wait
public final void wait(long timeout)
throws InterruptedException
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者超过指定的时间量。
当前的线程必须拥有此对象监视器。

此方法导致当前线程（称之为 T）将其自身放置在对象的等待集中，然后放弃此对象上的所有同步要求。出于线程调度目的，线程 T 被禁用，且处于休眠状态，直到发生以下四种情况之一：

其他某个线程调用此对象的 notify 方法，并且线程 T 碰巧被任选为被唤醒的线程。
其他某个线程调用此对象的 notifyAll 方法。
其他某个线程中断线程 T。
已经到达指定的实际时间。但是，如果 timeout 为零，则不考虑实际时间，该线程将一直等待，直到获得通知。
然后，从对象的等待集中删除线程 T，并重新进行线程调度。然后，该线程以常规方式与其他线程竞争，以获得在该对象上同步的权利；一旦获得对该对象的控制权，该对象上的所有其同步声明都将被还原到以前的状态 – 这就是调用 wait 方法时的情况。然后，线程 T 从 wait 方法的调用中返回。所以，从 wait 方法返回时，该对象和线程 T 的同步状态与调用 wait 方法时的情况完全相同。
在没有被通知、中断或超时的情况下，线程还可以唤醒一个所谓的虚假唤醒 (spurious wakeup)。虽然这种情况在实践中很少发生，但是应用程序必须通过以下方式防止其发生，即对应该导致该线程被提醒的条件进行测试，如果不满足该条件，则继续等待。换句话说，等待应总是发生在循环中，如下面的示例：

synchronized (obj) {
while ()
obj.wait(timeout);
… // Perform action appropriate to condition
}
（有关这一主题的更多信息，请参阅 Doug Lea 撰写的《Concurrent Programming in Java (Second Edition)》(Addison-Wesley, 2000) 中的第 3.2.3 节或 Joshua Bloch 撰写的《Effective Java Programming Language Guide》(Addison-Wesley, 2001) 中的第 50 项。
如果当前线程在等待时被其他线程中断，则会抛出 InterruptedException。在按上述形式恢复此对象的锁定状态时才会抛出此异常。

注意，由于 wait 方法将当前的线程放入了对象的等待集中，所以它只能解除此对象的锁定；可以同步当前线程的任何其他对象在线程等待时仍处于锁定状态。

此方法只应由作为此对象监视器的所有者的线程来调用。请参阅 notify 方法，了解线程能够成为监视器所有者的方法的描述。

参数：
timeout – 要等待的最长时间（以毫秒为单位）。
抛出：
IllegalArgumentException – 如果超时值为负。
IllegalMonitorStateException – 如果当前的线程不是此对象监视器的所有者。
InterruptedException – 如果在当前线程等待通知之前或者正在等待通知时，另一个线程中断了当前线程。在抛出此异常时，当前线程的中断状态被清除。
另请参见：
notify(), notifyAll()

——————————————————————————–

wait
public final void wait(long timeout,
int nanos)
throws InterruptedException
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者其他某个线程中断当前线程，或者已超过某个实际时间量。
此方法类似于一个参数的 wait 方法，但它允许更好地控制在放弃之前等待通知的时间量。用毫微秒度量的实际时间量可以通过以下公式计算出来：

1000000*timeout+nanos
在其他所有方面，此方法执行的操作与带有一个参数的 wait(long) 方法相同。需要特别指出的是，wait(0, 0) 与 wait(0) 相同。

当前的线程必须拥有此对象监视器。该线程发布对此监视器的所有权，并等待下面两个条件之一发生：

其他线程通过调用 notify 方法，或 notifyAll 方法通知在此对象的监视器上等待的线程醒来。
timeout 毫秒值与 nanos 毫微秒参数值之和指定的超时时间已用完。
然后，该线程等到重新获得对监视器的所有权后才能继续执行。

对于某一个参数的版本，实现中断和虚假唤醒是有可能的，并且此方法应始终在循环中使用：

synchronized (obj) {
while ()
obj.wait(timeout, nanos);
… // Perform action appropriate to condition
}
此方法只应由作为此对象监视器的所有者的线程来调用。请参阅 notify 方法，了解线程能够成为监视器所有者的方法的描述。

参数：
timeout – 要等待的最长时间（以毫秒为单位）。
nanos – 额外时间（以毫微秒为单位，范围是 0-999999）。
抛出：
IllegalArgumentException – 如果超时值是负数，或者毫微秒值不在 0-999999 范围内。
IllegalMonitorStateException – 如果当前线程不是此对象监视器的所有者。
InterruptedException – 如果在当前线程等待通知之前或者正在等待通知时，其他线程中断了当前线程。在抛出此异常时，当前线程的中断状态被清除。

——————————————————————————–

wait
public final void wait()
throws InterruptedException
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法。换句话说，此方法的行为就好像它仅执行 wait(0) 调用一样。
当前的线程必须拥有此对象监视器。该线程发布对此监视器的所有权并等待，直到其他线程通过调用 notify 方法，或 notifyAll 方法通知在此对象的监视器上等待的线程醒来。然后该线程将等到重新获得对监视器的所有权后才能继续执行。

对于某一个参数的版本，实现中断和虚假唤醒是可能的，而且此方法应始终在循环中使用：

synchronized (obj) {
while ()
obj.wait();
… // Perform action appropriate to condition
}
此方法只应由作为此对象监视器的所有者的线程来调用。请参阅 notify 方法，了解线程能够成为监视器所有者的方法的描述。

抛出：
IllegalMonitorStateException – 如果当前的线程不是此对象监视器的所有者。
InterruptedException – 如果在当前线程等待通知之前或者正在等待通知时，另一个线程中断了当前线程。在抛出此异常时，当前线程的中断状态被清除。
另请参见：
notify(), notifyAll()

——————————————————————————–

finalize
protected void finalize()
throws Throwable
当垃圾回收器确定不存在对该对象的更多引用时，由对象的垃圾回收器调用此方法。子类重写 finalize 方法，以配置系统资源或执行其他清除。
finalize 的常规协定是：当 JavaTM 虚拟机已确定尚未终止的任何线程无法再通过任何方法访问此对象时，将调用此方法，除非由于准备终止的其他某个对象或类的终结操作执行了某个操作。 finalize 方法可以采取任何操作，其中包括再次使此对象对其他线程可用；不过，finalize 的主要目的是在不可撤消地丢弃对象之前执行清除操作。例如，表示输入/输出连接的对象的 finalize 方法可执行显式 I/O 事务，以便在永久丢弃对象之前中断连接。

Object 类的 finalize 方法执行非特殊性操作；它仅执行一些常规返回。Object 的子类可以重写此定义。

Java 编程语言不保证哪个线程将调用某个给定对象的 finalize 方法。但可以保证在调用 finalize 时，调用 finalize 的线程将不会持有任何用户可见的同步锁定。如果 finalize 方法抛出未捕获的异常，那么该异常将被忽略，并且该对象的终结操作将终止。

在启用某个对象的 finalize 方法后，将不会执行进一步操作，直到 Java 虚拟机再次确定尚未终止的任何线程无法再通过任何方法访问此对象，其中包括由准备终止的其他对象或类执行的可能操作，在执行该操作时，对象可能被丢弃。

对于任何给定对象，Java 虚拟机最多只调用一次 finalize 方法。

finalize 方法抛出的任何异常都会导致此对象的终结操作停止，但可以通过其他方法忽略它。

Hashtable和HashMap的区别

Hashtable和HashMap类有三个重要的不同之处。第一个不同主要是历史原因。Hashtable是基于陈旧的Dictionary类的，HashMap是Java 1.2引进的Map接口的一个实现。

最重要的不同是Hashtable的方法是同步的，而HashMap的方法不是。这就意味着，虽然你可以不用采取任何特殊的行为就可以在一个多线程的应用程序中用一个Hashtable，但你必须同样地为一个HashMap提供外同步。一个方便的方法就是利用Collections类的静态的synchronizedMap()方法，它创建一个线程安全的Map对象，并把它作为一个封装的对象来返回。这个对象的方法可以让你同步访问潜在的HashMap。这么做的结果就是当你不需要同步时，你不能切断Hashtable中的同步（比如在一个单线程的应用程序中），而且同步增加了很多处理费用。

第三点不同是，只有HashMap可以让你将空值作为一个表的条目的key或value。HashMap中只有一条记录可以是一个空的key，但任意数量的条目可以是空的value。这就是说，如果在表中没有发现搜索键，或者如果发现了搜索键，但它是一个空的值，那么get()将返回null。如果有必要，用containKey()方法来区别这两种情况。

　一些资料建议，当需要同步时，用Hashtable，反之用HashMap。但是，因为在需要时，HashMap可以被同步，HashMap的功能比Hashtable的功能更多，而且它不是基于一个陈旧的类的，所以有人认为，在各种情况下，HashMap都优先于Hashtable。

关于Properties

有时侯，你可能想用一个hashtable来映射key的字符串到value的字符串。DOS、Windows和Unix中的环境字符串就有一些例子，如key的字符串PATH被映射到value的字符串C:WINDOWS;C:WINDOWSSYSTEM。Hashtables是表示这些的一个简单的方法，但Java提供了另外一种方法。

Java.util.Properties类是Hashtable的一个子类，设计用于String keys和values。Properties对象的用法同Hashtable的用法相象，但是类增加了两个节省时间的方法，你应该知道。

Store()方法把一个Properties对象的内容以一种可读的形式保存到一个文件中。Load()方法正好相反，用来读取文件，并设定Properties对象来包含keys和values。

注意，因为Properties扩展了Hashtable，你可以用超类的put()方法来添加不是String对象的keys和values。这是不可取的。另外，如果你将store()用于一个不包含String对象的Properties对象，store()将失败。作为put()和get()的替代，你应该用setProperty()和getProperty()，它们用String参数。

如何设计线程安全 HashMap

具体可以参见java5里的ConcurrentHashMap之实现细节

ConcurrentHashMap是Java 5中支持高并发、高吞吐量的线程安全HashMap实现。

实现原理

锁分离 (Lock Stripping)

ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术。它使用了多个锁来控制对hash表的不同部分进行的修改。ConcurrentHashMap内部使用段(Segment)来表示这些不同的部分，每个段其实就是一个小的hash table，它们有自己的锁。只要多个修改操作发生在不同的段上，它们就可以并发进行。

有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁。这里”按顺序”是很重要的，否则极有可能出现死锁，在ConcurrentHashMap内部，段数组是final的，并且其成员变量实际上也是final的，但是，仅仅是将数组声明为final的并不保证数组成员也是final的，这需要实现上的保证。这可以确保不会出现死锁，因为获得锁的顺序是固定的。不变性是多线程编程占有很重要的地位，下面还要谈到。

final Segment<K,V>[] segments;

不变(Immutable)和易变(Volatile)

ConcurrentHashMap完全允许多个读操作并发进行，读操作并不需要加锁。如果使用传统的技术，如HashMap中的实现，如果允许可以在hash链的中间添加或删除元素，读操作不加锁将得到不一致的数据。ConcurrentHashMap实现技术是保证HashEntry几乎是不可变的。HashEntry代表每个hash链中的一个节点，其结构如下所示：

static final class HashEntry<K,V> {

final K key;

final int hash;

volatile V value;

final HashEntry<K,V> next;

}

可以看到除了value不是final的，其它值都是final的，这意味着不能从hash链的中间或尾部添加或删除节点，因为这需要修改next引用值，所有的节点的修改只能从头部开始。对于put操作，可以一律添加到Hash链的头部。但是对于remove操作，可能需要从中间删除一个节点，这就需要将要删除节点的前面所有节点整个复制一遍，最后一个节点指向要删除结点的下一个结点。这在讲解删除操作时还会详述。为了确保读操作能够看到最新的值，将value设置成volatile，这避免了加锁。

其它

为了加快定位段以及段中hash槽的速度，每个段hash槽的的个数都是2^n，这使得通过位运算就可以定位段和段中hash槽的位置。当并发级别为默认值16时，也就是段的个数，hash值的高4位决定分配在哪个段中。但是我们也不要忘记《算法导论》给我们的教训：hash槽的的个数不应该是2^n，这可能导致hash槽分配不均，这需要对hash值重新再hash一次。（这段似乎有点多余了）

这是重新hash的算法，还比较复杂，我也懒得去理解了。

private static int hash(int h) {

// Spread bits to regularize both segment and index locations,

// using variant of single-word Wang/Jenkins hash.

h += (h << 15) ^ 0xffffcd7d;

h ^= (h >>> 10);

h += (h << 3);

h ^= (h >>> 6);

h += (h << 2) + (h << 14);

return h ^ (h >>> 16);

}

这是定位段的方法：

final Segment<K,V> segmentFor(int hash) {

return segments[(hash >>> segmentShift) & segmentMask];

}

数据结构

关于Hash表的基础数据结构，这里不想做过多的探讨。Hash表的一个很重要方面就是如何解决hash冲突，ConcurrentHashMap和HashMap使用相同的方式，都是将hash值相同的节点放在一个hash链中。与HashMap不同的是，ConcurrentHashMap使用多个子Hash表，也就是段(Segment)。下面是ConcurrentHashMap的数据成员：

public class ConcurrentHashMap<K, V> extends AbstractMap<K, V>

implements ConcurrentMap<K, V>, Serializable {

final int segmentMask;

final int segmentShift;

final Segment<K,V>[] segments;

}

所有的成员都是final的，其中segmentMask和segmentShift主要是为了定位段，参见上面的segmentFor方法。

每个Segment相当于一个子Hash表，它的数据成员如下：

static final class Segment<K,V> extends ReentrantLock implements Serializable {

private static final long serialVersionUID = 2249069246763182397L;

transient volatile int count;

transient int modCount;

transient int threshold;

transient volatile HashEntry<K,V>[] table;

final float loadFactor;

}

count用来统计该段数据的个数，它是volatile，它用来协调修改和读取操作，以保证读取操作能够读取到几乎最新的修改。协调方式是这样的，每次修改操作做了结构上的改变，如增加/删除节点(修改节点的值不算结构上的改变)，都要写count值，每次读取操作开始都要读取count的值。这利用了Java 5中对volatile语义的增强，对同一个volatile变量的写和读存在happens-before关系。modCount统计段结构改变的次数，主要是为了检测对多个段进行遍历过程中某个段是否发生改变，在讲述跨段操作时会还会详述。threashold用来表示需要进行rehash的界限值。table数组存储段中节点，每个数组元素是个hash链，用HashEntry表示。table也是volatile，这使得能够读取到最新的table值而不需要同步。loadFactor表示负载因子。

实现细节

修改操作

先来看下删除操作remove(key)。

public V remove(Object key) {

int hash = hash(key.hashCode());

return segmentFor(hash).remove(key, hash, null);

}

整个操作是先定位到段，然后委托给段的remove操作。当多个删除操作并发进行时，只要它们所在的段不相同，它们就可以同时进行。下面是Segment的remove方法实现：

V remove(Object key, int hash, Object value) {

lock();

try {

int c = count – 1;

HashEntry<K,V>[] tab = table;

int index = hash & (tab.length – 1);

HashEntry<K,V> first = tab[index];

HashEntry<K,V> e = first;

while (e != null && (e.hash != hash || !key.equals(e.key)))

e = e.next;

V oldValue = null;

if (e != null) {

V v = e.value;

if (value == null || value.equals(v)) {

oldValue = v;

// All entries following removed node can stay

// in list, but all preceding ones need to be

// cloned.

++modCount;

HashEntry<K,V> newFirst = e.next;

for (HashEntry<K,V> p = first; p != e; p = p.next)

newFirst = new HashEntry<K,V>(p.key, p.hash,

newFirst, p.value);

tab[index] = newFirst;

count = c; // write-volatile

}

return oldValue;

} finally {

unlock();

}

整个操作是在持有段锁的情况下执行的，空白行之前的行主要是定位到要删除的节点e。接下来，如果不存在这个节点就直接返回null，否则就要将e前面的结点复制一遍，尾结点指向e的下一个结点。e后面的结点不需要复制，它们可以重用。下面是个示意图，我直接从这个网站上复制的（画这样的图实在是太麻烦了，如果哪位有好的画图工具，可以推荐一下）。

删除元素之前：

删除元素3之后：

第二个图其实有点问题，复制的结点中应该是值为2的结点在前面，值为1的结点在后面，也就是刚好和原来结点顺序相反，还好这不影响我们的讨论。

整个remove实现并不复杂，但是需要注意如下几点。第一，当要删除的结点存在时，删除的最后一步操作要将count的值减一。这必须是最后一步操作，否则读取操作可能看不到之前对段所做的结构性修改。第二，remove执行的开始就将table赋给一个局部变量tab，这是因为table是volatile变量，读写volatile变量的开销很大。编译器也不能对volatile变量的读写做任何优化，直接多次访问非volatile实例变量没有多大影响，编译器会做相应优化。

接下来看put操作，同样地put操作也是委托给段的put方法。下面是段的put方法：

V put(K key, int hash, V value, boolean onlyIfAbsent) {

lock();

try {

int c = count;

if (c++ > threshold) // ensure capacity

rehash();

HashEntry<K,V>[] tab = table;

int index = hash & (tab.length – 1);

HashEntry<K,V> first = tab[index];

HashEntry<K,V> e = first;

while (e != null && (e.hash != hash || !key.equals(e.key)))

e = e.next;

V oldValue;

if (e != null) {

oldValue = e.value;

if (!onlyIfAbsent)

e.value = value;

}

else {

oldValue = null;

++modCount;

tab[index] = new HashEntry<K,V>(key, hash, first, value);

count = c; // write-volatile

}

return oldValue;

} finally {

unlock();

}

该方法也是在持有段锁的情况下执行的，首先判断是否需要rehash，需要就先rehash。接着是找是否存在同样一个key的结点，如果存在就直接替换这个结点的值。否则创建一个新的结点并添加到hash链的头部，这时一定要修改modCount和count的值，同样修改count的值一定要放在最后一步。put方法调用了rehash方法，reash方法实现得也很精巧，主要利用了table的大小为2^n，这里就不介绍了。

修改操作还有putAll和replace。putAll就是多次调用put方法，没什么好说的。replace甚至不用做结构上的更改，实现要比put和delete要简单得多，理解了put和delete，理解replace就不在话下了，这里也不介绍了。

获取操作

首先看下get操作，同样ConcurrentHashMap的get操作是直接委托给Segment的get方法，直接看Segment的get方法：

V get(Object key, int hash) {

if (count != 0) { // read-volatile

HashEntry<K,V> e = getFirst(hash);

while (e != null) {

if (e.hash == hash && key.equals(e.key)) {

V v = e.value;

if (v != null)

return v;

return readValueUnderLock(e); // recheck

}

e = e.next;

}

return null;

}

get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count变量，通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是volatile的，也能保证读取到最新的值。接下来就是对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是final的，这是通过getFirst(hash)方法返回，也就是存在table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash)之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽然可能不是最新的。要得到最新的数据，只有采用完全的同步。

最后，如果找到了所求的结点，判断它的值如果非空就直接返回，否则在有锁的状态下再读一次。这似乎有些费解，理论上结点的值不可能为空，这是因为put的时候就进行了判断，如果为空就要抛NullPointerException。空值的唯一源头就是HashEntry中的默认值，因为HashEntry中的value不是final的，非同步读取有可能读取到空值。仔细看下put操作的语句：tab[index] = new HashEntry<K,V>(key, hash, first, value)，在这条语句中，HashEntry构造函数中对value的赋值以及对tab[index]的赋值可能被重新排序，这就可能导致结点的值为空。这种情况应当很罕见，一旦发生这种情况，ConcurrentHashMap采取的方式是在持有锁的情况下再读一遍，这能够保证读到最新的值，并且一定不会为空值。

V readValueUnderLock(HashEntry<K,V> e) {

lock();

try {

return e.value;

} finally {

unlock();

}

另一个操作是containsKey，这个实现就要简单得多了，因为它不需要读取值：

boolean containsKey(Object key, int hash) {

if (count != 0) { // read-volatile

HashEntry<K,V> e = getFirst(hash);

while (e != null) {

if (e.hash == hash && key.equals(e.key))

return true;

e = e.next;

}

return false;

}

跨段操作

有些操作需要涉及到多个段，比如说size(), containsValaue()。先来看下size()方法：

public int size() {

final Segment<K,V>[] segments = this.segments;

long sum = 0;

long check = 0;

int[] mc = new int[segments.length];

// Try a few times to get accurate count. On failure due to

// continuous async changes in table, resort to locking.

for (int k = 0; k < RETRIES_BEFORE_LOCK; ++k) {

check = 0;

sum = 0;

int mcsum = 0;

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

sum += segments[i].count;

mcsum += mc[i] = segments[i].modCount;

}

if (mcsum != 0) {

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

check += segments[i].count;

if (mc[i] != segments[i].modCount) {

check = -1; // force retry

break;

}

if (check == sum)

break;

}

if (check != sum) { // Resort to locking all segments

sum = 0;

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

segments[i].lock();

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

sum += segments[i].count;

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

segments[i].unlock();

}

if (sum > Integer.MAX_VALUE)

return Integer.MAX_VALUE;

else

return (int)sum;

}

size方法主要思路是先在没有锁的情况下对所有段大小求和，如果不能成功（这是因为遍历过程中可能有其它线程正在对已经遍历过的段进行结构性更新），最多执行RETRIES_BEFORE_LOCK次，如果还不成功就在持有所有段锁的情况下再对所有段大小求和。在没有锁的情况下主要是利用Segment中的modCount进行检测，在遍历过程中保存每个Segment的modCount，遍历完成之后再检测每个Segment的modCount有没有改变，如果有改变表示有其它线程正在对Segment进行结构性并发更新，需要重新计算。

其实这种方式是存在问题的，在第一个内层for循环中，在这两条语句sum += segments[i].count; mcsum += mc[i] = segments[i].modCount;之间，其它线程可能正在对Segment进行结构性的修改，导致segments[i].count和segments[i].modCount读取的数据并不一致。这可能使size()方法返回任何时候都不曾存在的大小，很奇怪javadoc居然没有明确标出这一点，可能是因为这个时间窗口太小了吧。size()的实现还有一点需要注意，必须要先segments[i].count，才能segments[i].modCount，这是因为segment[i].count是对volatile变量的访问，接下来segments[i].modCount才能得到几乎最新的值（前面我已经说了为什么只是”几乎”了）。这点在containsValue方法中得到了淋漓尽致的展现：

public boolean containsValue(Object value) {

if (value == null)

throw new NullPointerException();

// See explanation of modCount use above

final Segment<K,V>[] segments = this.segments;

int[] mc = new int[segments.length];

// Try a few times without locking

for (int k = 0; k < RETRIES_BEFORE_LOCK; ++k) {

int sum = 0;

int mcsum = 0;

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

int c = segments[i].count;

mcsum += mc[i] = segments[i].modCount;

if (segments[i].containsValue(value))

return true;

}

boolean cleanSweep = true;

if (mcsum != 0) {

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

int c = segments[i].count;

if (mc[i] != segments[i].modCount) {

cleanSweep = false;

break;

}

if (cleanSweep)

return false;

}

// Resort to locking all segments

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

segments[i].lock();

boolean found = false;

try {

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

if (segments[i].containsValue(value)) {

found = true;

break;

}

} finally {

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

segments[i].unlock();

}

return found;

}

同样注意内层的第一个for循环，里面有语句int c = segments[i].count; 但是c却从来没有被使用过，即使如此，编译器也不能做优化将这条语句去掉，因为存在对volatile变量count的读取，这条语句存在的唯一目的就是保证segments[i].modCount读取到几乎最新的值。关于containsValue方法的其它部分就不分析了，它和size方法差不多。

跨段方法中还有一个isEmpty()方法，其实现比size()方法还要简单，也不介绍了。最后简单地介绍下迭代方法，如keySet(), values(), entrySet()方法，这些方法都返回相应的迭代器，所有迭代器都继承于Hash_Iterator类(提交时居然提醒我不能包含sh It，只得加了下划线)，里实现了主要的方法。其结构是：

abstract class Hash_Iterator{

int nextSegmentIndex;

int nextTableIndex;

HashEntry<K,V>[] currentTable;

HashEntry<K, V> nextEntry;

HashEntry<K, V> lastReturned;

}

nextSegmentIndex是段的索引，nextTableIndex是nextSegmentIndex对应段中中hash链的索引，currentTable是nextSegmentIndex对应段的table。调用next方法时主要是调用了advance方法：

final void advance() {

if (nextEntry != null && (nextEntry = nextEntry.next) != null)

return;

while (nextTableIndex >= 0) {

if ( (nextEntry = currentTable[nextTableIndex–]) != null)

return;

}

while (nextSegmentIndex >= 0) {

Segment<K,V> seg = segments[nextSegmentIndex–];

if (seg.count != 0) {

currentTable = seg.table;

for (int j = currentTable.length – 1; j >= 0; –j) {

if ( (nextEntry = currentTable[j]) != null) {

nextTableIndex = j – 1;

return;

}

不想再多介绍了，唯一需要注意的是跳到下一个段时，一定要先读取下一个段的count变量。

这种迭代方式的主要效果是不会抛出ConcurrentModificationException。一旦获取到下一个段的table，也就意味着这个段的头结点在迭代过程中就确定了，在迭代过程中就不能反映对这个段节点并发的删除和添加，对于节点的更新是能够反映的，因为节点的值是一个volatile变量。

结束语

ConcurrentHashMap是一个支持高并发的高性能的HashMap实现，它支持完全并发的读以及一定程度并发的写。ConcurrentHashMap的实现也是很精巧，充分利用了最新的JMM规范，值得学习，却不值得模仿。最后由于本人水平有限，对大师的作品难免有误解，如果存在，还望大牛们不吝指出。

参考文章：

http://www.ibm.com/developerworks/java/library/j-jtp08223/，这个是讨论的是Doug Lea’s util.concurrent包中的ConcurrentHashMap的实现，不过大致思想是一致的。

http://floatingpoint.tinou.com/2008/09/performance-optimization-in-concurrenthashmap.html

ArrayList和linkedList的区别

1.ArrayList是实现了基于动态数组的数据结构，linkedList基于链表的数据结构。

2.对于随机访问get和set，ArrayList觉得优于linkedList，因为linkedList要移动指针。

3.对于新增和删除操作add和remove，LinedList比较占优势，因为ArrayList要移动数据。

ArrayList 和linkedList是两个集合类，用于存储一系列的对象引用(references)。例如我们可以用ArrayList来存储一系列的String 或者Integer。那么ArrayList和linkedList在性能上有什么差别呢？什么时候应该用ArrayList什么时候又该用 linkedList呢？

一．时间复杂度

首先一点关键的是，ArrayList的内部实现是基于基础的对象数组的，因此，它使用get方法访问列表中的任意一个元素时(random access)，它的速度要比linkedList快。linkedList中的get方法是按照顺序从列表的一端开始检查，直到另外一端。对 linkedList而言，访问列表中的某个指定元素没有更快的方法了。

假设我们有一个很大的列表，它里面的元素已经排好序了，这个列表可能是ArrayList类型的也可能是linkedList类型的，现在我们对这个列表来进行二分查找(binary search)，比较列表是ArrayList和linkedList时的查询速度，看下面的程序：

package com.mangocity.test;
import java.util.linkedList;
import java.util.List;
import java.util.Random;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
public class TestList …{
public static final int N=50000;

public static List values;

static…{
Integer vals[]=new Integer[N];

Random r=new Random();

         for(int i=0,currval=0;i<N;i++)…{
             vals=new Integer(currval);
             currval+=r.nextInt(100)+1;
         }

values=Arrays.asList(vals);
}

     static long timeList(List lst)…{
         long start=System.currentTimeMillis();
         for(int i=0;i<N;i++)…{
             int index=Collections.binarySearch(lst, values.get(i));
             if(index!=i)
                 System.out.println(“***错误***”);
         }
         return System.currentTimeMillis()-start;
     }
     public static void main(String args[])…{
         System.out.println(“ArrayList消耗时间：”+timeList(new ArrayList(values)));
         System.out.println(“linkedList消耗时间：”+timeList(new linkedList(values)));
     }
}

我得到的输出是：ArrayList消耗时间：15

linkedList消耗时间：2596

这个结果不是固定的，但是基本上ArrayList的时间要明显小于linkedList的时间。因此在这种情况下不宜用linkedList。二分查找法使用的随机访问(random access)策略，而linkedList是不支持快速的随机访问的。对一个linkedList做随机访问所消耗的时间与这个list的大小是成比例的。而相应的，在ArrayList中进行随机访问所消耗的时间是固定的。

这是否表明ArrayList总是比linkedList性能要好呢？这并不一定，在某些情况下linkedList的表现要优于ArrayList，有些算法在linkedList中实现时效率更高。比方说，利用Collections.reverse方法对列表进行反转时，其性能就要好些。

看这样一个例子，加入我们有一个列表，要对其进行大量的插入和删除操作，在这种情况下linkedList就是一个较好的选择。请看如下一个极端的例子，我们重复的在一个列表的开端插入一个元素：

package com.mangocity.test;

import java.util.*;
public class ListDemo {
     static final int N=50000;
     static long timeList(List list){
     long start=System.currentTimeMillis();
     Object o = new Object();
     for(int i=0;i<N;i++)
         list.add(0, o);
     return System.currentTimeMillis()-start;
     }
     public static void main(String[] args) {
         System.out.println(“ArrayList耗时：”+timeList(new ArrayList()));
         System.out.println(“linkedList耗时：”+timeList(new linkedList()));
     }
}

这时我的输出结果是：ArrayList耗时：2463

linkedList耗时：15

这和前面一个例子的结果截然相反，当一个元素被加到ArrayList的最开端时，所有已经存在的元素都会后移，这就意味着数据移动和复制上的开销。相反的，将一个元素加到linkedList的最开端只是简单的未这个元素分配一个记录，然后调整两个连接。在linkedList的开端增加一个元素的开销是固定的，而在ArrayList的开端增加一个元素的开销是与ArrayList的大小成比例的。

二．空间复杂度

在linkedList中有一个私有的内部类，定义如下：

private static class Entry {
         Object element;
         Entry next;
         Entry previous;
     }

每个Entry对象reference列表中的一个元素，同时还有在linkedList中它的上一个元素和下一个元素。一个有1000个元素的 linkedList对象将有1000个链接在一起的Entry对象，每个对象都对应于列表中的一个元素。这样的话，在一个linkedList结构中将有一个很大的空间开销，因为它要存储这1000个Entity对象的相关信息。

ArrayList 使用一个内置的数组来存储元素，这个数组的起始容量是10.当数组需要增长时，新的容量按如下公式获得：新容量=(旧容量*3)/2+1，也就是说每一次容量大概会增长50%。这就意味着，如果你有一个包含大量元素的ArrayList对象，那么最终将有很大的空间会被浪费掉，这个浪费是由 ArrayList的工作方式本身造成的。如果没有足够的空间来存放新的元素，数组将不得不被重新进行分配以便能够增加新的元素。对数组进行重新分配，将会导致性能急剧下降。如果我们知道一个ArrayList将会有多少个元素，我们可以通过构造方法来指定容量。我们还可以通过trimToSize方法在 ArrayList分配完毕之后去掉浪费掉的空间。

三．总结

ArrayList和linkedList在性能上各有优缺点，都有各自所适用的地方，总的说来可以描述如下：

性能总结：

–

add()操作

delete()操作

insert操作

index取值操作

iterator取值操作

ArrayList/Vector/Stack

好

差

极优

linkedList

好

差

极优

1．对ArrayList和linkedList而言，在列表末尾增加一个元素所花的开销都是固定的。对ArrayList而言，主要是在内部数组中增加一项，指向所添加的元素，偶尔可能会导致对数组重新进行分配；而对linkedList而言，这个开销是统一的，分配一个内部Entry对象。

2．在ArrayList的中间插入或删除一个元素意味着这个列表中剩余的元素都会被移动；而在linkedList的中间插入或删除一个元素的开销是固定的。

3．linkedList不支持高效的随机元素访问。

4．ArrayList的空间浪费主要体现在在list列表的结尾预留一定的容量空间，而linkedList的空间花费则体现在它的每一个元素都需要消耗相当的空间

可以这样说：当操作是在一列数据的后面添加数据而不是在前面或中间,并且需要随机地访问其中的元素时,使用ArrayList会提供比较好的性能；当你的操作是在一列数据的前面或中间添加或删除数据,并且按照顺序访问其中的元素时,就应该使用linkedList了。

java中ArrayList 、List区别

List集合
List继承自Collection接口。List是一种有序集合，List中的元素可以根据索引（顺序号：元素在集合中处于的位置信息）进行取得/删除/插入操作。
跟Set集合不同的是，List允许有重复元素。对于满足e1.equals(e2)条件的e1与e2对象元素，可以同时存在于List集合中。当然，也有List的实现类不允许重复元素的存在。
同时，List还提供一个listIterator()方法，返回一个ListIterator接口对象，和Iterator接口相比，ListIterator添加元素的添加，删除，和设定等方法，还能向前或向后遍历。

List跟Collection的关系：
java.util.Collection [I]
+–java.util.List [I]
   +–java.util.ArrayList [C]
   +–java.util.linkedList [C]
   +–java.util.Vector [C]
      +–java.util.Stack [C]

List接口的实现类主要有ArrayList，linkedList，Vector，Stack等。

父子关系.
List是一个接口,ArrayList继承与这个接口并实现了它.
用的时候一般都用ArrayList.没用过List. 可以这么用:List list = new ArrayList();

Collection接口
Collection 是最基本的集合接口，一个Collection代表一组Object，即Collection的元素（Elements）。一些 Collection允许相同的元素而另一些不行。一些能排序而另一些不行。Java SDK不提供直接继承自Collection的类，Java SDK提供的类都是继承自Collection的”子接口”如List和Set。
所有实现Collection接口的类都必须提供两个标准的构造函数：无参数的构造函数用于创建一个空的Collection，有一个 Collection参数的构造函数用于创建一个新的Collection，这个新的Collection与传入的Collection有相同的元素。后一个构造函数允许用户复制一个Collection。
如何遍历Collection中的每一个元素？不论Collection的实际类型如何，它都支持一个iterator()的方法，该方法返回一个迭代子，使用该迭代子即可逐一访问Collection中每一个元素。典型的用法如下：
Iterator it = collection.iterator(); // 获得一个迭代子
while(it.hasNext()) {
Object obj = it.next(); // 得到下一个元素
}
由Collection接口派生的两个接口是List和Set。

List接口
List是有序的Collection，使用此接口能够精确的控制每个元素插入的位置。用户能够使用索引（元素在List中的位置，类似于数组下标）来访问List中的元素，这类似于Java的数组。
和下面要提到的Set不同，List允许有相同的元素。
除了具有Collection接口必备的iterator()方法外，List还提供一个listIterator()方法，返回一个 ListIterator接口，和标准的Iterator接口相比，ListIterator多了一些add()之类的方法，允许添加，删除，设定元素，还能向前或向后遍历。
实现List接口的常用类有linkedList，ArrayList，Vector和Stack。

linkedList类
linkedList 实现了List接口，允许null元素。此外linkedList提供额外的get，remove，insert方法在 linkedList的首部或尾部。这些操作使linkedList可被用作堆栈（stack），队列（queue）或双向队列（deque）。
注意linkedList没有同步方法。如果多个线程同时访问一个List，则必须自己实现访问同步。一种解决方法是在创建List时构造一个同步的List：
List list = Collections.synchronizedList(new linkedList(…));

ArrayList类
ArrayList实现了可变大小的数组。它允许所有元素，包括null。ArrayList没有同步。
size，isEmpty，get，set方法运行时间为常数。但是add方法开销为分摊的常数，添加n个元素需要O(n)的时间。其他的方法运行时间为线性。
每个ArrayList实例都有一个容量（Capacity），即用于存储元素的数组的大小。这个容量可随着不断添加新元素而自动增加，但是增长算法并没有定义。当需要插入大量元素时，在插入前可以调用ensureCapacity方法来增加ArrayList的容量以提高插入效率。
和linkedList一样，ArrayList也是非同步的（unsynchronized）。

总结
　　如果涉及到堆栈，队列等操作，应该考虑用List，对于需要快速插入，删除元素，应该使用linkedList，如果需要快速随机访问元素，应该使用ArrayList。
尽量返回接口而非实际的类型，如返回List而非ArrayList，这样如果以后需要将ArrayList换成linkedList时，客户端代码不用改变。这就是针对抽象编程。

Java内存泄露

Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java 中的内存泄漏，这些对象不会被GC 所回收，然而它却占用内存。在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收

不回来。在Java 中，这些不可达的对象都由GC 负责回收，因此程序员不需要考虑这部分的内存泄漏。通过分析，可以得知，对于C++，程序员需要自己管理边和顶点，而对于Java 程序员只需要管理边就可以了（不需要管理顶点

的释放）。通过这种方式，Java 提高了编程的效率。

内存泄漏示例

示例1

在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身，那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。

Vector v = new Vector(10);

for (int i = 1; i<100; i++)

{Object o = new Object();

v.add(o);

o = null;

}//

此时，所有的Object 对象都没有被释放，因为变量v 引用这些对象。实际上无用，而还被引用的对象，GC 就无能为力了（事实上GC 认为它还有用），这一点是导致内存泄漏最重要的原因。

(1)如果要释放对象，就必须使其的引用记数为0，只有那些不再被引用的对象才能被释放，这个原理很简单，但是很重要，是导致内存泄漏的基本原因，也是解决内存泄漏方法的宗旨；

(2)程序员无须管理对象空间具体的分配和释放过程，但必须要关注被释放对象的引用记数是否为0；

(3)一个对象可能被其他对象引用的过程的几种：

a.直接赋值，如上例中的A.a = E；

b.通过参数传递，例如public void addObject(Object E)；

c.其它一些情况如系统调用等。

容易引起内存泄漏的几大原因

静态集合类

像HashMap、Vector 等静态集合类的使用最容易引起内存泄漏，因为这些静态变量的生命周期与应用程序一致，如示例1，如果该Vector 是静态的，那么它将一直存在，而其中所有的Object对象也不能被释放，因为它们也将一直被该Vector 引用着。

监听器

在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

物理连接

一些物理连接，比如数据库连接和网络连接，除非其显式的关闭了连接，否则是不会自动被GC 回收的。Java 数据库连接一般用DataSource.getConnection()来创建，当不再使用时必须用Close()方法来释放，因为这些连接是独立于JVM的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。

内部类和外部模块等的引用

内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。对于程序员而言，自己的程序很清楚，如果发现内存泄漏，自己对这些对象的引用可以很快定位并解决，但是现在的应用软件

并非一个人实现，模块化的思想在现代软件中非常明显，所以程序员要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：

public void registerMsg(Object b);

这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。

预防和检测内存漏洞

在了解了引起内存泄漏的一些原因后，应该尽可能地避免和发现内存泄漏。

(1)好的编码习惯。最基本的建议就是尽早释放无用对象的引用，大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域后，自动设置为null。在使用这种方式时候，必须特别注意一些复杂的对象图，例如数组、列、树、图等，这些对象之间有相互引用关系较为复杂。对于这类对象，GC 回收它们一般效率较低。如果程序允许，尽早将不用的引用对象赋为null。另外建议几点：

在确认一个对象无用后，将其所有引用显式的置为null；

当类从Jpanel 或Jdialog 或其它容器类继承的时候，删除该对象之前不妨调用它的removeall()方法；在设一个引用变量为null 值之前，应注意该引用变量指向的对象是否被监听，若有，要首先除去监听器，然后才可以赋空值；当对象是一个Thread 的时候，删除该对象之前不妨调用它的interrupt()方法；内存检测过程中不仅要关注自己编写的类对象，同时也要关注一些基本类型的对象，例如：int[]、String、char[]等等；如果有数据库连接，使用try…finally 结构，在finally 中关闭Statement 对象和连接。

(2)好的测试工具。在开发中不能完全避免内存泄漏，关键要在发现有内存泄漏的时候能用好的测试工具迅速定位问题的所在。市场上已有几种专业检查Java 内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java 程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根据这些信息判断程序是否有内存泄漏问题。这些工具包括Optimizeit Profiler、JProbe Profiler、JinSight、Rational 公司的Purify 等。

摩根Java面试准备要点

Reference Counting(引用计数）

跟踪收集器

Mark-Sweep Collector(标记–清除收集器）

Copying Collector(复制收集器）

Mark-Compact Collector(标记–整理收集器）

JVM的垃圾收集策略

Java面试题相关栏目本月热门文章