java for 多线程_Java多线程整理（li）

目录：

1.volatile变量

2.Java并发编程学习

3.CountDownLatch用法

4.CyclicBarrier使用

5.BlockingQueue使用

6.任务执行器Executor

7.CompletionService使用

8.ConcurrentHashMap使用

9.Lock使用

一、 volatile变量

1.volatile原理：volatile的原理实际上是告诉处理器，不要把变量缓存在寄存器或者相对于其他处理器不可见的地方，而是把变量放在主存，每次读写操作都在主存上进行操作。另外，被申明为volatile的变量也不会与其它内存中的变量进行重排序。

2.volatile同步：volatile是同步的一个子集，只保证了变量的可见性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。相对于同步而言，volatile的优势：a.简易性，可以像使用其他变量一样使用volatile变量；b.volatile变量不会造成线程阻塞；c.如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。

3.正确使用volatile条件：对变量的写操作不依赖于当前值；该变量没有包含在具有其他变量的不变式中；

/** 对于第一条原则:对变量的写操作不依赖于当前值;

* 虽然i++只有一条语句,实际上这条语句是分三步执行的,读入i,i加1，写入i;

* 若在第三步执行过程前，其他线程对i进行了改动，此时的结果将是错的。因此即使使用了volatile进行控制，并不能保证这个操作是线程安全的。*/

private volatile int i=1;

...

i++;/** 这类问题的解决方案有两种:

* 1.一种是采用synchronized进行同步控制，这显然违背了volatile的初衷

* 2.一种是采用CPU原语进行控制。在jdk1.5之后，java.util.concurrent.atomic包下的很多类就是采用这种方式进行控制，这样可以在保持性能的情况下，保证数据的线程安全。*/

二、Java并发编程学习

在java 并发编程实践中对线程安全的定义如下：当多个线程访问一个类时，如果不用考虑这些线程在运行时环境下的调度和交替运行，并且不需要额外的同步及在调用方代码不必做其他的协调，这个类的行为仍然是正确的，那么这个类就是线程安全的。完全由线程安全的类构成的程序不一定就是线程安全的。

/** 如下代码所示:

* 虽然Vector是一个线程安全的类，但是对于由Vector线程安全的方法组成上面的逻辑，显然不是线程安全的。

* 当然，由线程不安全的类构成的程序，也不一定不是线程安全的。*/Vector v;if(!v.contains(o)){

v.add(o);

}/** 微妙的可见性:

* 当变量的读入写出被不同的线程共享时，必须使用同步。若不使用同步将有可能发生与直觉大相径庭的错误。*/

public classTestVisiable {static int x = 0, y = 0;static int b = 0, a = 0;public static void main(String[] args) throwsInterruptedException {

Thread t1= new Thread(newRunnable() {

@Overridepublic voidrun() {

a= 1;

x=b;

}

});

Thread t2= new Thread(newRunnable() {

@Overridepublic voidrun() {

b= 1;

y=a;

}

});

t1.start();

t2.start();

t1.join();

t2.join();

System.out.println(x+ " " +y);

}

}/** 由于没有同步，程序运行的可能结果为(1,0) (0,1),(1,1),然而，还有可能为(0,0),不可思议吧。

* 1.这是由于为了加快并发执行，JVM内部采用了重排序的机制导致。

* 2.最低限的安全性在java中，java存储模型要求java变量的获取和存储都是原子操作，但是有两种类型的变量是比较特殊的,没有申明为volitale的long和double变量。

* 原因在于：

* 1.在java中long和double变量为64位，jvm允许将64位的读写操作划分为两个32位的操作。

* 2.当多个线程同时读写非volatile的long或者double类型数据时，将有可能得到数据是一个数的高32位和另一个数的低32位组成的数。

* 3.这样的结果显然是完全不对的。因此对应long或double类型的数据用于多线程共享时，必须申明加上volatile或者进行同步。*/

三、CountDownLatch用法

在jdk API中如下描述：一个同步辅助类，在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待。用给定的计数初始化 CountDownLatch。由于调用了 countDown() 方法，所以在当前计数到达零之前，await 方法会一直受阻塞。之后，会释放所有等待的线程，await 的所有后续调用都将立即返回。

CountDownLatch 是一个通用同步工具，它有很多用途。将计数 1 初始化的 CountDownLatch 用作一个简单的开/关锁存器，或入口：在通过调用 countDown() 的线程打开入口前，所有调用 await 的线程都一直在入口处等待。

