编写java程序151条建议读书笔记（17）

建议123：volatile不能保证数据同步

volatile关键字比较少用，原因两点，一是在Java1.5之前该关键字在不同的操作系统上有不同的表现，所带来的问题就是移植性较差；二是比较难设计，而且误用较多，这也导致它的"名誉" 受损。我们知道，每个线程都运行在栈内存中，每个线程都有自己的工作内存(Working Memory,比如寄存器Register、高速缓冲存储器Cache等)，线程的计算一般是通过工作内存进行交互的，其示意图如下图所示：

从图上可以看到，线程在初始化时从主内存中加载所需的变量值到工作内存中，然后在线程运行时，如果是读取，则直接从工作内存中读取，若是写入则先写到工作内存中，之后刷新到主内存中，这是JVM的一个简答的内存模型，但是这样的结构在多线程的情况下有可能会出现问题，比如：A线程修改变量的值，也刷新到了主内存，但B、C线程在此时间内读取的还是本线程的工作内存，也就是说它们读取的不是最"新鲜"的值，此时就出现了不同线程持有的公共资源不同步的情况。对于此类问题有很多解决办法，比如使用synchronized同步代码块，或者使用Lock锁来解决该问题，不过Java可以使用volatile更简单地解决此类问题，比如在一个变量前加上volatile关键字，可以确保每个线程对本地变量的访问和修改都是直接与内存交互的，而不是与本线程的工作内存交互的，保证每个线程都能获得最"新鲜"的变量值，直接跳转不是结果上图3、4步骤。volatile变量是否能够保证数据的同步性？

class UnsafeThread implements Runnable {
// 共享资源
private volatile int count = 0;
@Override
public void run() {
// 增加CPU的繁忙程度,不必关心其逻辑含义
for (int i = 0; i < 1000; i++) {
Math.hypot(Math.pow(92456789, i), Math.cos(i));
}
count++;
}
public int getCount() {
return count;
}
}
public static void main(String[] args) throws InterruptedException {
// 理想值，并作为最大循环次数
int value = 1000;
// 循环次数,防止造成无限循环或者死循环
int loops = 0;
// 主线程组,用于估计活动线程数
ThreadGroup tg = Thread.currentThread().getThreadGroup();
while (loops++ < value) {
// 共享资源清零
UnsafeThread ut = new UnsafeThread();
for (int i = 0; i < value; i++) {
new Thread(ut).start();
}
// 先等15毫秒，等待活动线程为1
do {
Thread.sleep(15);
} while (tg.activeCount() != 1);
// 检查实际值与理论值是否一致
if (ut.getCount() != value) {
// 出现线程不安全的情况
System.out.println("循环到：" + loops + " 遍，出现线程不安全的情况");
System.out.println("此时，count= " + ut.getCount());
System.exit(0);
}    }    }

代码定义了一个多线程类，run方法的主要逻辑是共享资源count的自加运算，而且我们还为count变量加上了volatile关键字，确保是从内存中读取和写入的，如果有多个线程运行，也就是多个线程执行count变量的自加操作，count变量会产生脏数据吗？代码运行逻辑如下：1、启动100个线程，修改共享资源count的值。2、暂停15秒，观察活动线程数是否为1(即只剩下主线程再运行)，若不为1，则再等待15秒。3、判断共享资源是否是不安全的，即实际值与理想值是否相同，若不相同，则发现目标，此时count的值为脏数据。4、如果没有找到，继续循环，直到达到最大循环为止。运行结果如下：循环到：40
遍，出现线程不安全的情况此时，count= 999。

这只是一种可能的结果，每次执行都有可能产生不同的结果。这也说明我们的count变量没有实现数据同步，在多个线程修改的情况下，count的实际值与理论值产生了偏差，直接说明了volatile关键字并不能保证线程的安全。自加操作。count++表示的是先取出count的值然后再加1，也就是count=count+1，所以，在某个紧邻时间片段内会发生如下神奇的事情(1)第一个时间片段。A线程获得执行机会，因为有关键字volatile修饰，所以它从主内存中获得count的最新值为998，接下来的事情又分为两种类型：如果是单CPU，此时调度器暂停A线程执行，让出执行机会给B线程，于是B线程也获得了count的最新值998。如果是多CPU，此时线程A继续执行，而线程B也同时获得了count的最新值998。(2)、第二个片段：如果是单CPU，B线程执行完+1操作(这是一个原子处理)，count的值为999，由于是volatile类型的变量，所以直接写入主内存，然后A线程继续执行，计算的结果也是999，重新写入主内存中。2、如果是多CPU，A线程执行完加1动作后修改主内存的变量count为999，线程B执行完毕后也修改主内存中的变量为999，这两个时间片段执行完毕后，原本期望的结果为1000，单运行后的值为999，这表示出现了线程不安全的情况。这也是要说明的：volatile关键字并不能保证线程安全，它只能保证当前线程需要该变量的值时能够获得最新的值，而不能保证线程修改的安全性。顺便说一下，在上面的代码中，UnsafeThread类的消耗CPU计算是必须的，其目的是加重线程的负荷，以便出现单个线程抢占整个CPU资源的情景，否则很难模拟出volatile线程不安全的情况。

建议124：异步运算考虑使用Callable接口

多线程应用有两种实现方式，一种是实现Runnable接口，另一种是继承Thread类，这两个方法都有缺点：run方法没有返回值，不能抛出异常(这两个缺点归根到底是Runnable接口的缺陷，Thread类也实现了Runnable接口)，如果需要知道一个线程的运行结果就需要用户自行设计，线程类本身也不能提供返回值和异常。但是从Java1.5开始引入了一个新的接口Callable，它类似于Runnable接口，实现它就可以实现多线程任务，实现Callable接口的类，只是表明它是一个可调用的任务，并不表示它具有多线程运算能力，还是需要执行器来执行的。

