Java™ 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量。这两种机制的提出都是为了实现代码线程的安全性。其中 Volatile 变量的同步性较差（但有时它更简单并且开销更低），而且其使用也更容易出错。在这期的 Java 理论与实践 中，Brian Goetz 将介绍几种正确使用 volatile 变量的模式，并针对其适用性限制提出一些建议。
Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。

锁提供了两种主要特性：互斥（mutual exclusion） 和可见性（visibility）。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。

Volatile 变量

Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start <=end”）。

出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile 变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile 变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。

正确使用 volatile 变量的条件

您只能在有限的一些情形下使用 volatile 变量替代锁。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：

对变量的写操作不依赖于当前值。
该变量没有包含在具有其他变量的不变式中。

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

第一个条件的限制使 volatile 变量不能用作线程安全计数器。虽然增量操作（x++）看上去类似一个单独操作，实际上它是一个由读取－修改－写入操作序列组成的组合操作，必须以原子方式执行，而 volatile 不能提供必须的原子特性。实现正确的操作需要使 x 的值在操作期间保持不变，而 volatile 变量无法实现这点。（然而，如果将值调整为只从单个线程写入，那么可以忽略第一个条件。）

大多数编程情形都会与这两个条件的其中之一冲突，使得 volatile 变量不能像 synchronized 那样普遍适用于实现线程安全。清单 1 显示了一个非线程安全的数值范围类。它包含了一个不变式 —— 下界总是小于或等于上界。

清单 1. 非线程安全的数值范围类

@NotThreadSafe 
public class NumberRange {
    private int lower, upper;

    public int getLower() { return lower; }
    public int getUpper() { return upper; }

    public void setLower(int value) { 
        if (value > upper) 
            throw new IllegalArgumentException(...);
        lower = value;
    }

    public void setUpper(int value) { 
        if (value < lower) 
            throw new IllegalArgumentException(...);
        upper = value;
    }
}

这种方式限制了范围的状态变量，因此将 lower 和 upper 字段定义为 volatile 类型不能够充分实现类的线程安全；从而仍然需要使用同步。否则，如果凑巧两个线程在同一时间使用不一致的值执行 setLower 和 setUpper 的话，则会使范围处于不一致的状态。例如，如果初始状态是 (0, 5)，同一时间内，线程 A 调用 setLower(4) 并且线程 B 调用 setUpper(3)，显然这两个操作交叉存入的值是不符合条件的，那么两个线程都会通过用于保护不变式的检查，使得最后的范围值是 (4, 3) —— 一个无效值。至于针对范围的其他操作，我们需要使 setLower() 和 setUpper() 操作原子化 —— 而将字段定义为 volatile 类型是无法实现这一目的的。

性能考虑

使用 volatile 变量的主要原因是其简易性：在某些情形下，使用 volatile 变量要比使用相应的锁简单得多。使用 volatile 变量次要原因是其性能：某些情况下，volatile 变量同步机制的性能要优于锁。

很难做出准确、全面的评价，例如 “X 总是比 Y 快”，尤其是对 JVM 内在的操作而言。（例如，某些情况下 VM 也许能够完全删除锁机制，这使得我们难以抽象地比较 volatile 和 synchronized 的开销。）就是说，在目前大多数的处理器架构上，volatile 读操作开销非常低 —— 几乎和非 volatile 读操作一样。而 volatile 写操作的开销要比非 volatile 写操作多很多，因为要保证可见性需要实现内存界定（Memory Fence），即便如此，volatile 的总开销仍然要比锁获取低。

volatile 操作不会像锁一样造成阻塞，因此，在能够安全使用 volatile 的情况下，volatile 可以提供一些优于锁的可伸缩特性。如果读操作的次数要远远超过写操作，与锁相比，volatile 变量通常能够减少同步的性能开销。

正确使用 volatile 的模式

很多并发性专家事实上往往引导用户远离 volatile 变量，因为使用它们要比使用锁更加容易出错。然而，如果谨慎地遵循一些良好定义的模式，就能够在很多场合内安全地使用 volatile 变量。要始终牢记使用 volatile 的限制 —— 只有在状态真正独立于程序内其他内容时才能使用 volatile —— 这条规则能够避免将这些模式扩展到不安全的用例。

模式 #1：状态标志

也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。

很多应用程序包含了一种控制结构，形式为 “在还没有准备好停止程序时再执行一些工作”，如清单 2 所示：

清单 2. 将 volatile 变量作为状态标志使用

volatile boolean shutdownRequested;

...

public void shutdown() { shutdownRequested = true; }

public void doWork() { 
    while (!shutdownRequested) { 
        // do stuff
    }
}

很可能会从循环外部调用 shutdown() 方法 —— 即在另一个线程中 —— 因此，需要执行某种同步来确保正确实现 shutdownRequested 变量的可见性。（可能会从 JMX 侦听程序、GUI 事件线程中的操作侦听程序、通过 RMI 、通过一个 Web 服务等调用）。然而，使用 synchronized 块编写循环要比使用清单 2 所示的 volatile 状态标志编写麻烦很多。由于 volatile 简化了编码，并且状态标志并不依赖于程序内任何其他状态，因此此处非常适合使用 volatile。

这种类型的状态标记的一个公共特性是：通常只有一种状态转换；shutdownRequested 标志从 false 转换为 true，然后程序停止。这种模式可以扩展到来回转换的状态标志，但是只有在转换周期不被察觉的情况下才能扩展（从 false 到 true，再转换到 false）。此外，还需要某些原子状态转换机制，例如原子变量。

模式 #2：一次性安全发布（one-time safe publication）

缺乏同步会导致无法实现可见性，这使得确定何时写入对象引用而不是原语值变得更加困难。在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。（这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象）。

实现安全发布对象的一种技术就是将对象引用定义为 volatile 类型。清单 3 展示了一个示例，其中后台线程在启动阶段从数据库加载一些数据。其他代码在能够利用这些数据时，在使用之前将检查这些数据是否曾经发布过。

清单 3. 将 volatile 变量用于一次性安全发布

public class BackgroundFloobleLoader {
    public volatile Flooble theFlooble;

    public void initInBackground() {
        // do lots of stuff
        theFlooble = new Flooble();  // this is the only write to theFlooble
    }
}

public class SomeOtherClass {
    public void doWork() {
        while (true) { 
            // do some stuff...
            // use the Flooble, but only if it is ready
            if (floobleLoader.theFlooble != null) 
                doSomething(floobleLoader.theFlooble);
        }
    }
}

如果 theFlooble 引用不是 volatile 类型，doWork() 中的代码在解除对 theFlooble 的引用时，将会得到一个不完全构造的 Flooble。

该模式的一个必要条件是：被发布的对象必须是线程安全的，或者是有效的不可变对象（有效不可变意味着对象的状态在发布之后永远不会被修改）。volatile 类型的引用可以确保对象的发布形式的可见性，但是如果对象的状态在发布后将发生更改，那么就需要额外的同步。

模式 #3：独立观察（independent observation）

安全使用 volatile 的另一种简单模式是：定期 “发布” 观察结果供程序内部使用。例如，假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。

使用该模式的另一种应用程序就是收集程序的统计信息。清单 4 展示了身份验证机制如何记忆最近一次登录的用户的名字。将反复使用 lastUser 引用来发布值，以供程序的其他部分使用。

清单 4. 将 volatile 变量用于多个独立观察结果的发布

public class UserManager {
    public volatile String lastUser;

    public boolean authenticate(String user, String password) {
        boolean valid = passwordIsValid(user, password);
        if (valid) {
            User u = new User();
            activeUsers.add(u);
            lastUser = user;
        }
        return valid;
    }
} 

