JAVA内存模型（转）
了解Java的同步秘密之前，先来看看JMM(Java Memory Model)。
Java被设计为跨平台的语言，在内存管理上，显然也要有一个统一的模型。而且Java语言最大的特点就是废除了指针，把程序员从痛苦中解脱出来，不用再考虑内存使用和管理方面的问题。
可惜世事总不尽如人意，虽然JMM设计上方便了程序员，但是它增加了虚拟机的复杂程度，而且还导致某些编程技巧在Java语言中失效。
JMM主要是为了规定了线程和内存之间的一些关系。对Java程序员来说只需负责用synchronized同步关键字，其它诸如与线程/内存之间进行数据交换/同步等繁琐工作均由虚拟机负责完成。如图1所示：根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是在工作内存中进行，线程之间无法相互直接访问，变量传递均需要通过主存完成。
图1 Java内存模型示例图
线程若要对某变量进行操作，必须经过一系列步骤：首先从主存复制/刷新数据到工作内存，然后执行代码，进行引用/赋值操作，最后把变量内容写回Main Memory。Java语言规范(JLS)中对线程和主存互操作定义了6个行为，分别为load，save，read，write，assign和use，这些操作行为具有原子性，且相互依赖，有明确的调用先后顺序。具体的描述请参见JLS第17章。
我们在前面的章节介绍了synchronized的作用，现在，从JMM的角度来重新审视synchronized关键字。
假设某条线程执行一个synchronized代码段，其间对某变量进行操作，JVM会依次执行如下动作：
(1) 获取同步对象monitor (lock)
(2) 从主存复制变量到当前工作内存 (read and load)
(3) 执行代码，改变共享变量值 (use and assign)
(4) 用工作内存数据刷新主存相关内容 (store and write)
(5) 释放同步对象锁 (unlock)
可见，synchronized的另外一个作用是保证主存内容和线程的工作内存中的数据的一致性。如果没有使用synchronized关键字，JVM不保证第2步和第4步会严格按照上述次序立即执行。因为根据JLS中的规定，线程的工作内存和主存之间的数据交换是松耦合的，什么时候需要刷新工作内存或者更新主内存内容，可以由具体的虚拟机实现自行决定。如果多个线程同时执行一段未经synchronized保护的代码段，很有可能某条线程已经改动了变量的值，但是其他线程却无法看到这个改动，依然在旧的变量值上进行运算，最终导致不可预料的运算结果。
这一节我们要讨论的是一个让Java丢脸的话题：DCL失效。在开始讨论之前，先介绍一下LazyLoad，这种技巧很常用，就是指一个类包含某个成员变量，在类初始化的时候并不立即为该变量初始化一个实例，而是等到真正要使用到该变量的时候才初始化之。
例如下面的代码：
代码1
图2
现在Thread-1构造了Resource实例，初始化过程中改动了obj的一些内容。退出同步代码段后，因为采取了同步机制，Thread-1所做的改动都会反映到主存中。接下来Thread-2获得了新的Resource实例变量res，由于没有使用synchronized保护所以Thread-2不会进行刷新工作内存的操作。假如之前Thread-2的工作内存中已经有了obj实例的一份拷贝，那么Thread-2在对obj执行use操作的时候就不会去执行load操作,这样一来就无法看到Thread-1对obj的改变，这显然会导致错误的运算结果。此外，Thread-1在退出同步代码段的时刻对ref和obj执行的写入主存的操作次序也是不确定的，所以即使Thread-2对obj执行了load操作，也有可能只读到obj的初试状态的数据。(注：这里的load/use均指JMM定义的操作)
有很多人不死心，试图想出了很多精妙的办法来解决这个问题，但最终都失败了。事实上，无论是目前的JMM还是已经作为JSR提交的JMM模型的增强，DCL都不能正常使用。在William Pugh的论文《Fixing the java Memory Model》中详细的探讨了JMM的一些硬伤，更尝试给出一个新的内存模型，有兴趣深入研究的读者可以参见文后的参考资料。
如果你设计的对象在程序中只有一个实例，即singleton的，有一种可行的解决办法来实现其LazyLoad：就是利用类加载器的LazyLoad特性。代码如下：
图3 Concurrent包Sync接口类关系图
Semaphore：和前面介绍的代码类似，可用于pool类实现资源管理限制。提供了acquire()方法允许在设定时间内尝试锁定信号量，若超时则返回false。
Mutex：和Java的synchronized类似，与之不同的是，synchronized的同步段只能限制在一个方法内，而Mutex对象可以作为参数在方法间传递，所以可以把同步代码范围扩大到跨方法甚至跨对象。
NullSync：一个比较奇怪的东西，其方法的内部实现都是空的，可能是作者认为如果你在实际中发现某段代码根本可以不用同步，但是又不想过多改动这段代码，那么就可以用NullSync来替代原来的Sync实例。此外，由于NullSync的方法都是synchronized，所以还是保留了“内存壁垒”的特性。
ObservableSync：把sync和observer模式结合起来，当sync的方法被调用时，把消息通知给订阅者，可用于同步性能调试。
TimeoutSync：可以认为是一个adaptor，其构造函数如下：
public TimeoutSync(Sync sync, long timeout){…}
具体上锁的代码靠构造函数传入的sync实例来完成，其自身只负责监测上锁操作是否超时，可与SyncSet合用。
Channel接口： 代表一种具备同步控制能力的容器，你可以从中存放/读取对象。不同于JDK中的Collection接口，可以把Channel看作是连接对象构造者(Producer)和对象使用者(Consumer)之间的一根管道。如图所示：
图4 Concurrent包Channel接口示意图
通过和Sync接口配合，Channel提供了阻塞式的对象存取方法（put/take）以及可设置阻塞等待时间的offer/poll方法。实现Channel接口的类有LinkedQueue，BoundedLinkedQueue，BoundedBuffer，BoundedPriorityQueue，SynchronousChannel，Slot等。
图5 Concurrent包Channel接口部分类关系图
使用Channel我们可以很容易的编写具备消息队列功能的代码，示例如下：
代码4
?
}
public TestChannel() { // start background thread
Runnable logger = new Runnable () {
public void run() {
try {
for (; ; )
System .out.println( "Logger: " + msgQ.take());
}
catch ( InterruptedException ie) {}
}
};
new Thread (logger).start();
}
}
Excutor/ThreadFactory接口: 把相关的线程创建/回收/维护/调度等工作封装起来，而让调用者只专心于具体任务的编码工作（即实现Runnable接口），不必显式创建Thread类实例就能异步执行任务。
使用Executor还有一个好处，就是实现线程的“轻量级”使用。前面章节曾提到，即使我们实现了Runnable接口，要真正的创建线程，还是得通过new Thread()来完成，在这种情况下，Runnable对象(任务)和Thread对象(线程)是1对1的关系。如果任务多而简单，完全可以给每条线程配备一个任务队列，让Runnable对象(任务)和Executor对象变成n:1的关系。使用了Executor，我们可以把上面两种线程策略都封装到具体的Executor实现中，方便代码的实现和维护。
具体的实现有: PooledExecutor，ThreadedExecutor，QueuedExecutor，FJTaskRunnerGroup等
类关系图如下：
图6 Concurrent包Executor/ThreadFactory接口部分类关系图
下面给出一段代码，使用PooledExecutor实现一个简单的多线程服务器
代码5
?
package org.javaresearch.j2seimproved.thread;
import java.net.*;
import EDU.oswego.cs.dl.util.concurrent.*;
public class TestExecutor {
public static void main( String [] args) {
PooledExecutor pool =
new PooledExecutor( new BoundedBuffer(10), 20);
pool.createThreads(4);
try {
ServerSocket socket = new ServerSocket (9999);
for (; ; ) {
final Socket connection = socket.accept();
pool.execute( new Runnable () {
public void run() {
new Handler ().process(connection);
}
});
}
}
catch ( Exception e) {} // die
}
static class Handler {
void process( Socket s){
}
}
}
