Java并发编程：什么是对象可见性，线程安全性的帮手-源码交易平台丞旭猿

前面我们讲过如何通过同步来避免多个线程在同一时刻访问相同的数据，而接下来的几篇文章我们将介绍如何共享和发布对象，从而使它们能够安全地由多个线程同时访问。这两部分内容结合在一起，就形成了构建线程安全类以及通过java.util.concurrent类库来构建并发应用程序的重要基础。

我们知道同步代码块和同步方法可以确保以原子的方式执行操作，但一种常见的误解是，认为关键字synchronized只能用于实现原子性或者确定临界区。同步还有另一个重要的方面：内存可见性。我们不仅希望防止某个线程正在使用对象状态而另一个线程在同时修改状态，而且希望确保当一个线程修改了对象状态后，其他线程能够看到发生的状态变化。如果没有同步，那么这种情况就无法实现。你可以通过显示的同步或者类库中内置的同步来保证对象被安全地发布。

可见性详解

可见性是一种复杂的属性，在单线程环境中，如果向某个变量先写入值，然后在没有其他写入操作的情况下读取这个变量，那么总能得到相同的值。这看起来很自然是不是。然而，当读操作和写操作在不同的线程中执行时，情况却并非如此，这听起来或许有些难以接受。通常，我们无法确保执行读操作的线程能适时地看到其他写线程写入的值，有时甚至是根本不可能的事情。为了确保多个线程之间对内存写入操作的可见性，必须使用同步机制。

上面的程序说明了当多个线程在没有同步的情况下共享数据时出现的错误。在代码中，主线程和读线程都将访问共享变量ready和number。主线程启动读线程，然后将number设为43，并将ready设为true。读线程一直循环直到发现ready的值变为true，然后输出number的值。虽然程序看起来会输出42，但事实上很可能输出0，或者根本无法终止。这是因为在代码中没有足够的同步机制，因此无法保证主线程写入的ready值和number值对于读线程来说是可见的。

程序可能会持续循环下去，因为读线程可能永远看不到ready的值。一种更奇怪的现象是，程序可能会输出0，因为读线程可能看到了写入ready的值，但却没有看到之后写入number的值，这种想象被称为重排序。只要在某个线程中无法检测到重排序情况，那么就无法确保线程中的操作将按照程序中指定的顺序来执行。当主线程首先写入number，然后在没有同步的情况下写入ready，那么读线程看到的顺序可能与写入的顺序完全相反。

在没有同步的情况下，编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的调整。在缺乏足够同步的多线程程序中，要想对内存操作的执行顺序进行判断，几乎无法得出正确的结论。

程序是一个简单的并发程序，只包含两个线程和两个共享变量，但即便如此，在判断程序的执行结果以及是否会结束时仍然很容易得出错误结论。要对那些缺乏足够同步的并发程序的执行情况进行推断是十分困难的。

这听起来有点恐怖，但实际情况也确实如此。幸运的是，有一种简单的方法能避免这些复杂的问题：只要有数据在多个线程之间共享，就使用正确的同步。

失效数据

在缺乏同步的程序中可能产生错误结果的一种情况：失效数据。当读线程查看ready变量时，可能会得到一个已经失效的值。除非在每次访问变量时都使用同步，否则很可能获得该变量的一个失效值。更糟糕的是，失效值可能不会同时出现：一个线程可能获得某个变量的最新值，而获得另一个变量的失效值。

通常，当食物过期时，还是可以使用的，只不过味道差了一些。失效的数据可能导致输出错误的值，或者是程序无法结束。如果对象的引用（例如链表中的指针）失效，那么情况会更负责。失效数据还可能导致一些令人困惑的故障，例如意料之外的异常、被破坏的数据结构、不精确的计算以及无限循环等。

上面的程序不是线程安全的，因为get和set都是在没有同步的情况下访问value的。与其他问题相比，失效值问题更容易出现：如果某个线程调用了set，那么另一个正在调用get的线程可能会看到更新后的value值，也可能看不到。

再看一个层序：

上面的程序，通过对get和set等方法进行同步，可以使程序成为一个线程安全的类。仅对set方法进行同步是不够的，调用get的线程仍然会看见失效值。

非原子的64位操作