该模式是前面模式的扩展；将某个值发布以在程序内的其他地方使用，但是与一次性事件的发布不同，这是一系列独立事件。这个模式要求被发布的值是有效不可变的 —— 即值的状态在发布后不会更改。使用该值的代码需要清楚该值可能随时发生变化。

模式 #4：“volatile bean” 模式

volatile bean 模式适用于将 JavaBeans 作为“荣誉结构”使用的框架。在 volatile bean 模式中，JavaBean 被用作一组具有 getter 和/或 setter 方法 的独立属性的容器。volatile bean 模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。

在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通 —— 除了获取或设置相应的属性外，不能包含任何逻辑。此外，对于对象引用的数据成员，引用的对象必须是有效不可变的。（这将禁止具有数组值的属性，因为当数组引用被声明为 volatile 时，只有引用而不是数组本身具有 volatile 语义）。对于任何 volatile 变量，不变式或约束都不能包含 JavaBean 属性。清单 5 中的示例展示了遵守 volatile bean 模式的 JavaBean：

清单 5. 遵守 volatile bean 模式的 Person 对象

@ThreadSafe
public class Person {
    private volatile String firstName;
    private volatile String lastName;
    private volatile int age;

    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public int getAge() { return age; }

    public void setFirstName(String firstName) { 
        this.firstName = firstName;
    }

    public void setLastName(String lastName) { 
        this.lastName = lastName;
    }

    public void setAge(int age) { 
        this.age = age;
    }
}

volatile 的高级模式

前面几节介绍的模式涵盖了大部分的基本用例，在这些模式中使用 volatile 非常有用并且简单。这一节将介绍一种更加高级的模式，在该模式中，volatile 将提供性能或可伸缩性优势。

volatile 应用的的高级模式非常脆弱。因此，必须对假设的条件仔细证明，并且这些模式被严格地封装了起来，因为即使非常小的更改也会损坏您的代码！同样，使用更高级的 volatile 用例的原因是它能够提升性能，确保在开始应用高级模式之前，真正确定需要实现这种性能获益。需要对这些模式进行权衡，放弃可读性或可维护性来换取可能的性能收益 —— 如果您不需要提升性能（或者不能够通过一个严格的测试程序证明您需要它），那么这很可能是一次糟糕的交易，因为您很可能会得不偿失，换来的东西要比放弃的东西价值更低。

模式 #5：开销较低的读－写锁策略

目前为止，您应该了解了 volatile 的功能还不足以实现计数器。因为 ++x 实际上是三种操作（读、添加、存储）的简单组合，如果多个线程凑巧试图同时对 volatile 计数器执行增量操作，那么它的更新值有可能会丢失。

然而，如果读操作远远超过写操作，您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。清单 6 中显示的线程安全的计数器使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。

清单 6. 结合使用 volatile 和 synchronized 实现 “开销较低的读－写锁”

@ThreadSafe
public class CheesyCounter {
    // Employs the cheap read-write lock trick
    // All mutative operations MUST be done with the 'this' lock held
    @GuardedBy("this") private volatile int value;

    public int getValue() { return value; }

    public synchronized int increment() {
        return value++;
    }
}

之所以将这种技术称之为 “开销较低的读－写锁” 是因为您使用了不同的同步机制进行读写操作。因为本例中的写操作违反了使用 volatile 的第一个条件，因此不能使用 volatile 安全地实现计数器 —— 您必须使用锁。然而，您可以在读操作中使用 volatile 确保当前值的可见性，因此可以使用锁进行所有变化的操作，使用 volatile 进行只读操作。其中，锁一次只允许一个线程访问值，volatile 允许多个线程执行读操作，因此当使用 volatile 保证读代码路径时，要比使用锁执行全部代码路径获得更高的共享度 —— 就像读－写操作一样。然而，要随时牢记这种模式的弱点：如果超越了该模式的最基本应用，结合这两个竞争的同步机制将变得非常困难。

结束语

与锁相比，Volatile 变量是一种非常简单但同时又非常脆弱的同步机制，它在某些情况下将提供优于锁的性能和伸缩性。如果严格遵循 volatile 的使用条件 —— 即变量真正独立于其他变量和自己以前的值 —— 在某些情况下可以使用 volatile 代替 synchronized 来简化代码。然而，使用 volatile 的代码往往比使用锁的代码更加容易出错。本文介绍的模式涵盖了可以使用 volatile 代替 synchronized 的最常见的一些用例。遵循这些模式（注意使用时不要超过各自的限制）可以帮助您安全地实现大多数用例，使用 volatile 变量获得更佳性能。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

ConcurrentHashMap 是 Doug Lea 的 util.concurrent 包的一部分，它提供比Hashtable 或者 synchronizedMap 更高程度的并发性。而且，对于大多数成功的 get() 操作它会设法避免完全锁定，其结果就是使得并发应用程序有着非常好的吞吐量。这个月，BrianGoetz 仔细分析了 ConcurrentHashMap 的代码，并探讨 Doug Lea 是如何在不损失线程安全的情况下取得这么骄人成绩的。请在 讨论论坛上与作者及其他读者共享您对本文的一些想法（也可以在文章的顶部或底部点击 讨论来访问论坛）。
在7月份的那期 Java理论与实践（“ Concurrent collections classes”）中，我们简单地回顾了可伸缩性的瓶颈，并讨论了怎么用共享数据结构的方法获得更高的并发性和吞吐量。有时候学习的最好方法是分析专家的成果，所以这个月我们将分析 Doug Lea 的 util.concurrent 包中的 ConcurrentHashMap 的实现。JSR 133 将指定 ConcurrentHashMap 的一个版本，该版本针对 Java 内存模型（JMM）作了优化，它将包含在 JDK 1.5 的 java.util.concurrent 包中。 util.concurrent 中的版本在老的和新的内存模型中都已通过线程安全审核。

针对吞吐量进行优化

ConcurrentHashMap 使用了几个技巧来获得高程度的并发以及避免锁定，包括为不同的 hash bucket（桶）使用多个写锁和使用 JMM 的不确定性来最小化锁被保持的时间――或者根本避免获取锁。对于大多数一般用法来说它是经过优化的，这些用法往往会检索一个很可能在 map 中已经存在的值。事实上，多数成功的 get() 操作根本不需要任何锁定就能运行。（警告：不要自己试图这样做！想比 JMM 聪明不像看上去的那么容易。 util.concurrent 类是由并发专家编写的，并且在 JMM 安全性方面经过了严格的同行评审。）

多个写锁

我们可以回想一下，Hashtable（或者替代方案 Collections.synchronizedMap ）的可伸缩性的主要障碍是它使用了一个 map 范围（map-wide）的锁，为了保证插入、删除或者检索操作的完整性必须保持这样一个锁，而且有时候甚至还要为了保证迭代遍历操作的完整性保持这样一个锁。这样一来，只要锁被保持，就从根本上阻止了其他线程访问 Map，即使处理器有空闲也不能访问，这样大大地限制了并发性。

ConcurrentHashMap 摒弃了单一的 map 范围的锁，取而代之的是由 32 个锁组成的集合，其中每个锁负责保护 hash bucket 的一个子集。锁主要由变化性操作（ put() 和 remove() ）使用。具有 32 个独立的锁意味着最多可以有 32 个线程可以同时修改 map。这并不一定是说在并发地对 map 进行写操作的线程数少于 32 时，另外的写操作不会被阻塞――32 对于写线程来说是理论上的并发限制数目，但是实际上可能达不到这个值。但是，32 依然比 1 要好得多，而且对于运行于目前这一代的计算机系统上的大多数应用程序来说已经足够了。&#160

map 范围的操作

