Java并发——DCL问题

转自:http://www.iteye.com/topic/875420

如果你搜索网上分析dcl为什么在java中失效的原因,都会谈到编译器会做优化云云,我相信大家看到这个一定会觉得很沮丧、很无助,对自己写的程序很没信心。我很理解这种感受,因为我也经历过,这或许是为什么网上一直有人喜欢谈dcl的原因。如果放在java5之前,从编译器的角度去解释dcl也无可厚非,在java5的JMM(内存模型)已经得到很大的修正,如果到现在还只能从编译器的角度去解释dcl,那简直就在污辱java,要知道java的最大优势就是只需要考虑一个平台。你可以完全无视网上绝大多数关于dcl的讨论,很多时候他们自己都说不清楚,除Doug Lea等几个大牛,我不相信谁比谁更权威。

很多人不理解dcl,不是dcl有多么复杂,恰恰相反,而是对基础掌握得不够。所以,我会先从基础讲起,然后再分析DCL。

我们都知道,当两个线程同时读写(或同时写)一个共享变量时会发生数据竞争。那我怎么才能知道发生了数据竞争呢?我需要去读取那个变量,发生数据竞争通常有两个表现:一是读取到陈旧数据,即读取到虽是曾经写入的数据,但不是最新的。二是读取到之前根本没有写入的值,也就是说读到垃圾。

数据陈旧性

为了读取到另一个线程写入的最新数据,JMM定义了一系列的规则,最基本的规则就是要利用同步。在Java中,同步的手段有synchronized和volatile两种,这里我只会涉及到syncrhonized。请大家先记住以下规则,接下来我会细讲。

规则一:必须对变量的所有写和所有读同步,才能读取到该最新的数据。

先看下面的代码:

public class A {
	private int some;
	public int another;

	public int getSome() { return some; }
	public synchronized int getSomeWithSync() { return some; }
	public void setSome(int v) { some = v; }
	public synchronized void setSomeWithSync(int v) { some = v; }
}

让我们来分析一个线程写,另一个线程读的情形,一共四种情形。初始情况都是a = new A(),暂不考虑其它线程。

情形一:读写都不同步。

Thread1 Thread2
(1) a.setSome(13)  
  (2) a.getSome()

这种情况下,即使thread1先写入some为13,thread2再读取some,它能读到13吗?在没有同步协调下,结果是不确定的。从图上看出,两个线程独立运行,JMM并不保证一个线程能够看到另一个线程写入的值。在这个例子中,就是thread2可能读到0(即some的初始值)而不是13。注意,在理论上,即使thread2在thread1写入some之后再等上一万年也还是可能读到some的初始值0,尽管这在实际几乎不可能发生。

情形二:写同步,读不同步

Thread1 Thread2
(1) a.setSomeWithSync(13)  
  (2) a.getSome()

情形三:读同步,写不同步

Thread1 Thread2
(1) a.setSome(13)  
  (2) a.getSomeWithSync()

在这两种情况下,thread1和thread2只对读或只对写some加了锁,这不起任何作用,和[情形一]一样,thread2仍有可能读到some的初始值0。从图上也可看出,thread1和thread2互相之间并没有任何影响,一方加锁并不影响另一方的继续运行。图中也显示,同步操作相当于在同步开始执行lock操作,在同步结束时执行unlock操作。

情形四:读写都同步

Thread1 Thread2
(1) a.setSomeWithSync(13)  
  (2) a.getSomeWithSync()

在情形四中,thread1写入some时,thread2等待thread1写入完成,并且它能看到thread1对some做的修改,这时thread2保证能读到13。实际上,thread2不仅能看到thread1对some的修改,而且还能看到thread1在修改some之前所做的任何修改。说得更精确一些,就是一个线程的lock操作能看见另一线程对同一个对象unlock操作之前的所有修改,请注意图中的红色箭头。 沿着图中箭头指示方向,箭头结尾处总能看到箭头开始处操作做的修改。这样,a.some[thread2]能看见lock[thread2],lock[thread2]能看见unlock[thread1],unlock[thread1]又能看见a.some=13[thread1],即能看到some的值为13。

再来看一个稍微复杂一点的例子:

例子五

Thread1 Thread2
(1) a.another = 5  
(2) a.setSomeWithSync(13)  
  (3) a.getSomeWithSync()
(4) a.another = 7  
  (5) a.another

thread2最后会读到another的什么值呢?会不会读到another的初始值0呢,毕竟所有对another的访问都没有同步?不会。从图中很清晰地可以看出,thread2的another至少到看到thread1在lock之前写入的5,却并不能保证它能看到thread1在unlock写入的7。因此,thread2可以什么读到another的值可能5或7,但不会是0。你或许已经发现,如果去掉图中thread2读取a.some的操作,这时相当于一个空的同步块,对结论并没有任何影响。这说明空的同步块是起作用的,编译器不能擅自将空的同步块优化掉,但你在使用空的同步块应该特别小心,通常它都不是你想要的结果。另外需要注意,unlock操作和lock操作必须针对同一个对象,才能保证unlock操作能看到lock操作之前所做的修改。

