Java线程/内存模子的缺陷和加强

副标题#e#

Java在语言条理上实现了对线程的支持。它提供了Thread/Runnable/ThreadGroup等一系列封装的类和接口，让措施员可以高效的开拓Java多线程应用。为了实现同步，Java提供了synchronize要害字以及object的wait()/notify()机制，但是在简朴易用的背后，应藏着更为巨大的玄机，许多问题就是由此而起。

一、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掩护的代码段，很有大概某条线程已经窜改了变量的值，可是其他线程却无法看到这个窜改，依然在旧的变量值长举办运算，最终导致不行预料的运算功效。

#p#副标题#e#

二、DCL失效

这一节我们要接头的是一个让Java难看的话题：DCL失效。在开始接头之前，先先容一下LazyLoad，这种能力很常用，就是指一个类包括某个成员变量，在类初始化的时候并不当即为该变量初始化一个实例，而是比及真正要利用到该变量的时候才初始化之。

譬喻下面的代码：

代码1

class Foo
{
　 private Resource res = null;
　 public Resource getResource()
　 {
　　 if (res == null) res = new Resource();
　　 return res;
　 }
}

由于LazyLoad可以有效的淘汰系统资源耗损，提高措施整体的机能，所以被遍及的利用，连Java的缺省类加载器也回收这种要领来加载Java类。

在单线程情况下，一切都相安无事，但假如把上面的代码放到多线程情况下运行，那么就大概会呈现问题。假设有2条线程，同时执行到了if(res == null)，那么很有大概res被初始化2次，为了制止这样的Race Condition，得用synchronized要害字把上面的要领同步起来。代码如下：

代码2

Class Foo
{
　 Private Resource res = null;
　 Public synchronized Resource getResource()
　 {
　　 If (res == null) res = new Resource();
　　 return res;
　 }
}

此刻Race Condition办理了，一切都很好。

N天事后，勤学的你偶尔看了一本Refactoring的魔书，深深为之冲动，筹备本身实验这重构一些以前写过的措施，于是找到了上面这段代码。你已经不再是以前的Java菜鸟，深知synchronized过的要领在速度上要比未同步的要领慢上100倍，同时你也发明，只有第一次挪用该要领的时候才需要同步，而一旦res初始化完成，同步完全没须要。所以你很快就把代码重组成了下面的样子：

#p#分页标题#e#

代码3

Class Foo
{
　 Private Resource res = null;
　 Public Resource getResource()
　 {
　　 If (res == null)
　　 {
　　　 synchronized(this)
　　　 {
　　　　 if(res == null)
　　　　 {
　　　　　 res = new Resource();
　　　　 }
　　　 }
　　 }
　　 return res;
　 }
}

这种看起来很完美的优化能力就是Double-Checked Locking。可是很遗憾，按照Java的语言类型，上面的代码是不行靠的。

#p#副标题#e#

造成DCL失效的原因之一是编译器的优化会调解代码的序次。只要是在单个线程环境下执行功效是正确的，就可以认为编译器这样的“自作主张的调解代码序次”的行为是正当的。JLS在某些方面的划定较量自由，就是为了让JVM有更多余地举办代码优化以提高执行效率。而此刻的CPU大多利用超流水线技能来加速代码执行速度，针对这样的CPU，编译器采纳的代码优化的要领之一就是在调解某些代码的序次，尽大概担保在措施执行的时候不要让CPU的指令流水线断流，从而提高措施的执行速度。正是这样的代码调解会导致DCL的失效。为了进一步证明这个问题，引用一下《DCL Broken Declaration》文章中的例子：

设一行Java代码：

Objects[i].reference = new Object();

颠末Symantec JIT编译器编译过今后，最终会酿成如下汇编码在呆板中执行：

0206106A mov 　eax,0F97E78h
0206106F call　01F6B210　　　　　　　;为Object申请内存空间
　　　　　　　　　　　　　　　　　　 ; 返回值放在eax中
02061074 mov 　dword ptr [ebp],eax 　; EBP 中是objects[i].reference的地点
　　　　　　　　　　　　　　　　　　 ; 将返回的空间地点放入个中
　　　　　　　　　　　　　　　　　　 ; 此时Object尚未初始化
02061077 mov　 ecx,dword ptr [eax] 　　; dereference eax所指向的内容
　　　　　　　　　　　　　　　　　　　 ; 得到新建设工具的起始地点
02061079 mov 　dword ptr [ecx],100h 　　; 下面4行是内联的结构函数
0206107F mov　 dword ptr [ecx+4],200h
02061086 mov 　dword ptr [ecx+8],400h
0206108D mov　 dword ptr [ecx+0Ch],0F84030h

可见，Object结构函数尚未挪用，可是已经可以或许通过objects[i].reference得到Object工具实例的引用。

假如把代码放到多线程情况下运行，某线程在执行到该行代码的时候JVM可能操纵系统举办了一次线程切换，其他线程显然会发明msg工具已经不为空，导致Lazy load的判定语句if(objects[i].reference == null)不创立。线程认为工具已经成立乐成，随之大概会利用工具的成员变量可能挪用该工具实例的要领，最终导致不行预测的错误。