有 32 个独立的锁，其中每个锁保护 hash bucket 的一个子集，这样需要独占访问 map 的操作就必须获得所有32个锁。一些 map 范围的操作，比如说 size() 和 isEmpty()， 也许能够不用一次锁整个 map（通过适当地限定这些操作的语义），但是有些操作，比如 map 重排（扩大 hash bucket 的数量，随着 map 的增长重新分布元素），则必须保证独占访问。Java 语言不提供用于获取可变大小的锁集合的简便方法。必须这么做的情况很少见，一旦碰到这种情况，可以用递归方法来实现。

JMM概述

在进入 put() 、 get() 和 remove() 的实现之前，让我们先简单地看一下 JMM。JMM 掌管着一个线程对内存的动作（读和写）影响其他线程对内存的动作的方式。由于使用处理器寄存器和预处理 cache 来提高内存访问速度带来的性能提升，Java 语言规范（JLS）允许一些内存操作并不对于所有其他线程立即可见。有两种语言机制可用于保证跨线程内存操作的一致性―― synchronized 和 volatile。

按照 JLS 的说法，“在没有显式同步的情况下，一个实现可以自由地更新主存，更新时所采取的顺序可能是出人意料的。”其意思是说，如果没有同步的话，在一个给定线程中某种顺序的写操作对于另外一个不同的线程来说可能呈现出不同的顺序， 并且对内存变量的更新从一个线程传播到另外一个线程的时间是不可预测的。

虽然使用同步最常见的原因是保证对代码关键部分的原子访问，但实际上同步提供三个独立的功能――原子性、可见性和顺序性。原子性非常简单――同步实施一个可重入的（reentrant）互斥，防止多于一个的线程同时执行由一个给定的监视器保护的代码块。不幸的是，多数文章都只关注原子性方面，而忽略了其他方面。但是同步在 JMM 中也扮演着很重要的角色，会引起 JVM 在获得和释放监视器的时候执行内存壁垒（memory barrier）。

一个线程在获得一个监视器之后，它执行一个 读屏障（read barrier）――使得缓存在线程局部内存（比如说处理器缓存或者处理器寄存器）中的所有变量都失效，这样就会导致处理器重新从主存中读取同步代码块使用的变量。与此类似，在释放监视器时，线程会执行一个 写屏障（write barrier）――将所有修改过的变量写回主存。互斥独占和内存壁垒结合使用意味着只要您在程序设计的时候遵循正确的同步法则（也就是说，每当写一个后面可能被其他线程访问的变量，或者读取一个可能最后被另一个线程修改的变量时，都要使用同步），每个线程都会得到它所使用的共享变量的正确的值。

如果在访问共享变量的时候没有同步的话，就会发生一些奇怪的事情。一些变化可能会通过线程立即反映出来，而其他的则需要一些时间（这由关联缓存的本质所致）。结果，如果没有同步您就不能保证内存内容必定一致（相关的变量相互间可能会不一致），或者不能得到当前的内存内容（一些值可能是过时的）。避免这种危险情况的常用方法（也是推荐使用的方法）当然是正确地使用同步。然而在有些情况下，比如说在像 ConcurrentHashMap 之类的一些使用非常广泛的库类中，在开发过程当中还需要一些额外的专业技能和努力（可能比一般的开发要多出很多倍）来获得较高的性能。

ConcurrentHashMap 实现

如前所述， ConcurrentHashMap 使用的数据结构与 Hashtable 或 HashMap 的实现类似，是 hash bucket 的一个可变数组，每个 ConcurrentHashMap 都由一个 Map.Entry 元素链构成，如清单1所示。与 Hashtable 和 HashMap 不同的是， ConcurrentHashMap 没有使用单一的集合锁（collection lock），而是使用了一个固定的锁池，这个锁池形成了bucket 集合的一个分区。

清单1. ConcurrentHashMap 使用的 Map.Entry 元素

protected static class Entry implements Map.Entry {
    protected final Object key;
    protected volatile Object value;
    protected final int hash;
    protected final Entry next;
    ...
}

不用锁定遍历数据结构

与 Hashtable 或者典型的锁池 Map 实现不同， ConcurrentHashMap.get() 操作不一定需要获取与相关bucket 相关联的锁。如果不使用锁定，那么实现必须有能力处理它用到的所有变量的过时的或者不一致的值，比如说列表头指针和 Map.Entry 元素的域（包括组成每个 hash bucket 条目的链表的链接指针）。

大多并发类使用同步来保证独占式访问一个数据结构（以及保持数据结构的一致性）。 ConcurrentHashMap 没有采用独占性和一致性，它使用的链表是经过精心设计的，所以其实现可以 检测 到它的列表是否一致或者已经过时。如果它检测到它的列表出现不一致或者过时，或者干脆就找不到它要找的条目，它就会对适当的bucket 锁进行同步并再次搜索整个链。这样做在一般的情况下可以优化查找，所谓的一般情况是指大多数检索操作是成功的并且检索的次数多于插入和删除的次数。

使用不变性

不一致性的一个重要来源是可以避免得，其方法是使 Entry 元素接近不变性――除了值字段（它们是易变的）之外，所有字段都是 final 的。这就意味着不能将元素添加到 hash 链的中间或末尾，或者从 hash 链的中间或末尾删除元素――而只能从 hash 链的开头添加元素，并且删除操作包括克隆整个链或链的一部分并更新列表的头指针。所以说只要有对某个 hash 链的一个引用，即使可能不知道有没有对列表头节点的引用，您也可以知道列表的其余部分的结构不会改变。而且，因为值字段是易变的，所以能够立即看到对值字段的更新，从而大大简化了编写能够处理内存潜在过时的 Map 的实现。

新的 JMM 为 final 型变量提供初始化安全，而老的 JMM 不提供，这意味着另一个线程看到的可能是 final 字段的默认值，而不是对象的构造方法提供的值。实现必须能够同时检测到这一点，这是通过保证 Entry 中每个字段的默认值不是有效值来实现的。这样构造好列表之后，如果任何一个 Entry 字段有其默认值（零或空），搜索就会失败，提示同步 get() 并再次遍历链。

检索操作

检索操作首先为目标 bucket 查找头指针（是在不锁定的情况下完成的，所以说可能是过时的），然后在不获取 bucket 锁的情况下遍历 bucket 链。如果它不能发现要查找的值，就会同步并试图再次查找条目，如清单2所示：

清单2. ConcurrentHashMap.get() 实现

  public Object get(Object key) {
    int hash = hash(key);     // throws null pointer exception if key is null
    // Try first without locking...
    Entry[] tab = table;
    int index = hash & (tab.length - 1);
    Entry first = tab[index];
    Entry e;
    for (e = first; e != null; e = e.next) {
      if (e.hash == hash && eq(key, e.key)) {
        Object value = e.value;
        // null values means that the element has been removed
        if (value != null) 
          return value;
        else
          break;
      }
    }
    // Recheck under synch if key apparently not there or interference
    Segment seg = segments[hash & SEGMENT_MASK];
    synchronized(seg) { 
      tab = table;
      index = hash & (tab.length - 1);
      Entry newFirst = tab[index];
      if (e != null || first != newFirst) {
        for (e = newFirst; e != null; e = e.next) {
          if (e.hash == hash && eq(key, e.key)) 
            return e.value;
        }
      }
      return null;
    }
  }

删除操作

因为一个线程可能看到 hash 链中链接指针的过时的值，简单地从链中删除一个元素不足以保证其他线程在进行查找的时候不继续看到被删除的值。相反，从清单3我们可以看到，删除操作分两个过程――首先找到适当的 Entry 对象并把其值字段设为 null ，然后对链中从头元素到要删除的元素的部分进行克隆，再连接到要删除的元素之后的部分。因为值字段是易变的，如果另外一个线程正在过时的链中查找那个被删除的元素，它会立即看到一个空值，并知道使用同步重新进行检索。最终，原始 hash 链中被删除的元素将会被垃圾收集。