例子六:不同的锁

class B {
	private Object lock1 = new Object();
	private Object lock2 = new Object();

	private int some;

	public int getSome() {
		synchronized(lock1) { return some; }
	}

	public void setSome(int v) {
		synchronized(lock2) { some = v; }
	}
}
Thread1 Thread2
(1) b.setSome(13)  
  (2) b.getSome()

在这种情况下,虽然getSome和setSome都加了锁,但由于它们是不同的锁,一个线程运行时并不能阻塞另一个线程运行。因此这里的情形和情形一、二、三一样,thread2不保证读到thread1写入的some最新值。

现在来看DCL:

例子七: DCL

public class LazySingleton {
    private int someField;

    private static LazySingleton instance;

    private LazySingleton() {
        this.someField = 201;                                 // (1)
    }

    public static LazySingleton getInstance() {
        if (instance == null) {                               // (2)
            synchronized(LazySingleton.class) {               // (3)
                if (instance == null) {                       // (4)
                    instance = new LazySingleton();           // (5)
                }
            }
        }
        return instance;                                      // (6)
    }

    public int getSomeField() {
        return this.someField;                                // (7)
    }
}

  假设thread1先调用getInstance(),由于此时还没有任何线程创建LazySingleton实例,它会创建一个实例s并返回。这是thread2再调用getInstance(),当它运行到(2)处,由于这时读instance没有同步,它有可能读到s或者null(参考情形二)。先考虑它读到s的情形,画出流程图就是下面这样的:

由于thread2已经读到s,所以getInstance()会立即返回s,这是没有任何问题,但当它读取s.someFiled时问题就发生了。 从图中可以看thread2没有任何同步,所以它可能看不到thread1写入someField的值20,对thread2来说,它可能读到s.someField为0,这就是DCL的根本问题。从上面的分析也可以看出,为什么试图修正DCL但又希望完全避免同步的方法几乎总是行不通的。

接下来考虑thread2在(2)处读到instance为null的情形,画出流程图:

接下来thread2会在有锁的情况下读取instance的值,这时它保证能读到s,理由参考情形四或者通过图中箭头指示方向来判定。

关于DCL就说这么多,留下两个问题:

    1. 接着考虑thread2在(2)读到instance为null的情形,它接着调用s.someFiled会得到什么?会得到0吗?
    2. DCL为什么要double check,能不能去掉(4)处的check?若不能,为什么?

原子性 
回到情形一,为什么我们说thread2读到some的值只可能为为0或13,而不可能为其它?这是由java对int、引用读写都是原子性所决定的。所谓“原子性”,就是不可分割的最小单元,有数据库事务概念的同学们应该对此容易理解。当调用some=13时,要么就写入成功要么就写入失败,不可能写入一半。但是,java对double, long的读写却不是原子操作,这意味着可能发生某些极端意外的情况。看例子:

public class C {
	private /* volatile */ long x;                           // (1)

	public void setX(long v) { x = v; }
	public long getX() { return x; }
}

  

Thread1 Thread2
(1) c.setX(0x1122334400112233L)  
  (2) c.getX()

thread2读取x的值可能为0,1122334400112233外,还可能为别的完全意想不到的值。一种情况假设jvm对long的写入是先写低4字节,再写高4字节,那么读取到x的值还可能为112233。但是我们不对jvm做如此假设,为了保证对long或double的读写是原子操作,有两种方式,一是使用volatile,二是使用synchronized。对上面的例子,如果取消(1)处的volatile注释,将能保证thread2读取到x的值要么为0,要么为1122334400112233。如果使用同步,则必须像下面这样对getX,setX都同步:

public class C {
	private /* volatile */ long x;                           // (1)

	public synchronized void setX(long v) { x = v; }
	public synchronized long getX() { return x; }
}

因此对原子性也有规则(volatile其实也是一种同步)。

规则二:对double, long变量,只有对所有读写都同步,才能保证它的原子性

有时候我们需要保证一个复合操作的原子性,这时就只能使用synchronized。

public class Canvas {
	private int curX, curY;

	public /* synchronized */ getPos() {
		return new int[] { curX, curY };

	}

	public /* synchronized */ void moveTo(int x, int y) {
		curX = x;
		curY = y;
	}
}

  

Thread1 Thread2
(1) c.moveTo(1, 1)  
(2) c.moveTo(2, 2)  
  (3) c.getPos()

当没有同步的情况下,thread2的getPos可能会得到[1, 2], 尽管该点可能从来没有出现过。之所以会出现这样的结果,是因为thread2在调用getPos()时,curX有0,1或2三种可能,同样curY也有0,1或2三种可能,所以getPos()可能返回[0,0], [0,1], [0,2], [1,0], [1,1], [1,2], [2,0], [2,1], [2,2]共九种可能。要避免这种情况,只有将getPos()和moveTo都设为同步方法。