/** 下面给出一个详细的应用场景 百米赛跑：

* 比赛共有10名运动员参与，10名运动在起跑线上统一等待号令员发起起跑的号令，通过终点时号令员统计该运动员的时间，当所有运动员都跑到终点时，报告每个人的成绩。

* 这里实际上就可以采用CountDownLatch来解决起跑线上设置一个CountDownLatch，当号令员没有发起起跑号令时，所有运动员都在起跑线上等待。

* 在终点设置一个CountDownLatch，起跑后号令员一直等待，当所有运动员都通过终点后，它会报告成绩。 用代码实现如下：*/

importjava.util.HashMap;importjava.util.Map;importjava.util.concurrent.CountDownLatch;public classCommander {private final CountDownLatch startSignal; //起跑信号

private final CountDownLatch endSignal; //终点信号

privateLong startTime;private final Map scoreMap = new HashMap();public voidwaitStart() {try{

startSignal.await();

}catch(InterruptedException e) {

e.printStackTrace();

}

}public synchronized voidstart() {

startTime=System.currentTimeMillis();

startSignal.countDown();try{

endSignal.await();

}catch(InterruptedException e) {

e.printStackTrace();

}

}public void reach(intid) {

endSignal.countDown();

scoreMap.put(id, System.currentTimeMillis()- startTime);//统计时间

}public Commander(intnum){

startSignal= new CountDownLatch(1);

endSignal= newCountDownLatch(num);

}public static voidmain(String[] args) {int runnerNum = 10;

Commander c= newCommander(runnerNum);for (int i = 0; i < runnerNum; i++) {new Thread(new Runner(i + 1, c)).start();

}

c.start();//发起号令

for(Integer i : c.scoreMap.keySet()) {

System.out.println(i+ "号运动员,耗时" +c.scoreMap.get(i));

}

}

}class Runner implementsRunnable {

Commander commander;intid;public Runner(intid, Commander commander){this.id =id;this.commander =commander;

}

@Overridepublic voidrun() {

commander.waitStart();try{

Thread.sleep((long) (Math.random() * 1000));

}catch(InterruptedException e) {

e.printStackTrace();

}

commander.reach(id);

}

}

四、CyclicBarrier使用

CyclicBarrier在jdk中描述：一个同步辅助类，它允许一组线程互相等待，直到到达某个公共屏障点 (common barrier point)。在涉及一组固定大小的线程的程序中，这些线程必须不时地互相等待，此时 CyclicBarrier 很有用。因为该 barrier 在释放等待线程后可以重用，所以称它为循环的 barrier。

实际上CyclicBarrier类似于CountDownLatch也是个计数器。不同的是，当线程调用await方法后，必须所有线程都到达了，才能分别进入后面的执行过程。一旦有一个线程未到达，所有线程都会等待，有点像一部电影的名字《一个都不能少》。

/** 考虑一个应用场景：

* 老师带领学生去春游，下午回来时，需要整队，然后统一坐车回去。

* 在这里，老师和已经到达的学生，必须等待所有学生归队后才能回去。 用代码实现如下：*/

importjava.util.concurrent.BrokenBarrierException;importjava.util.concurrent.CyclicBarrier;public classTeacher {private final CyclicBarrier barrier = new CyclicBarrier(20, newRunnable() {

@Overridepublic voidrun() {

System.out.println("所有学生已经归队");

}

});public void comeBack(inti) {

System.out.println(i+ "已经归队。");try{

barrier.await();

}catch(InterruptedException e) {

e.printStackTrace();

}catch(BrokenBarrierException e) {

e.printStackTrace();

}

}public static voidmain(String[] args) {

Teacher t= newTeacher();for (int i = 0; i < 20; i++) {new Thread(new Student(i + 1, t)).start();

}

}

}class Student implementsRunnable {private final intid;private finalTeacher teacher;public Student(intid, Teacher teacher){this.id =id;this.teacher =teacher;

}

@Overridepublic voidrun() {try{

Thread.sleep((long) (Math.random() * 1000));

teacher.comeBack(id);

System.out.println(id+ "上车");

}catch(InterruptedException e) {

e.printStackTrace();

}

}

}

五、BlockingQueue 学习

从名字上看，BlockingQueue是阻塞队列的意思。这个队列主要提供下面的功能：

1.阻塞队列提供了可阻塞的take和put方法，另外可定时的poll和offer实际原理也是一样的。

2.如果BlockingQueue是空的，从BlockingQueue取东西的操作将会被阻断进入等待状态，直到BlockingQueue进了东西才会被唤醒，同样，如果BlockingQueue是满的，任何试图往里存东西的操作也会被阻断进入等待状态，直到BlockingQueue里有空间时才会被唤醒继续操作。

阻塞队列有一般又为两类：无限阻塞队列和有限阻塞队列。有限阻塞队列中，当队列满时，调用put方法将会阻塞；而无限阻塞队列中，put方法是不会阻塞的。很显然这个队列的一种最常用的场景就是：生产者-消费者 模式。