清单3. ConcurrentHashMap.remove() 实现

protected Object remove(Object key, Object value) {
    /*
      Find the entry, then 
        1. Set value field to null, to force get() to retry
        2. Rebuild the list without this entry.
           All entries following removed node can stay in list, but
           all preceding ones need to be cloned.  Traversals rely
           on this strategy to ensure that elements will not be
          repeated during iteration.
    */
    int hash = hash(key);
    Segment seg = segments[hash & SEGMENT_MASK];
    synchronized(seg) {
      Entry[] tab = table;
      int index = hash & (tab.length-1);
      Entry first = tab[index];
      Entry e = first;
      for (;;) {
        if (e == null)
          return null;
        if (e.hash == hash && eq(key, e.key)) 
          break;
        e = e.next;
      }
      Object oldValue = e.value;
      if (value != null && !value.equals(oldValue))
        return null;
     
      e.value = null;
      Entry head = e.next;
      for (Entry p = first; p != e; p = p.next) 
        head = new Entry(p.hash, p.key, p.value, head);
      tab[index] = head;
      seg.count--;
      return oldValue;
    }
  }

图1为删除一个元素之前的 hash 链：

图1. Hash链

图2为删除元素3之后的链：

图2. 一个元素的删除过程

插入和更新操作

put() 的实现很简单。像 remove() 一样， put() 会在执行期间保持 bucket 锁，但是由于 put() 并不是都需要获取锁，所以这并不一定会阻塞其他读线程的执行（也不会阻塞其他写线程访问别的 bucket）。它首先会在适当的 hash 链中搜索需要的键值。如果能够找到， value 字段（易变的）就直接被更新。如果没有找到，新会创建一个用于描述新 map 的新 Entry 对象，然后插入到 bucket 列表的头部。

弱一致的迭代器

由 ConcurrentHashMap 返回的迭代器的语义又不同于 ava.util 集合中的迭代器；而且它又是 弱一致的（weakly consistent）而非 fail-fast 的（所谓 fail-fast 是指，当正在使用一个迭代器的时候，如何底层的集合被修改，就会抛出一个异常）。当一个用户调用 keySet().iterator() 去迭代器中检索一组 hash 键的时候，实现就简单地使用同步来保证每个链的头指针是当前值。 next() 和 hasNext() 操作以一种明显的方式定义，即遍历每个链然后转到下一个链直到所有的链都被遍历。弱一致迭代器可能会也可能不会反映迭代器迭代过程中的插入操作，但是一定会反映迭代器还没有到达的键的更新或删除操作，并且对任何值最多返回一次。 ConcurrentHashMap 返回的迭代器不会抛出 ConcurrentModificationException 异常。

动态调整大小

随着 map 中元素数目的增长，hash 链将会变长，因此检索时间也会增加。从某种意义上说，增加 bucket 的数目和重排其中的值是非常重要的。在有些像 Hashtable 之类的类中，这很简单，因为保持一个应用到整个 map 的独占锁是可能的。在 ConcurrentHashMap 中，每次一个条目插入的时候，如果链的长度超过了某个阈值，链就被标记为需要调整大小。当有足够多的链被标记为需要调整大小以后， ConcurrentHashMap 就使用递归获取每个 bucket 上的锁并重排每个 bucket 中的元素到一个新的、更大的 hash 表中。多数情况下，这是自动发生的，并且对调用者透明。

不锁定？

要说不用锁定就可以成功地完成 get() 操作似乎有点言过其实，因为 Entry 的 value 字段是易变的，这是用来检测更新和删除的。在机器级，易变的和同步的内容通常在最后会被翻译成相同的缓存一致原语，所以这里会有 一些 锁定，虽然只是细粒度的并且没有调度，或者没有获取和释放监视器的 JVM 开销。但是，除语义之外，在很多通用的情况下，检索的次数大于插入和删除的次数，所以说由 ConcurrentHashMap 取得的并发性是相当高的。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

转载:oksonic博客 

制作工具：Eclipse3.2   MyEclipse5.0m2   Tomcat5.5.x  

一、一个简单的 web service      新建一个 web service 工程，名称为 xfire      新建一个 java 文件，名称为 Hello.java，内容如下： -------------------------------------------------------------------------------------

package com.test; 

public class Hello { 

    public String getName(String name){ 

       return "Hello world " + name; 

    } 

} 

< beans xmlns = "http://xfire.codehaus.org/config/1.0" > 

    < service > 

       < name > Hello </ name > 

       < namespace > http://www.oksonic.cn/xfire </ namespace > 

       < serviceClass > com.test.Hello </ serviceClass > 

    </ service > 

</ beans > 

< name > Hello </ name >   服务名称 
  < serviceClass > com.test.Hello </ serviceClass >   服务类 

注：我的端口已经修改为80，如果没有修改过的话请使用   http://localhost:8080/xfire/services/Hello?wsdl    

网上原有的教程中提到可以使用 http://localhost/xfire/services/ 访问，但测试时出现无法连接     页面中出现 xml 文件内容表示服务正常    

二、使用 jsr181 风格  

--------------------- 介绍 摘抄自 XFire 实战  ------------------------  

JSR 181通过标准化一个易于学习且可以快速开发的Web服务简单编程模型，从而刺激了对Web服务的采用。一直以来，J2EE开发人员要开发和部署Web服务就必须掌握相当多的信息。通过使用J2SE 5.0中的新增注释功能，Java软件源代码可以使用JSR 181注释进行注释，从而声明式地定义所需的Web服务行为。这使开发人员可以将注意力集中在Web服务的应用逻辑上而无需担心复杂的API、协议和部署描述符。   BEA官方网站有一篇 “ web服务元数据简介 ” ,对理解JSR 181规范很有帮助。   这一节的例子和上一节的例子很相似，或者通过使用java注释，比上一节的POJO稍微复杂了一点。不是说JSR 181节省了很多的配置信息吗？鄙人认为可以从这个方面来理解，正常情况下，POJO如果配置到其他webservices框架下，比如axis2、Celtix、weblogic等容器中，必然需要编写适合这些容器的配置文件，以便这些容器能够识别这个POJO类是wenservices，并根据配置文件中的比如命名空间、参数类型、web服务的方法等信息提供web服务。而通过jsr 181规范中的定义可以自动识别这些信息，这样这些信息不必在每个容器中所配置，这些容器通过java注释就可以得到这些信息，所以说jsr181在这方面进行了简化。XFire通过services.xml文件得到哪个类被定义为web服务， XFire可以通过java注释来获取web服务的相关信息。

-------------------------------------------------------------------------------------     修改 Hello.java 文件，内容如下：

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

package com.test;   
import javax.jws.WebMethod; 
import javax.jws.WebParam; i
mport javax.jws.WebResult; 
import javax.jws.WebService;   
@WebService (name= "Hello" ,serviceName= "Hello" ,        targetNamespace= "http://www.oksonic.cn/xfire" ) 
public class Hello {       
@WebMethod     
@WebResult     
public String getName( @WebParam String name){        return "Hello world " + name;     
} 
}

-------------------------------------------------------------------------------------     修改 services.xml 文件，内容如下：

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

< beans xmlns = "http://xfire.codehaus.org/config/1.0" >     
< service >        
< serviceClass > com.test.Hello </ serviceClass >        
< serviceFactory > jsr181 </ serviceFactory >     
</ service > 
</ beans > 