总结 
以上分析了数据竞争的两种症状,陈旧数据和非原子操作,都是由于没有恰当同步引起的。这些其实都是相当基础的知识,同步可有两种效果:一是保证读取最新数据,二是保证操作原子性,但是大多数书籍都对后者过份强调,对前者认识不足,以致对多线程的认识上存在很多误区。如果想要掌握java线程高级知识,我只推荐《Java并发编程设计原则与模式》。其实我已经好久没有写Java了,这些东西都是我两年前的知识,如果存在问题,欢迎大家指出,千万不要客气。

还有一篇讲的也很不错:http://www.iteye.com/topic/260515

  

时间: 11-25

Java并发——DCL问题的相关文章

【Java并发编程】并发编程大合集-值得收藏

http://blog.csdn.net/ns_code/article/details/17539599这个博主的关于java并发编程系列很不错,值得收藏. 为了方便各位网友学习以及方便自己复习之用,将Java并发编程系列内容系列内容按照由浅入深的学习顺序总结如下,点击相应的标题即可跳转到对应的文章    [Java并发编程]实现多线程的两种方法    [Java并发编程]线程的中断    [Java并发编程]正确挂起.恢复.终止线程    [Java并发编程]守护线程和线程阻塞    [Ja

【死磕Java并发】-----深入分析volatile的实现原理

通过前面一章我们了解了synchronized是一个重量级的锁,虽然JVM对它做了很多优化,而下面介绍的volatile则是轻量级的synchronized.如果一个变量使用volatile,则它比使用synchronized的成本更加低,因为它不会引起线程上下文的切换和调度.Java语言规范对volatile的定义如下: Java编程语言允许线程访问共享变量,为了确保共享变量能被准确和一致地更新,线程应该确保通过排他锁单独获得这个变量. 上面比较绕口,通俗点讲就是说一个变量如果用volatil

Java 并发编程:volatile的使用及其原理

Java并发编程系列[未完]: Java 并发编程:核心理论 Java并发编程:Synchronized及其实现原理 Java并发编程:Synchronized底层优化(轻量级锁.偏向锁) Java 并发编程:线程间的协作(wait/notify/sleep/yield/join) Java 并发编程:volatile的使用及其原理 一.volatile的作用 在<a href="http://www.cnblogs.com/paddix/p/5374810.html">&

【Java并发编程】并发编程大合集

转载自:http://blog.csdn.net/ns_code/article/details/17539599 为了方便各位网友学习以及方便自己复习之用,将Java并发编程系列内容系列内容按照由浅入深的学习顺序总结如下,点击相应的标题即可跳转到对应的文章    [Java并发编程]实现多线程的两种方法    [Java并发编程]线程的中断    [Java并发编程]正确挂起.恢复.终止线程    [Java并发编程]守护线程和线程阻塞    [Java并发编程]Volatile关键字(上)

Java并发编程(三)volatile域

相关文章 Java并发编程(一)线程定义.状态和属性 Java并发编程(二)同步 Android多线程(一)线程池 Android多线程(二)AsyncTask源代码分析 前言 有时仅仅为了读写一个或者两个实例域就使用同步的话,显得开销过大,volatile关键字为实例域的同步訪问提供了免锁的机制.假设声明一个域为volatile,那么编译器和虚拟机就知道该域是可能被还有一个线程并发更新的. 再讲到volatile关键字之前我们须要了解一下内存模型的相关概念以及并发编程中的三个特性:原子性,可见

[Java] [Singleton] [DCL]

Singleton 只能有一个实例:必须自己创建自己的实例:必须给其他所有对象提供这一实例 实现方法 饿汉式singleton 预先加载法 class Single { private Single() { System.out.println("ok"); } private static Single instance = new Single(); public static Single getInstance() { return instance; } } 优点: thre

1.java并发-启程

1.java并发-启程 看了差不多快一个月的 java 并发有关的知识点了,看的比较多的是这个博主的死磕java系列 写的很好,感谢! 但是不写下来的话感觉忘得很快,趁现在有时间,多写点东西吧! 1. 为什么需要Java并发? 在大学学习 Java 的时候虽然也学了一点与线程有关的内容,但在实操中并没有使用到什么.虽然也做了课设,但是基本上不会被使用,所以也不会去关注程序的并发性问题,因为根本不会出现这样的问题.但是一个产品要投入使用,在生产中就不得不考虑了.单线程是不可能满足企业的业务需求的,

java 并发——内置锁

坚持学习,总会有一些不一样的东西. 一.由单例模式引入 引用一下百度百科的定义-- 线程安全是多线程编程时的计算机程序代码中的一个概念.在拥有共享数据的多条线程并行执行的程序中,线程安全的代码会通过同步机制保证各个线程都可以正常且正确的执行,不会出现数据污染等意外情况. 文字定义总是很含糊,举个反例就很清楚了,想起之前总结过单例模式,就从单例模式开始吧.如果不清楚单例模式的新同学,可以看一下这篇总结: java中全面的单例模式多种实现方式总结 单例模式中,懒汉式的实现方案如下: public c

Java并发编程:Concurrent锁机制解析

.title { text-align: center } .todo { font-family: monospace; color: red } .done { color: green } .tag { background-color: #eee; font-family: monospace; padding: 2px; font-size: 80%; font-weight: normal } .timestamp { color: #bebebe } .timestamp-kwd