Java并发编程实战

"上一章" 介绍了线程安全性，这一章称为"对象的共享"，书中重点介绍了如何共享和发布对象，这两章是并发编程中非常基础却很重要的部分。在本章，首先介绍了什么是可见性问题，然后介绍了Java内存模型，讨论什么是内存可见性以及java保证内存可见性的方式，在此基础上介绍如何设计线程安全的对象，如何使用线程封闭技术和设计不可变对象来避免同步，最后再重点探讨如何安全地发布对象。由于内容较多，我将这一章分拆为几篇来阐述自己对本章的理解，这是第一篇。 Java的并发机制基于共享内存，要理解对象间的共享关系，则离不开对象间的内存关系，这涉及到本章要介绍的一个重要概念：Java内存模型，又称 JMM。 1. 内存可见性 上边提到，Java的并发机制是采用的是 共享内存模型，因此，在并发环境中保证对象间的内存可见性是并发编程解决的主要问题。 什么是内存可见性？可见性是一个复杂的问题，它表示程序中的变量在写入值后是否能够立即读取到。在单线程环境中，由于写入变量和读取变量都是在单线程中进行的，因此能够保证总能读取到修改后的值。但在多线程环境下，却无法保证，可能一个线程修改变量的值，而另外的线程并不能正确读取被修改的变量的值，除非我们使用变量同步等机制来保证可见性。 为什么多线程环境下变量就不能保证可见性了呢？稍后介绍JMM时再来讨论，先看一个示例。 内存可见性（Memory Visibility）：某些线程修改了变量的值，正在读该变量的线程能够立即读取到修改后的值。 @NotThreadSafe public class UnsafeSequence { private int count; public void increment() { count++; } public int getCount() { return count; } } 上边的示例，count变量被多个线程共享，因此不能保证 getCount() 总能读取到 increment() 增加后的值。那是不是在 increment() 方法上使用 synchronized 进行同步就能保证可见性了呢？答案是不行。虽然使用同步能够保证只有一个线程修改count的值，但是其他多个线程仍然可能读到 失效的值，因此必须在 getCount() 上也使用同步，见 "这里"。 再看一个示例，如下边的代码： @NotThreadSafe public class NoVisibility { private static boolean ready; private static int anInt; private static class VariableReader implements Runnable { @Override public void run() { while (!ready) { Thread.yield(); } System.out.println(anInt); } } public static void main(String[] args) { new Thread(new VariableReader(), "read").start(); anInt = 47; (1) ready = true; (2) } } ...

上一章 介绍过，并发编程会带来诸多挑战，最基本的就是 线程安全性，但这又是一个非常复杂的主题。这一章重点介绍了什么是线程安全性、原子性、竞态条件等概念，以及在Java中如何通过加锁来确保线程安全性。 1. 什么是线程安全性 1.1. 正确性 要理解什么是线程安全性，必须先明白什么是正确性，正确性是线程安全性的核心概念。 正确性的含义是，某个类的行为与其规范完全一致。 — Java并发编程实战 这个定义从静态视角出发强调了类的规范重要性。通常，我们不会定义类的详细规范，但是我们应该为类和方法提供文档注释，来说明类是否是线程安全的，以及对于线程安全性如何保证。尤其在方法上，应该明确规定该方法是否已经保证了线程安全，调用者是否应该在同步机制内调用该方法等等。 下边是 ArrayList 的类文档注释的节选，它告诉调用者关于线程安全的内容： Note that this implementation is not synchronized. If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an element is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the list. ...