-------------------------------------------------------------------------------------     启动服务，现次测试，没什么变化，服务正常  

三、对 xfire 进行单元测试  

--------------------- 介绍 摘抄自 XFire 实战  ------------------------  

你不必发布到 tomcat 等容器中就可以进行测试，常用的测试类常继承 AbstractXFireTest 抽像类。 AbstractXFireSpringTest 类又实现了 AbstractXFireTest 类，AbstractXFireTest 类是 TestCase 的子类，所以你可以使用 junit 进行单元测试。

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

 新建一个 JUnit case ，这是为了让 IDE 自动增加 JUnit 相关的类库     新建一个 java 文件，名称为 HelloTest.java，此类继承 AbstractXFireSpringTest， 实现一个 createContest 方法，内容如下：

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

package test.com.test; 

import org.apache.xbean.spring.context.ClassPathXmlApplicationContext; 
import org.codehaus.xfire.spring.AbstractXFireSpringTest; 

import org.jdom.Document; 

import org.springframework.context.ApplicationContext; 

public class HelloTest extends AbstractXFireSpringTest { 

    @Override 

    protected ApplicationContext createContext() { 

       return new ClassPathXmlApplicationContext( new String[] { 

              "/org/codehaus/xfire/spring/xfire.xml" , 

              "/META-INF/xfire/services.xml" }); 

  

    } 

    public void testService() throws Exception { 

        Document wsdl = getWSDLDocument( "Hello" ); 

        printNode(wsdl); 

    } 

} 

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

为了让 createContext 方法可以找到 services.xml 文件，需要把 Web Services 目录下的 services.xml 拷贝到 src/ META-INF/xfire 目录下    

不用启动 tomcat 直接在 HelloTest.java 文件上点击鼠标右键 Run as --> Junit ... 进行测试，

结果显示绿色条，通过测试！  

关于其它的测试方法请查看《XFire实战.pdf》  

四、和 Spring 集成     新建一个 service 层接口 IHelloService，内容如下：

 ------------------------------------------------------------------------------ package com.test.services;  

 public interface IHelloService {      

public String getName(String name);    

}

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

创建接口的实现 HelloService,内容如下：

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

package com.test.services.impl;   

import com.test.services.IHelloService;   

public class HelloService implements IHelloService {       

        public String getName(String name) {        

                     return "Hello World " + name;     

        }   

}

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

 添加 spirng 框架，设置将 applicationContext.xml 文件创建到 WEB-INF 目录下    

修改 applicationContext.xml 文件，内容如下：

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

<? xml version = "1.0" encoding = "UTF-8" ?> 

<! DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd" >   

< beans >     

< bean id = " helloBean " class = "com.test.services.impl.HelloService" /> 

</ beans >

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

 在 WEB-INF 目录下新建 xfire -servlet.xml 文件，文件内容如下：

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

<? xml version = "1.0" encoding = "UTF-8" ?> 

<! DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd" > 

< beans >     

< bean  class = "org.springframework.web.servlet.handler.SimpleUrlHandlerMapping" >      

< property name = "urlMap" >

            < map > 

              <!-- 配置 service 名称和 Service Bean -->

               < entry key = "/Hello" > 

                  < ref bean = " hello " /> 

              </ entry >            

            </ map >

</ property >

</ bean >

     < bean id = " hello "        class = "org.codehaus.xfire.spring.remoting.XFireExporter" >        < property name = "serviceFactory" > 

           < ref bean = "xfire.serviceFactory" />

        </ property >

        < property name = "xfire" >

            < ref bean = "xfire" /> 

       </ property >

        < property name = "serviceBean" > 

           < ref bean = " helloBean " />

        </ property >

        < property name = "serviceClass" >

            < value > com.test.services.IHelloService </ value >

        </ property >

     </ bean >

 </ beans >

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

   注意：红色字体部份必需一r致，深红色字体部份要和 spring 的配置文件部份一致     修改 web.xml 文件，增加 spring 配置部份，修改 xfire 的名称

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

<? xml version = "1.0" encoding = "UTF-8" ?> 