/*它有以下具体实现类：

* ArrayBlockingQueue：采用数组作为存储队列的阻塞队列，这个队列采用FIFO的方式管理数据

* LinkedBlockingQueue：采用链式结构作为存储队列，同样它也采用FIFO的方式管理数据

* PriorityBlockingQueue：采用基于优先级堆的极大优先级队列作为存储队列。

* SynchronousQueue：特殊的BlockingQueue，其中每个 put 必须等待一个 take，反之亦然。

* DelayQueue：这是一个无限阻塞队列，只有在延迟期满时才能从中提取元素。该队列的头部 是延迟期满后保存时间最长的 Delayed 元素。如果延迟都还没有期满，则队列没有头部。

*

* 通过查看源代码可以看到这个类内部是采用PriorityQueue作为存储队列

* DelayQueue的一些常用的场景

* a) 关闭空闲连接。服务器中，有很多客户端的连接，空闲一段时间之后需要关闭之。

* b) 缓存。缓存中的对象，超过了空闲时间，需要从缓存中移出。

* c) 任务超时处理。在网络协议滑动窗口请求应答式交互时，处理超时未响应的请求。

**/

六、任务执行器Executor

记得在大学的时候，有一次写程序时，需要创建很多的线程来处理各种socket请求，于是写了一个线程类，每出现一个socket请求，就创建一个线程。后来，老师指出，每次创建线程的开销比较大，可以将线程与具体的业务逻辑分离开来，然后用一个队列，保存一定量的线程，每次需要的时候就去取，不用的时候就还回去，这样可以循环使用，避免重复创建线程的开销，于是乎，对代码进行重构，写了大段的代码，发现以后需要用到多线程的地方都可要用它，后来在网上找资料才知道，那叫线程池。

jdk1.5的升级，给我们带来一个很特殊的包java.util.concurrent,翻阅API，可以看到jdk中已经封装了线程池，简单两行便可实现。这个包中提供了Executor的接口，接口定义如下：

void execute(Runnable command);

传入一个runnable接口的实现，它便自动为我们创建线程和执行，任务的提交者再也不用为了并发执行，自己写一大段代码来创建并管理各种线程。扩展了Executor的有ExecutorService, ScheduledExecutorService,AbstractExecutorService, ScheduledThreadPoolExecutor, ThreadPoolExecutor.由于Runnable接口中只提供了一个不带返回值run方法，因此当任务需要返回值时，Executor就不能满足需求了，于是出现了ExecutorService,这个接口继承了Executor，对提交任务的接口进行了扩展，引入了Callable接口，该接口定义如下：

public interface Callable{

V call()throwsException;

}

同时接口将任务执行过程进行管理，分为三个状态，提交，shutdown，terminate。在AbstractExecutorService中可以看到submit(Callable c)的实现，实际上它会先创建一个Future对象，然后再调用execute(Runnable command)方法，执行任务。可以很明显的知道Future肯定是继承了Runnable接口。通过Future接口，我们可以获取由call方法调用的返回值。Executor接口的两个具体实现是ThreadPoolExecutor和ScheduledThreadPoolExecutor，通过名字可以看出，ThreadPoolExecutor是通过采用线程池来执行每个提交的任务，ScheduledThreadPoolExecutor继承自ThreadPoolExecutor,主要用于满足延迟后运行任务，或者定期执行任务的需求。虽然，我们可以通过直接调用ThreadPoolExecutor和ScheduledThreadPoolExecutor的构造函数生成Executor，但是很多情况下，没有这个必要，因为jdk为我们作了简化工作，通过Executors这个工厂类，可以只需传入一些简单的参数，便可以得到我们需要的Executor对象。

七、CompletionService学习

若在采用Executor执行任务时，可用通过采用Future来获取单个任务执行的结果，在Future中提供了一个get方法，该方法在任务执行返回之前，将会阻塞。当向Executor提交批处理任务时，并且希望在它们完成后获得结果，如果用FutureTask，你可以循环获取task，并用future.get()去获取结果，若没有完成则阻塞，这对于对任务结果需要分别对待的时候是可行的。但是若所有task产生的结果都可以被同等看待，这时候采用前面这样的方式显然是不可行了，因为若当前的task没有完成，而后面的其它task已经完成，你也得等待，这个实效性不高。显然很多时候，统一组task产生的结果都应该是没有区别的，也就是满足上述第二种情况。这个时候咋办呢？jdk为我们提供了一个很好的接口CompletionService，这个接口的具体实现类是ExecutorCompletionService。该类中定义下面三个属性：