当线程在没有同步的情况下读取变量时，可能会得到一个失效值，但至少这个值是由之前某个线程设置的值，而不是一个随机值。这种安全性保证也被成为最低安全性。

最低安全性适用于绝大多数变量，但是存在一个例外：非volatile类型的64位数值变量。Java内存模型要求，变量的读取操作和写入操作都必须是原子操作，但对于非volatile类型的long和double变量，JVM允许将64位的读操作和学操作分解为两个32位的操作。当读取一个非volatile类型的long变量时，如果对该变量的读操作和写操作在不同的线程中执行，那么很可能会读取到某个值的高32位和另一个值的低32位。因此，即使不考虑失效数据问题，在多线程程序中使用共享且可变的long和double等类型变量也是不安全的，除非用关键字volatile来声明他们，或者用锁保护起来。

加锁与可见性

内置锁可以用于确保某个线程以一种可预测的方式来查看另一个线程的执行结果，如下图所示。

当线程A执行某个同步代码块时，线程B随后进入由同一个锁保护的同步代码块，在这种情况下可以保证，在锁被释放之前，A看到的变量在B获得锁后同样可以由B看到。换句话说，当线程B执行由锁保护的同步代码块，可以看到线程A之前在同一个同步代码块中的所有操作结果。如果没有同步，那么就无法实现上述保证。

现在，我们可以进一步理解为什么在访问某个共享且可变的变量时要求所有线程在同一个锁上同步，就是为了确保某个线程写入该变量的值对于其他线程来说都是可见的。否则，如果一个线程在未持有正确锁的情况下读取某个变量，那么读到的可能是一个失效值。

加锁的含义不仅仅是局限于互斥行为，还包括内存可见性。为了确保所有线程都能看到共享变量的最新值，所有执行读操作或者写操作的线程都必须在一个锁上同步。

volatile变量

Java语言提供了一种稍弱的同步机制就是volatile变量，用来确保将变量的更新操作通知到其他线程。当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量上的操作与其他内存操作一起重排序。volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。

理解volatile变量的一种有效办法是，将它们的行为想象成如下程序的类似行为：

将volatile变量的读操作和写操作分别替换为get方法和set方法。然而，在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile变量是一种比synchronized关键字更轻量级的同步机制。

volatile变量对可见性的影响比volatile变量本身更为重要。当线程A首先写入一个volatile变量并且线程B随后读取该变量的时候，在写入volatile变量之前对A可见的所有变量的值，在B读取了volatile变量后，对B也是可见的。因此，从内存可见性的角度来看，写入volatile变量相当于退出同步代码块，而读取volatile变量就相当于进入同步代码块。然而，我们并不建议过度依赖volatile变量提供的可见性。如果在代码中依赖volatile变量来控制状态的可见性，通常比使用锁的代码更脆弱，也更难以理解。

仅当volatile变量能简化代码的实现以及对同步策略的验证时，才应该使用它们。如果在验证正确性时需要对可见性进行复杂的判断，那么就不要使用volatile变量。volatile变量的正确使用方式包括：确保它们自身状态的可见性，确保它们所引用对象的状态的可见性，以及标识一些重要的程序生命周期事件的发生。

上面的程序是volatile变量的一种典型用法：检查某个状态标记以判断是否退出循环。在这个示例中，线程试图通过类似于数绵羊的传统方法进入休眠状态。为了使这个示例能正确执行，asleep必须为volatile变量。否则，当asleep被另一个线程修改时，执行判断的线程却发现不了。我们也可以用锁来确保asleep更新操作的可见性，但这将使代码变得更加复杂。

虽然volatile变量很方便，但也存在一些局限性。volatile变量通常用作某个操作完成、发生中断或者状态的标志，例如上面程序的asleep标志。尽管volatile变量也可以用于表示其他的状态信息，但在使用时要非常小心。例如，volatile的语义不足以确保递增操作(count++)的原子性，除非你能确保只有一个线程对变量执行写操作。

加锁机制既可以确保可见性又可以确保原子性，而volatile变量只能确保可见性。

当且仅当满足一下所有条件时，才应该使用volatile变量：

对变量的写入操作不依赖变量的当前值，或者你能确保只有单个线程更新变量的值。

该变量不会与其他状态变量一起纳入不变性条件中。

在访问变量时不需要加锁。