< web-app xmlns = "http://java.sun.com/xml/ns/j2ee" 

    xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" version = "2.4" 

    xsi:schemaLocation = "http://java.sun.com/xml/ns/j2ee   http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" > 

    < context-param > 

       < param-name > contextConfigLocation </ param-name > 

       < param-value > 

           /WEB-INF/applicationContext.xml 

           classpath:org/codehaus/xfire/spring/xfire.xml 

       </ param-value > 

    </ context-param > 

    < listener > 

       < listener-class > 

           org.springframework.web.context.ContextLoaderListener 

       </ listener-class > 

    </ listener > 

    < servlet > 

       < servlet-name > xfire </ servlet-name > 

       < servlet-class > 

           org.springframework.web.servlet.DispatcherServlet 

       </ servlet-class > 

       < load-on-startup > 0 </ load-on-startup > 

    </ servlet > 

    < servlet-mapping > 

       < servlet-name > xfire </ servlet-name > 

       < url-pattern > /services/* </ url-pattern > 

    </ servlet-mapping > 

</ web-app > 

  一切正常，现在用一个web service测试工具进行一下测试

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

转载:作者:golden

Java 社区一直试图将 POJO 的作用发挥到极致，降低 Java 应用实现的难度，最近的尝试是将 EJB3.0 建立在 POJO 之上；另一方面，SOA 是目前 Java 社区炙手可热的名词，非常多的企业都在努力应用和实施 SOA；XFire 为这两方面的需求提供了一种魔术般的解决方式，我们很快能够发现使用 XFire 创建和发布 Web 服务可以直接基于 POJO，将烦人的继承关系和一大堆其他可能的约束丢在一边

POJO（Plain Old Java Object，简单 Java 对象）是 Java 社区中最早的成员（回想您学习 Java 时第一个兴奋的时刻，那个简单的 "Hello World！" 例子），也是最简单、最容易实现的方式。

然而现实中 Java 的发展已经远远超越了 POJO 的范围，成为面向对象技术应用中最成功的编程语言，尤其是继承、多态的应用为我们造就了一大批开发框架（如 Struts）和标准（如 EJB），随之而来的就是实现的复杂化，我们必须面对一大堆继承关系的限制。比如说：要开发一个基于 Struts 的应用，我们必须了解 Struts 特定的继承关系如 ActionForm、ValidateActionForm；要开发一个 EJB 应用，我们必须继承 EJBObject、SessionEJB 等。

为了抛开这些限制，降低 Java 应用实现的难度，Java 社区开始重新审视 POJO 的价值，试图将 POJO 的作用发挥到极致，最新的努力是 EJB3.0。Java 社区将 EJB3.0 设计为基于 POJO，而不是为他准备更多的继承关系等限制。

SOA 已经成为了目前 Java 社区中炙手可热的名词，几乎所有的软件厂商都在讨论它，为他提供解决方案和产品支持，大部分的企业也已经在企业内部实施或者正在考虑实施 SOA。

然而 SOA 在企业内的实施却不是一项简单的任务，即使抛开新建系统直接基于 SOA 架构实施的因素，要把企业已有系统纳入 SOA 框架也不是一件容易的事情。企业必须在对当前架构深入了解的基础上，对已有系统进行大规模的改造才能满足新的要求。如何经济的从原有技术架构切换到 SOA 架构成为很多企业的难题。

XFire 是 codeHaus 组织提供的一个开源框架，它构建了 POJO 和 SOA 之间的桥梁，主要特性就是支持将 POJO 通过非常简单的方式发布成 Web 服务，这种处理方式不仅充分发挥了 POJO 的作用，简化了 Java 应用转化为 Web 服务的步骤和过程，也直接降低了 SOA 的实现难度，为企业转向 SOA 架构提供了一种简单可行的方式。

XFire 目前最新的版本是 1.2.2，目前支持的特性主要包括：

• 支持将 Web 服务绑定到 POJO、XMLBeans、JAXB1.1、JAXB2.0 和 Castor；
• 支持基于 HTTP、JMS、XMPP 等多种协议访问 Web 服务；
• 支持多种 Web 服务业界重要标准如 SOAP、WSDL、Web 服务寻址（WS-Addressing）、Web 服务安全（WS-Security）等；
• 支持 JSR181，可以通过 JDK5 配置 Web 服务；
• 高性能的 SOAP 实现；
• 服务器端、客户端代码辅助生成；
• 对 Spring、Pico、Plexus 等项目的支持等。

XFire 框架目前的最新版本是 1.2.6，可以访问 xfire.codehaus.org 下载 XFire 框架的安装包，下载时请选择“全部二进制发布包（Binary Distribution in zip package）”，而不仅仅是“XFire jar 文件（Jar of all XFire modules）”。

下载完成后，我们可以将下载的 .zip 文件解压缩到任意的文件夹中（后面的章节中使用 % XFIRE_HOME % 表示 XFire 框架的安装目录），解压缩后形成的文件目录结构如下：

• api（目录）

  api 目录中是 XFire 框架中所有类（class）对应的 API 文档，为开发者使用 XFire 完成应用开发提供帮助。

• examples（目录）

  examples 目录中包含了所有随 XFire 二进制包发布的实例，包括这些实例的源代码和相关 Web 应用配置内容。

• lib（目录）

  lib 目录中包含 XFire 运行所需要的外部支持类包（.jar文件），可以根据不同项目所需的 XFire 特性选择所需要的支持类包。保守的方法是在 Web 项目中包含所有的外部支持类包（.jar文件）。

• manual（目录）

  manual 目录中包含有 XFire 框架的帮助文档，开发者可以从这些帮助文档中学习更多运用 XFire 框架实现 SOA 的知识和技巧。

• modules（目录）

  modules 目录中包含了 XFire 框架根据不同特性分别编译的二进制包文件。发布基于 XFire 框架的 Web 项目时，可以选择使用该目录下的所有 .jar 文件，也可以选择 XFire-all-1.2.6.jar 文件。

• XFire-all-1.2.6.jar

  XFire 框架的二进制包文件，包含了全部的模块（modules）。

• LICENSE.txt

  LICENSE.txt 文件中包含了 XFire 框架的授权协议。

• NOTICE.txt
• README.txt

  这两个文件中包含了 XFire 发布时的一些有用的信息。

XFire框架是一种基于Servlet技术的SOA应用开发框架，要正常运行基于XFire应用框架开发的企业应用，除了XFire框架本身之外，还需要JDK和Servlet容器的支持。

XFire 支持非常多的特性，其中不同的特性对 JDK 版本的要求有所不同，比如如果项目中选择基于 JSR181 标准发布 Web 服务，我们就需要选择 JDK5 或者以上版本，如果仅仅选择将 Web 服务绑定到最简单的 POJO，我们只需要选择 JDK1.4 版本即可。

JDK 各版本均可以在 java.sun.com 网站上下载，如何安装 JDK 请参考 SUN 公司的相关技术文档和 JDK 的帮助文档。

XFire 是一种基于 Servlet 技术的 SOA 应用开发框架，需要 Servlet 容器的支持。XFire 支持在多种 Servlet 容器中运行，包括 Websphere、Weblogic、TOMCAT 等。为了说明的简单，我们选择使用 TOMCAT（版本5.0.30）作为 XFire 的运行容器，所有配置过程和发布步骤的说明也均是针对 TOMCAT，如果读者使用 TOMCAT 之外的其它 Servlet 容器或者选择了 TOMCAT 的其它版本，下面的配置过程和步骤可能需要做出调整，请读者根据实际 Servlet 容器的帮助文档进行相应调整。

TOMCAT 各版本均可以在 tomcat.apache.org 网站上下载，如何正确安装 TOMCAT 服务器请参考 TOMCAT 服务器的帮助文档。

XFire 需要 xalan 项目的支持，然而 1.2.6 版本中并没有带有相应的 jar 文件，因此请访问 xml.apache.org，下载 xalan 项目的二进制包。

前面的章节中我们下载和安装了 XFire 安装包和所需要的支持环境，现在我们开始学习如何从零开始创建 XFire 应用开发环境。下面的所有配置过程和发布步骤均针对 TOMCAT（版本5.0.30）服务器，如果选择其它的 Servlet 容器，下面的配置过程和步骤可能需要做出调整，请读者根据实际 Servlet 容器的帮助文档进行相应调整。

1. 在 %TOMCAT_HOME%/webapps 目录下创建新的 Web 应用目录 “XFire”

   [注] 其中的 %TOMCAT_HOME% 指向 TOMCAT 的安装目录。

2. 在 ”XFire”目录下创建 ”WEB-INF”目录、
3. 在 ” WEB-INF”目录下创建 ”lib”目录和 ”classes”目录
4. 在 ” WEB-INF”目录下创建 Web 应用描述文件 ”web.xml”， ”web.xml”文件的内容见 清单 1-1。

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"	    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"	    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
         <display-name>XFire实例</display-name>
          <description>
           基于XFire框架发布Web服务的例子
       </description>
</web-app>

拷贝 %XFIRE_HOME%/lib 目录下所有文件到 “1、创建 Web 应用目录和基本元素” 中所创建的 ”lib”目录下，将 %XFIRE_HOME%/XFire-all-1.2.6.jar 文件也拷贝到 “1、创建 Web 应用目录和基本元素” 中所创建的 ”lib”目录下。将 xalan 安装包中的所有 jar 文件和所需要的支持 jar 文件拷贝到相同的 ”lib”目录下。

[注] 为了减少拷贝的 jar 文件的数目，开发者可以根据项目的需要选择需要拷贝的 jar 文件，而不是全部拷贝，如何根据需要选择拷贝合适的类包文件请访问 XFire 站点。

修改 web.xml 文件，在其中增加如下 Servlet 定义内容。

<servlet>
           <servlet-name>XFireServlet</servlet-name>
           <display-name>XFire Servlet</display-name>
            <servlet-class>	        org.codehaus.xfire.transport.http.XFireConfigurableServlet
            </servlet-class>
</servlet>
<servlet-mapping>
            <servlet-name>XFireServlet</servlet-name>
            <url-pattern>/servlet/XFireServlet/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
            <servlet-name>XFireServlet</servlet-name>
            <url-pattern>/services/*</url-pattern>
</servlet-mapping>

1. 在 “1、创建 Web 应用目录和基本元素” 中创建的 classes 目录下新建目录 ”META-INF\xfire”；
2. 在步骤 a) 中新建的 ”xfire”文件目录下创建新文件 services.xml，文件的默认内容如 清单1-2 。

	<beans xmlns="http://XFire.codehaus.org/config/1.0"></beans>

XFire 框架中，我们有两种方式将 POJO 发布成 Web 服务：

• 一种方式是直接使用 Web 服务接口和 Web 服务实现类（POJO）来发布；
• 另一种方式是基于 JSR181 标准和注释技术将被注释的 POJO 发布成 Web 服务；

下面的章节中我们将学习使用第一种方式来完成 POJO 的 Web 服务发布。我们将使用经典的 ”Hello World!”例子来演示将 POJO 发布成 Web 服务所需要的步骤，不过我们不再是简单的访问一个 Java 方法来输出 ”Hello World!”字符串，而是转为在 SOA 环境下实现：Web 服务客户端通过访问服务器端发布成 Web 服务的 POJO 获得返回的 ”Hello World!”字符串后输出到客户端的控制台上。

将 POJO 发布成 Web 服务的基本步骤如下：

1. 创建 Web 服务接口，声明该 Web 服务对外暴露的接口；
2. 创建 Web 服务实现类，为 Web 服务接口提供实现；
3. 修改 XFire 框架的服务发布文件 ---- services.xml，将 POJO 发布成 Web 服务。

下面我们通过创建 ”Hello World!”例子来具体说明如何实现这三个步骤。

要将 POJO 发布成 Web 服务，首先需要创建 Web 服务接口，在接口中声明该 Web 服务需要对外暴露的接口。

我们根据需要创建 Web 服务接口 ” HelloWorldService”，在其中声明一个 ”sayHello”方法，该方法返回 ”String ”类型的内容。” HelloWorldService”接口对应的 Java 文件代码如 清单 1-3。

package org.vivianj.xfire.pojo;
/**
 * HelloWorldService 中声明需要发布成 Web 服务的所有 Java 方法
 * HelloWorldService 作为Web服务接口
 */