private finalExecutor executor;private finalAbstractExecutorService aes;private final BlockingQueue> completionQueue;

executor由构造函数传入，aes只是用于生成Future对象。特别要注意是completionQueue。它维护了一个保存Future对象的BlockingQueue。当这个Future对象状态是结束的状态的时候，也就是task执行完成之后，会将它加入到这个Queue中。到底是在哪里将完成的Future加入到队列里面的呢？又是怎么知道task是什么时候结束的呢？在ExecutorCompletionService中定义了一个QueueingFuture类，该类的实现：

private class QueueingFuture extends FutureTask{

QueueingFuture(RunnableFuturetask) {super(task, null);this.task =task;

}protected voiddone() { completionQueue.add(task); }private final Futuretask;

}

可以看到在done方法中，它会把当前的task加入到阻塞队列中。追踪done方法可以看到，该方法定义在FutureTask中，默认实现为空，从注释可以看出，当Future的状态转为isDone的时候，就会调用该方法。调用端在调用CompletionService的take方法时，实际上调用的是BlockingQueue的take方法，由前面的学习中，我们知道，当队列中有内容时，该队列会立即返回队列中的对象，当队列为空时，调用线程将会阻塞。而只要有任务完成，调用线程就会跳出阻塞，获得结果。

八、ConcurrentHashMap学习

java中提供对HashMap是我们使用得比较多的一个类，单该类是非线程安全的，若处于多线程环境中，则需要通过synchronized关键字进行同步(通过查看Collections.synchronizedMap方法，可以知道，实际上该方法对实现也是通过synchronized关键字进行同步控制)，虽然它能保证线程安全，但是，由于需要对整个map进行加锁，这样做的并发性能往往不是很理想，尤其是map中数据量比较大的时候。jdk1.5之后，java.util.concurrent包中提供了ConcurrentHashMap，一方面，该类自己保证了线程安全性，另一方面，该类也提供了一些复合操作的原子性接口。

ConcurrentHashMap与HashMap一样，同样是哈希表，但是采用不同对锁机制--分离锁，即采用不同的锁来同步不同的数据块，以减少对锁对竞争。 　　在ConcurrentHashMap内部采用了一个包含16个锁对象对数组，每个锁负责同步hash Bucket的1/16，bucket中的每个对象通过它的hashCode计算得到它所在锁对象。假设hash算法的实现能够提供合理的扩展性,并且关键字能够以统一的方式访问,这会将对于锁的请求减少到原来的1/16.这种基于分离锁设计的技术实现能够使得ConcurrentHashMap支持16个并发的请求。

九、Lock使用

在java5.0以前都是采用synchronized关键字进行同步控制，所有对象都自动含有单一的锁，JVM负责跟踪对象被加锁的次数。如果一个对象被解锁，其计数变为0。在任务(线程)第一次给对象加锁的时候，计数变为1。每当这个相同的任务(线程)在此对象上获得锁时，计数会递增。只有首先获得锁的任务(线程)才能继续获取该对象上的多个锁。每当任务离开一个synchronized方法，计数递减，当计数为0的时候，锁被完全释放，此时别的任务就可以使用此资源。由于这些锁是由JVM来控制，因此也叫隐式锁。

在jdk5.0以后，提供了显示锁，即Lock，可以说是对隐式锁的功能的扩展，主要有两个。一个是ReentrantLock,另一个是ReentrantReadWriteLock，前者是普通重入锁，后者是可重入的读写锁。这些锁提供了两种锁竞争机制：公平竞争和非公平竞争，公平竞争的实现实际上是采用一个队列保存等待的线程，当当前线程释放锁之后，取出队头的线程唤醒，使之可以获取锁。java中Lock接口的定义:

public interfaceLock {voidlock();void lockInterruptibly() throwsInterruptedException;booleantryLock();boolean tryLock(long time, TimeUnit unit) throwsInterruptedException;voidunlock();

Condition newCondition();

}

Lock与synchronized的区别：

1.synchronized是在JVM层面上实现的，不但可以通过一些监控工具监控synchronized的锁定，而且在代码执行时出现异常，JVM会自动释放锁。而Lock的释放必须由程序自己保证，常用的写法是把是把释放锁的代码写到try{}finally中，在finally块中释放锁。

2.如果使用 synchronized ，如果A不释放，B将一直等下去，不能被中断，如果使用Lock，如果A不释放，可以使B在等待了足够长的时间以后，中断等待，而干别的事情。

3.synchronize实际上是ReentrantLock和Condition的组合的简化版

4.相对于synchonized独占锁，ReentrantReadWriteLock通过分离读锁和写锁，提供可共享的读锁提高读并发性能。