这一章主要讲述线程的发展历史，以及并发编程带来的优势和挑战。 1. 线程的发展 1946年第一台计算机诞生，一直到20世纪50年代中期，这时候的计算机没有操作系统的概念，采用手工操作的方式工作，每次只能有一个人使用计算机。此时的手工操作方式，用户独占全机，昂贵的计算机资源得不到充分利用。 后来，随着计算机的发展，出现了批处理系统、多道程序系统，它们都提升了计算机的资源利用率。1961年，分时系统（Time Sharing System）出现，此时的一台计算机可以供多个用户终端同时连接并使用，就好像自己在独占计算机一样。分时系统将CPU的运行时间分成很短的时间片，按时间片分配给不同的连接终端使用，这充分利用了计算机资源，看起来就好像多个用户在同时使用计算机一样。 再后来，通用操作系统出现（General Operating System），它隐藏了硬件调用接口，为应用程序员提供调用硬件资源的更好、更简单、更清晰的系统调用接口，程序员就可以直接面向操作系统来编写程序，而不用关注硬件。 计算机的发展 [1]，都在试图解决三个问题： 资源利用率：尽可能的利用昂贵的计算机资源，如CPU、内存，而不是使其大部分时间处于等待状态 公平性：不同的用户对计算机都有同等使用权，而不是排队等待 便利性：可以同时执行多个程序，每个程序执行一个任务并在必要时相互通信 这三个问题促使进程和线程的出现。计算机可以同时运行多个程序，每个程序一个进程；而同一个进程中同样存在多个线程（轻量级进程），它们共享进程范围内的资源，如内存句柄和文件句柄，每个线程都有自己的程序计数器、局部变量等，而且同一个进程的多个线程都可以被调度到CPU上运行。但是，线程之间存在着共享资源（进程的内存），如果没有协同机制，那么多个线程在同时处理共享内存时会存在安全问题，比如一个线程读某个变量而一个线程同时在写这个变量，如果没有线程同步机制，则该变量的值变得不可预测。 举个例子，假设进程为多条高速公路，它们之间彼此独立，而线程就好比高速公路的多个车道，它们共享这条高速路的资源，如指示牌、测速设备等，线程中执行的任务就是一辆小汽车，它们相安无事的飞驰在自己的车道上，一旦它们开始抢夺道路资源，不遵守交通规则，超速、违规变道，那么后果可想而知。 2. 多线程的优势 Java是门支持并发编程的语言，充分利用其提供的并发特性来编写高并发程序，是信息化时代发展所需。多线程程序的优势可以从几个方面来说明： 多线程程序能够极大的发挥处理器的强大能力。现代的计算机，CPU核心越来越多、处理频率越来越快、制造工艺越来越精，计算机的价格也越来越亲民，个人普通电脑都普遍是四核心、八核心甚至配置更高。在单核心CPU中，可能多线程程序不但没能提升处理性能，反而由于线程上下文切换的开销导致程序性能降低；但是，在多核心时代，多线程能够发挥处理器的强大能力，每个核心都能同时处理一个任务而不会造成上下文切换，如果还停留在单线程程序，这无疑是极大的浪费计算机资源，如果有100个CPU，那么单线程程序会造成99%的CPU都处于空闲状态。 建模更简单。首先要明确，编写多线程程序与单线程程序相比，肯定是复杂且容易出错的，那么为什么说建模更简单呢？这需要从管理线程中执行的任务角度去分析。在单线程中执行多个任务，与多个线程每个线程仅执行一个任务相比，哪个更容易管理呢？很明显是后者。虽然多线程中的任务彼此可能存在通信，但是从模型上看，一个线程只管理一个任务，职责更单一。 异步事件简化处理。这一点可以理解为编程模型的简化。单线程和多线程程序，在IO模型的选择上存在很大的不同。单线程程序，要提高并发请求数，底层需要使用异步IO、非阻塞IO或者IO多路复用模型 [2]，但他们都是由操作系统底层支持，编程难度大；而多线程程序，由于应用层面本身采用了多线程模型，底层的IO则可以选择同步IO(异步的事情多线程做了)，这就降低了开发难度。比如单线程模型中，Nginx采用多进程单线程和IO多路复用模型的架构，具备极高的并发处理能力；Redis采用单线程和IO多路复用模型，同样具备很高的处理效率。 响应更灵敏的用户界面。Java的GUI框架AWT和Swing采用事件分发线程来替代传统的主事件循环，并可将将耗时的处理任务放到单独的线程中异步执行，从而提高用户界面的响应速度。 3. 多线程的挑战 多线程是一把双刃剑，带来诸多优势时也让开发者面临更大的挑战。 1、开发难度问题 由于多线程程序运行的不确定性，给开发难度带来很大的挑战。相对于单线程程序，多线程编程更难以掌握，不仅需要充分理解编程语言级的多线程支持，还需要掌握操作系统层级的多线程模型。尽管如此，多线程程序仍然难以调试和跟踪，尤其是产生 "活跃性" 问题时往往无法重现。 2、安全性问题 什么是安全性？安全性指的是程序永远不会返回错误的结果。看下边的示例： public class UnsafeSequence { private int count; public int increment() { return count++; } public int getCount() { return count; } } 多个线程调用 increment 方法，由于 count++ 包含了 读取、修改、写入三步内存操作，这三步不是一个原子操作，存在多个线程重复写同一值的情况，如下图示意： Figure 1. 线程竞争导致错误的结果 由于线程在同时操作相同的count域，一个线程可能会覆盖另一个线程写入的值（线程竞争），最终count得到错误的值6，而不是预期的7. 线程安全本身是一个非常复杂的问题，由于线程之间存在资源共享，如果多个线程交替执行又没有有效的同步机制，执行结果将难以预料。尽管Java提供了足够的同步机制来保证线程安全性，但是这就要求开发者必须完全理解多线程程序的执行原理和Java的同步机制，这给程序开发带来很大的难度。 3、活跃性问题： ...