public interface HelloWorldService {
/**
 * sayHello 方法声明了 Web 服务对外暴露的接口
*
 * @return 返回给客户端的字符串
*/
public String sayHello();
            }
            

创建 Web 服务实现类 ”HelloWorldServiceImpl”，它继承 ”1、创建Web服务接口 ---- HelloWorldService” 中创建的 HelloWorldService 接口，并且为它声明的 ”sayHello”方法提供具体实现： 返回字符串”Hello World!”。 ”HelloWorldServiceImpl”类对应的 Java 文件代码如 清单 1-4。

package org.vivianj.xfire.pojo;
/**
 * HelloWorldServiceImpl 中为 Web 服务接口中声明的所有 Java 方法提供具体实现
 * HelloWorldServiceImpl 作为 Web 服务的实现类
 */
public class HelloWorldServiceImpl implements HelloWorldService {
/*
 * sayHello 方法为 HelloWorldService 服务接口定义的 sayHello 方法提供具体实现
 *
 * @see org.vivianj.XFire.pojo.HelloWorldService#sayHelloToXFire()
 */
public String sayHello() {
            return "Hello World!";
 }            

}
            

我们可以在 WEB-INF\classes\META-INF\XFire\services.xml 文件中的 <beans …> 和 </beans> 元素中间加入如下的 xml 内容将上面创建的 HelloWorldService 发布成 Web 服务。

<service>
    <name>HelloWorldService</name>
            <namespace>http://vivianj.org/HelloWorldService</namespace>
            <serviceClass>
                        org.vivianj.xfire.pojo.HelloWorldService
            </serviceClass>
            <implementationClass>
                        org.vivianj.xfire.pojo.HelloWorldServiceImpl
            </implementationClass>
</service>
            

其中各元素的功能如下：

• service

  service 标签和它所包含的 xml 内容为发布成 Web 服务的 POJO 提供完整的描述。

• name

  Web 服务被发布时所采用的唯一名称。

• namespace

  Web 服务发布时所使用的命名空间。

• serviceClass

  Web 服务接口类的全名，包括包名和类名。

• implemetationClass

  Web 服务实现类的全名，包括包名和类名。

更多 service 元素的子元素和它们的用法请参考 XFire 站点。

通过上面的三个步骤，我们已经将新创建的HelloWorldService发布成了Web服务，我们可以使用下面的步骤测试一下创建的Web服务是否能够正常运行：

1. 编译上面的步骤中创建的 Java 接口和类；
2. 启动 TOMCAT 服务器。
3. 等 TOMCAT 服务器完全启动后，打开浏览器，在地址栏中输入 http://localhost:8080/XFire/services/HelloWorldService?wsdl。

其中 HelloWorldServcie 是配置文件中 service\name 元素所定义的内容，”wsdl”参数表示查看该 Web 服务的 WSDL（Web服务描述语言）文件。

如果浏览器中出现如下图所示类似的内容，表示 Web 服务发布成功，我们可以编写客户端访问该 Web 服务从服务器获取返回字符串，本文下载资源中提供的下载文件中包含有可供参考的客户端类 org.vivianj.xfire.pojo.client.HelloWorldServiceClient。

如果浏览器中出现错误提示，请按照上面的步骤和说明检查已经完成的开发、配置过程是否完全正确。

本文中作者首先讲解了 XFire 框架的主要特性，XFire 框架的运行环境以及基于 XFire 框架开发 SOA 应用的基本步骤，并且借助于 SOA 环境下的 ”Hello World!”例子，详细的讲解和演示了如何基于 XFire 框架、经过简单的开发、配置步骤就将一个 POJO 类中包含的方法发布成Web服务。从 ”Hello World!”例子实现的过程中，我们可以发现 XFire 框架最大化的发挥了 POJO 的作用，减少了 SOA 实施时对框架本身的依赖，降低了 SOA 实施的难度，企业实施 SOA 时并不需要增加太多的投入就可以实现目标。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

JCS在一般用在，查询数据库比较频繁，每次查询的结果都差不多，这样讲数据进行缓冲，可以 减轻数据库负担：
下面举个例子：
在一个点击量比较频繁的页面，调用一个数据列表，每个用户进去在某一时间段数据都一样，这时将考虑将数据进行缓冲。
1、配置 JCS cache.ccf 文件，将该文件直接放到src根目录下即可：

2、程序中这样应用即可：

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

1、关于JCS
JCS是Jakarta的项目Turbine的子项目。它是一个复合式的缓冲工具。可以将对象缓冲到内存、硬盘。具有缓冲对象时间过期设定。还可以通过JCS构建具有缓冲的分布式构架，以实现高性能的应用。 对于一些需要频繁访问而每访问一次都非常消耗资源的对象，可以临时存放在缓冲区中，这样可以提高服务的性能。而JCS正是一个很好的缓冲工具。缓冲工具对于读操作远远多于写操作的应用性能提高非常显著。
2、JCS的特性
JCS除了简单的将对象缓冲在内存中以外，还具有几个特性，以适应企业级缓冲系统的需要。这些特性包括时间过期、索引式硬盘缓冲、并行式的分布缓冲等。
3、内存缓冲
JCS现在支持两种内存缓冲算法LRU和MRU。通常都是使用LRU算法。 org.apache.stratum.jcs.engine.memory.lru.LRUMemoryCache 使用内存缓冲区需要定义缓冲区大小，当超过缓冲区限制时，会将缓冲内容抛弃掉。如果有配硬盘缓冲，则将挤出来的缓冲内容写入硬盘缓冲区。
4、时间过期
JCS对于缓冲的对象，可以设定缓冲过期时间，一个对象在缓冲区中停留的时间超过这个时间，就会被认为是“不新鲜”而被放弃。
5、索引式硬盘缓冲
一方面，为了避免缓冲区过大，撑爆虚拟机的内存，另一方面又希望能够缓冲更多的对象，JCS可以将超出缓冲区大小的对象缓存到硬盘上。配置上也比较方便，只需要指定缓冲临时文件的存放目录位置。硬盘缓冲将缓冲对象的内容写到文件上，但是将访问索引保存在内存中，因此也能够达到尽可能高的访问效率。
6、并行式的分布缓冲(Lateral)
通常，将对象缓冲在内存中，一方面提高了应用的性能，而另一方面却使得应用不可以分布式发布。因为假设一个应用配置在两台服务器上并行运行，而两台服务器单独缓冲，则很容易导致两个缓冲区内容出现版本上的不一致而出错。一个机器上修改了数据，这个动作会影响到本地内存缓冲区和数据库服务器，但是却不会通知到另一台服务器，导致另一台上缓冲的数据实际上已经无效了。 并行式的分布缓冲就是解决这个问题。可以通过配置，将几台服务器配成一个缓冲组，组内每台服务器上有数据更新，会横向将更新的内容通过TCP/IP协议传输到其他服务器的缓冲层，这样就可以保证不会出现上述情况。这个的缺点是如果组内的并行的服务器数量增大后，组内的数据传输量将会迅速上升。这种方案适合并行服务器的数量比较少的情况。
7、Client/Server式的缓冲(Remote)
客户/服务端式的缓冲集群。这种方式支持一个主服务器和最高达到256个客户端。客户端的缓冲层会尝试连接主服务器，如果连接成功，就会在主服务器上注册。每个客户端有数据更新，就会通知到主服务器，主服务器会将更新通知到除消息来源的客户端以外的所有的客户端。 每个客户端可以配置超过一个服务器，第一个服务器是主服务器，如果与第一个服务器连接失败，客户端会尝试与备用的服务器连接，如果连接成功，就会通过备用服务器与其他客户端对话，同时会定期继续尝试与主服务器取得连接。如果备用服务器也连接失败，就会按照配置顺序尝试与下一个备用服务器连接。 这种方式下，更新通知是一种轻量级的，一个机器上的数据更新，不会把整个数据传输出去，而只是通知一个ID，当远程的其他机器收到更新通知后，就会把对应ID的缓冲对象从本地的内存缓冲区中移除，以保证不会在缓冲区内出现错误数据。 这种构造需要分别配置客户端和服务器，配置比较麻烦。
8、配置方法
JCS的好处之一，就是应用在开发的时候，可以不用去构思底层的缓冲配置构架。同一个应用，只需要修改配置，就可以改变缓冲构架，不需要修改应用的源代码。配置方法也比较简单，就是修改配置文件cache.ccf。这个文件放置在WEB-INF/classes目录下。配置格式类似log4j的配置文件格式。下面介绍一下使用各种缓冲结构的配置方法。
9、内存缓冲
#WEB-INF/classes/cache.ccf(以下内容不要换行) 