原因之二是在共享内存的SMP机上，每个CPU有本身的Cache和寄存器，共享同一个系统内存。所以CPU大概会动态调解指令的执行序次，以更好的举办并行运算而且把运算功效与主内存同步。这样的代码序次调解也大概导致DCL失效。追念一下前面临Java内存模子的先容，我们这里可以把Main Memory看作系统的物理内存，把Thread Working Memory认为是CPU内部的Cache和寄存器，没有synchronized的掩护，Cache和寄存器的内容就不会实时和主内存的内容同步，从而导致一条线程无法看到另一条线程对一些变量的窜改。

团结代码3来举例说明，假设Resource类的实现如下：

Class Resource{ Object obj;}

即Resource类有一个obj成员变量引用了Object的一个实例。假设2条线程在运行，其状态用如下简化图暗示：

图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界说的操纵)

#p#分页标题#e#

有许多人不死心，试图想出了许多精妙的步伐来办理这个问题，但最终都失败了。事实上，无论是今朝的JMM照旧已经作为JSR提交的JMM模子的加强，DCL都不能正常利用。在William Pugh的论文《Fixing the Java Memory Model》中具体的探讨了JMM的一些硬伤，更实验给出一个新的内存模子，有乐趣深入研究的读者可以拜见文后的参考资料。

假如你设计的工具在措施中只有一个实例，即singleton的，有一种可行的办理步伐来实现其LazyLoad：就是操作类加载器的LazyLoad特性。代码如下：

Class ResSingleton {public static Resource res = new Resource();}

这里ResSingleton只有一个静态成员变量。当第一次利用ResSingleton.res的时候，JVM才会初始化一个Resource实例，而且JVM会担保初始化的功效实时写入主存，能让其他线程看到，这样就乐成的实现了LazyLoad。

除了这个步伐以外，还可以利用ThreadLocal来实现DCL的要领，可是由于ThreadLocal的实现效率较量低，所以这种办理步伐会有较大的机能损失，有乐趣的读者可以参考文后的参考资料。

最后要说明的是，对付DCL是否有效，小我私家认为更多的是一种带有学究气的揣度和接头。而从纯理论的角度来看，存取任何大概共享的变量（工具引用）都需要同步掩护，不然都有大概堕落，可是随处用synchronized又会增加死锁的产生几率，薄命的措施员怎么来办理这个抵牾呢？事实上，在许多Java开源项目（好比Ofbiz/Jive等）的代码中都能找到利用DCL的证据，我在详细的实践中也没有遇到过因DCL而产生的措施异常。小我私家的偏好是：不妨先斗胆利用DCL，等呈现问题再用synchronized慢慢解除之。也许有人偏于守旧，认为不变名列前茅，那就不妨先用synchronized同步起来，我想这是一个见仁见智的问题，并且得针对详细的项目详细阐明后才气抉择。尚有一个步伐就是写一个测试案例来测试一下系统是否存在DCL现象，附带的光盘中提供了这样一个例子，感乐趣的读者可以自行编译测试。不管功效奈何，这样的接头有助于我们更好的认识JMM，养成用多线程的思路去阐明问题的习惯，提高我们的措施设计本领。

#p#副标题#e#

三、Java线程同步加强包

相信你已经相识了Java用于同步的3板斧：synchronized/wait/notify，它们简直简朴而有效。可是在某些环境下，我们需要越发巨大的同步东西。有些简朴的同步东西类，诸如ThreadBarrier，Semaphore，ReadWriteLock等，可以本身编程实现。此刻要先容的是牛人Doug Lea的Concurrent包。这个包专门为实现Java高级并行措施所开拓，可以满意我们绝大部门的要求。更令人欢快的是，这个包果真源代码，可自由下载。且在JDK1.5中该包将作为SDK一部门提供应Java开拓人员。

Concurrent Package提供了一系列根基的操纵接口，包罗sync，channel，executor,barrier,callable等。这里将对前三种接口及其部门派生类举办简朴的先容。

sync接口：专门认真同步操纵，用于替代Java提供的synchronized要害字，以实现越发机动的代码同步。其类干系图如下：

图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接口示意图

#p#分页标题#e#

通过和Sync接口共同，Channel提供了阻塞式的工具存取要领（put/take）以及可配置阻塞期待时间的offer/poll要领。实现Channel接口的类有LinkedQueue，BoundedLinkedQueue，BoundedBuffer，BoundedPriorityQueue，SynchronousChannel，Slot等。

图5 Concurrent包Channel接口部门类干系图

#p#副标题#e#

利用Channel我们可以很容易的编写具备动静行列成果的代码，示譬喻下：

代码4

Package org.javaresearch.j2seimproved.thread;
Import EDU.oswego.cs.dl.util.concurrent.*;
public class TestChannel {
　 final Channel msgQ = new LinkedQueue(); //log信息行列
　 public static void main(String[] args) {
　　 TestChannel tc = new TestChannel();
　　 For(int i = 0;i < 10;i ++){
　　　 Try{
　　　　 tc.serve();
　　　　 Thread.sleep(1000);
　　　 }catch(InterruptedException ie){
　　 }
　 }
}
public void serve() throws InterruptedException {
　 String status = doService();
　 //把doService()返回状态放入Channel，靠山logger线程自动读取之
　 msgQ.put(status);
}
private String doService() {
　 // Do service here
　 return "service completed OK! ";
}
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){ } }
}