这是个人的《Java并发编程实战》阅读笔记整理系列的第一篇文章，这个系列包括对书中并发编程内容的整理、总结以及个人的一些感悟和实践心得。 1. 简介 《Java并发编程实战》是 Brian Goetz 等 6 位 Java 大师合著的介绍 Java 并发编程的经典著作，这部名著由浅入深的介绍了 Java 并发编程的诸多知识，是一本完美的Java并发参考手册， 豆瓣评分 9.0，可见其受欢迎程度。 1.1. 内容概要 《Java并发编程实战》从并发性和线程安全性的基本概念出发，介绍了如何使用类库提供的基本并发构建块，用于避免并发危险、构造线程安全的类及验证线程安全的规则，如何将小的线程安全类组合成更大的线程安全类，如何利用线程来提高并发应用程序的吞吐量，如何识别可并行执行的任务，如何提高单线程子系统的响应性，如何确保并发程序执行预期任务，如何提高并发代码的性能和可伸缩性等内容，最后介绍了一些高级主题，如显式锁、原子变量、非阻塞算法以及如何开发自定义的同步工具类。 这本书介绍的是 Java 中 "并发编程" 这样的高级主题，不太适合初学者阅读。书中诸多的内容都较难理解，比如线程的 "竞态条件"、"同步机制"、"活跃性" 等等，如果对并发知之甚少，不熟悉操作系统层面的相关内容，阅读起来比较吃力。 1.2. 作者简介 本书作者都是Java Community Process JSR 166专家组（并发工具）的主要成员，并在其他很多JCP专家组里任职。Brian Goetz有20多年的软件咨询行业经验，并著有至少75篇关于Java开发的文章。Tim Peierls是“现代多处理器”的典范，他在BoxPop.biz、唱片艺术和戏剧表演方面也颇有研究。Joseph Bowbeer是一个Java ME专家，他对并发编程的兴趣始于Apollo计算机时代。David Holmes是《The Java Programming Language》一书的合著者，任职于Sun公司。Joshua Bloch是Google公司的首席Java架构师，《Effective Java》一书的作者，并参与著作了《Java Puzzlers》。Doug Lea是《Concurrent Programming》一书的作者，纽约州立大学 Oswego分校的计算机科学教授。 也许你对这几位大师不怎么熟悉，但是你一定读过它们的著作，尤其是 Joshua Bloch 的《Effective Java》，这本书也是 Java 开发者必读的书籍，目前已经出到了第三版。 如果经常编写并发程序，那么对于 Doug Lea 一定不会陌生，因为 Java 5 开始的很多并发工具（它们都在 java.util.concurrent 包中，简称 juc 包）都出自他的手笔，如 AbstractQueuedSynchronizer、AtomicXxx 原子类、BlockingQueue、ConcurrentMap、ExecutorService 等等，几乎整个并发工具包的类都是他实现的。 1.3. 阅读建议 前边说过，尽管《Java并发编程实战》是经典著作，但是由于其内容的特殊性，存在一定的阅读门槛。如果英文过关，建议直接阅读英文版，对于大多数人只能阅读翻译的中文版本了，但中文版存在一些问题，诸多概念介绍的很官方，内容不够充实、通俗易懂，理解起来费力，也存在一些翻译不通顺的问题。 ...