#定义一个硬盘缓冲区产生器(Factory)，取名为DC 

java 代码
jcs.auxiliary.DC=org.apache.stratum.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory    
jcs.auxiliary.DC.attributes=org.apache.stratum.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes jcs.auxiliary.DC.attributes.DiskPath=g:/dev/jakarta-turbine-stratum/raf   

#这里其实就是指明了缓冲文件存放到那里去。 

然后，做以下修改 jcs.default=DC 这样，所有未特别指定属性的缓冲区都会自己使用一个硬盘缓冲区，缓冲文件会以缓冲区的名字来命名。存放在指定的目录下

12、横向式的并行缓冲

并行式的配置如下 ：

 这里的配置是在41,129,221三台机器上实现并行缓冲的。 大家都在1121端口上监听，同时与另外两台机器连接。如果连接失败，就会等待一个时间后再连接一次，直到连接成功为止。三台机器中任意一台的缓冲区发生更新，比如put和remove动作，就会把更新传递给另外两台。

13、单独指明某个缓冲区的属性

如果，针对某个缓冲区，比如叫做TestCache1，需要单独配置属性，可以如下配置。

14、system.GroupIdCache

JCS文档中指出配置以下内容会比较好。

这可能是JCS自己的组管理体系上的缓冲区。

15、Client/Server式的缓冲(Remote)

这种构架需要单独配置客户端和服务端

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

MyEclipse 6.0.1 注册码

Subscriber: administrator
Subscription Code: nLR7ZL-655342-54657656405281154

注册后：

Subscriber: administrator
Product ID: E2MY (MyEclipse Standard Subscription)
License version: 1.0
Full Maintenance Included
Subscription expiration date (YYYYMMDD): 20091021
Number of licenses: 897

下面把 6.0GA / M1 和 5.5GA 版本的“注册信息”“注册码”“破解”给大家：

Subscriber:
Subscriber Code: jLR8ZC-655355-5450765457039125
或者
Subscriber:
Subscriber Code: jLR7ZL-655355-5450755330522962

适用于早期的 5.5 M2 版本的：

Subscriber:
Subscriber Code: jLR8ZC-956-55-5467865833584547

适用于早期的 5.1.1 GA 和 5.5 M1 版本的：

Subscriber:
Subscriber Code: jLR8ZC-444-55-4467865481680090

注册成功后会发现：

Subscriber:
Product ID: E3MP (MyEclipse Professional Subscription)
License version: x.x
Full Maintenance Included
Subscription expiration date (YYYYMMDD): 20090520
Number of licenses: 800

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

看到墙角边总有这样的植物
 像爬山虎一样生命力旺盛
 只要有方向,它就一直努力地往上爬
 给自己找一个方向，一个目标
 即使前行的道路充满艰辛，也不要放弃，也一定要坚持

一直牢牢记得,厚积而薄发
 积累的过程常常让自己失去信心，看不到未来
 也许只是等待一个时机
 寻找一个突破口。喷发的是积聚已久的力量。

总会有疲惫的时候
 总会有想要不管不顾的时候
 于是会渴望一个世外桃源一样的屋子
 即使简陋不堪,只要能逃离这纷扰凡尘

忧伤有时是一个人的本质,无法避免
 表面再快乐的人其实也有不为人知的脆弱
 只是需要一个时间。属于一个人纯粹的时间。收拾心情
 不会让别人看到难过的泪水,笑容依然灿烂。

人这一生都在寻觅。寻觅相知的朋友。寻觅相亲的爱人
 有些温暖是别人给予
 同样也要自己真诚付出
 两个人可以撑起一把大伞
 风大雨大，一路同行。到底温暖几许

生命如草芥
 脆弱时候不堪一击
 任人践踏
 顽强时候，即便小小夹缝
 依然可以青葱蓬勃

幸好这世界总有这样的绿色
 在灰暗的墙头昂扬
 平时不过不经意的抬头一瞥
 也会感染到这样的活力

发明了飞机
 人类实现飞翔的梦想
 但是依然渴望可以有一双翅膀,一双梦想的翅膀
 梦有多大。天有多高。心有多宽
 为自己按上一双翅膀

我们会遇到各式各样的打击与阻力
 小小的支持与鼓励。也会是一股强大的力量
 但常常在需要这股力量的时候,却只是孤单一人
 于是学着,自己给自己这样的力量与支持
 哪怕全世界冷眼旁观。也请支撑下去。守得云开见月明

 相信自己,相信自己握在手中的每一件东西
 有些东西看不见。并不代表它不存在
 懂得把握的人。总有一天登上他自己心目中的顶峰

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

文章来源：http://it.mr-w.cn/n/200603/24/n20060324_9592.shtml

引言

　　期待已久的EJB3.0规范在最近发布了它的初稿。在本文中将对新的规范进行一个概要性的介绍，包括新增的元数据支持，EJBQL的修改，实体Bean模型访问bean上下文的新方法和运行时环境等等。作者还讨论了EJB在未来要作出的调整以及EJB3.0与其他开发规范之间的关系。

　　开始

　　无论如何由于EJB的复杂性使之在J2EE架构中的表现一直不是很好。EJB大概是J2EE架构中唯一一个没有兑现其能够简单开发并提高生产力的组建。 EJB3.0规范正尝试在这方面作出努力以减轻其开发的复杂性。EJB3.0减轻了开发人员进行底层开发的工作量，它取消或最小化了很多（以前这些是必须实现）回调方法的实现，并且降低了实体Bean及O/R映射模型的复杂性。

　　在本文中，我首先会介绍EJB