建议125：优先选择线程池

在Java1.5之前，实现多线程比较麻烦，需要自己启动线程，并关注同步资源，防止出现线程死锁等问题，在1.5版本之后引入了并行计算框架，大大简化了多线程开发。我们知道一个线程有五个状态：新建状态(NEW)、可运行状态(Runnable，也叫作运行状态)、阻塞状态(Blocked)、等待状态(Waiting)、结束状态(Terminated)，线程的状态只能由新建转变为了运行状态后才能被阻塞或等待，最后终结，不可能产生本末倒置的情况，比如把一个结束状态的线程转变为新建状态，则会抛出异常：java.lang.IllegalThreadStateException异常，原因就是不能从结束状态直接转变为运行状态。一个线程的运行时间分为3部分：T1为线程启动时间，T2为线程的运行时间，T3为线程销毁时间，如果一个线程不能被重复使用，每次创建一个线程都需要经过启动、运行、销毁时间，这势必增大系统的响应时间，有没有更好的办法降低线程的运行时间呢？T2是无法避免的，只有通过优化代码来实现降低运行时间。T1和T2都可以通过线程池(Thread
Pool)来缩减时间，比如在容器(或系统)启动时，创建足够多的线程，当容器(或系统)需要时直接从线程池中获得线程，运算出结果，再把线程返回到线程池中ExecutorService就是实现了线程池的执行器，我们来看一个示例代码：

public static void main(String[] args) throws InterruptedException {
// 2个线程的线程池
ExecutorService es = Executors.newFixedThreadPool(2);
// 多次执行线程体
for (int i = 0; i < 4; i++) {
es.submit(new Runnable() {
@Override
public void run() {
System.out.println(Thread.currentThread().getName());
}
});
}       // 关闭执行器
es.shutdown();
}

此段代码首先创建了一个包含两个线程的线程池，然后在线程池中多次运行线程体，输出运行时的线程名称，结果如下：pool-1-thread-1　　　pool-1-thread-2　　　　pool-1-thread-1　　　　pool-1-thread-2本次代码执行了4遍线程体，按照我们之前阐述的" 一个线程不可能从结束状态转变为可运行状态 "，那为什么此处的2个线程可以反复使用呢？这就是我们要搞清楚的重点。线程池涉及以下几个名词：

1、工作线程(Worker)：线程池中的线程，只有两个状态：可运行状态和等待状态，没有任务时它们处于等待状态，运行时它们循环的执行任务。

2、任务接口(Task)：这是每个任务必须实现的接口，以供工作线程调度器调度，它主要规定了任务的入口、任务执行完的场景处理，任务的执行状态等。这里有两种类型的任务：具有返回值(异常)的Callable接口任务和无返回值并兼容旧版本的Runnable接口任务。

3、任务对列(Work Quene)：也叫作工作队列，用于存放等待处理的任务，一般是BlockingQuene的实现类，用来实现任务的排队处理。首先从线程池的创建说起，Executors.newFixedThreadPool(2)表示创建一个具有两个线程的线程池，源代码如下：

public class Executors {
//生成一个最大为nThreads的线程池执行器
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
}

这里使用了LinkedBlockingQueue作为队列任务管理器，所有等待处理的任务都会放在该对列中，需要注意的是，此队列是一个阻塞式的单端队列。线程池建立好了，那就需要线程在其中运行了，线程池中的线程是在submit第一次提交任务时建立的，代码如下：

public Future<?> submit(Runnable task) {
//检查任务是否为null
if (task == null) throw new NullPointerException();
//把Runnable任务包装成具有返回值的任务对象，不过此时并没有执行，只是包装
RunnableFuture<Object> ftask = newTaskFor(task, null);
//执行此任务
execute(ftask);
//返回任务预期执行结果
return ftask;
}

此处的代码关键是execute方法，它实现了三个职责。1、创建足够多的工作线程数，数量不超过最大线程数量，并保持线程处于运行或等待状态。2、把等待处理的任务放到任务队列中。3、从任务队列中取出任务来执行。其中此处的关键是工作线程的创建，它也是通过new
Thread方式创建的一个线程，只是它创建的并不是我们的任务线程(虽然我们的任务实现了Runnable接口，但它只是起了一个标志性的作用)，而是经过包装的Worker线程，execute方法是通过Worker类启动的一个工作线程，执行的是我们的第一个任务，然后改线程通过getTask方法从任务队列中获取任务，之后再继续执行，但问题是任务队列是一个BlockingQuene，是阻塞式的，也就是说如果该队列的元素为0，则保持等待状态，直到有任务进入为止。线程池的创建过程：创建一个阻塞队列以容纳任务，在第一次执行任务时创建做够多的线程(不超过许可线程数)，并处理任务，之后每个工作线程自行从任务对列中获得任务，直到任务队列中的任务数量为0为止，此时，线程将处于等待状态，一旦有任务再加入到队列中，即召唤醒工作线程进行处理，实现线程的可复用性。使用线程池减少的是线程的创建和销毁时间，这对于多线程应用来说非常有帮助，比如我们常用的Servlet容器，每次请求处理的都是一个线程，如果不采用线程池技术，每次请求都会重新创建一个新的线程，这会导致系统的性能符合加大，响应效率下降，降低了系统的友好性。