JMM与多线程

原子性操作与CAS

原子性操作指的是计算机中最小的操作单元（一次总线事务），只有一条指令，一旦执行则不会被中断。像一些基本类型int、boolean的读写都属于原子性操作，但是double和long除外（因为他们在内存中用64位表示 ，对他们的写操作被拆分为两个单独的32位写的原子性操作 ？为啥，这是因为主流的硬件处理器还是 以32位居多，如果以后64位的处理器取代了32位的，那可想而知long和double的读写也会是原子性的，JDK1.5后规定对long和double的读为原子性，而写继续拆分为两个原子操作）。经常听到有人争论加、自增这些操作到底是不是原子性操作。其实弄明白了原子性操作的含义，这个 问题也就没有争论的必要了。答案是否定的，加和自增都不是原子性操作，因为他们都是先读在写，他们执行的过程中有可能被中断。

前面提到的原子性操作，我理解为硬件层次上的原子性操作，CAS是一种重要的原子性操作。（pS：CAS-compare and swap，比较并设置，比较当前值和预期值是否相同，如果相同则设置为更新值。听起来比较绕口 ...其实他的作用就是，在当前线程对变量a的操作完成之前，其他线程没有对a有操作，怎么实现呢？简单，我们让当前线程在设置变量a的值之前，先取出a的值看一下是否与原来的值一样，如果不一样说明有其他线程对变量a操作过了，那当前线程就不能直接设置a的值了；如果一样，说明没有其他线程操作过a，那就可以直接设置a为要更新的值了。处理器保证这些操作都是在一个指令下完成的，一步完成，是原子的 ）。

在java中，为了给开发者更好的编程体验，提供一些封装好的程序层次“原子性操作”，参考java.util.concurrent.atomic包。拿AtomicInteger来说，这个类实现了整数一些原子性操作 ，比如加、自增，what？前面已经提过整数的自增操作是非原子性的，这不是自己打脸吗？其实不然，这里的AtomicInteger对int进行了封装，先不解释，直接上源码：

 1  /**
 2      * Atomically increments by one the current value.
 3      *
 4      * @return the previous value
 5      */
 6     public final int getAndIncrement() {
 7         for (;;) {
 8             int current = get();
 9             int next = current + 1;
10             if (compareAndSet(current, next))
11                 return current;
12         }
13     }

先看注释，“在当前值上原子性自增1，返回原先的值”，这不就是value++吗，没错，但这是个能保证“原子性”的自增。来看看他是怎么实现的，关键在于compareAndSet()函数：

 1  /**
 2      * Atomically sets the value to the given updated value
 3      * if the current value {@code ==} the expected value.
 4      *
 5      * @param expect the expected value  预期值
 6      * @param update the new value  更新值
 7      * @return true if successful. False return indicates that
 8      * the actual value was not equal to the expected value.
 9      */
10     public final boolean compareAndSet(int expect, int update) {
11     return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
12     }

不难发现，这个函数就是CAS的一种java实现。回过头去看getAndIncrement()，它做的事就是在一个无限for循环中CAS，知道CAS成功，退出循环。这就保证了在自增操作在读取值到更新值这个过程中没有其他线程更新过这个整数，如果有则重新读取值并自增后更新知道成功。到这里，可以总结一下了，AtomicInteger其实不是真正的原子操作，它只是利用CAS做了一个冲突检测，保证每个线程对整数的操作都是有效的。

JMM与可见性

JMM（Java Memory Model），java内存模型。通常，JVM将运行时内存区域分为方法区、堆、JVM栈、本地方法栈以及程序计数器。

方法区——存储类方法、常量池，为所有线程共享

堆——存储共享变量

JVM栈——存储局部变量、方法参数、返回值等

本地方法栈——调用本地方法的栈

程序计数器——指向当前执行的字节码

并发多线程之间的通信有两种方式——共享内存和消息传递。在共享内存模型里，并发线程通过读写共享的内存区域来通信（同步）；在消息传递模型里，并发线程通过发送和接收消息来通信。Java的并发通信采用是共享内存模型，即JMM

上图中，线程A和线程B共享主存（堆）中的变量S=0，它们不会直接操作主存中的S，而是操作各自缓存的S的副本（各自的线程栈中，只能本线程访问）。why？这是由于CPU的速度比主存的读写速度快得多，将主存中的S缓存到线程的本地内存（指的是缓存、寄存器等）能提高读取速度，避免CPU因为每次读写主存而空闲。现在，假设线程A执行S=1，线程B怎样catch到这个更新呢？

1、线程A更新本地内存副本S_A=1，并刷新到主存S=1

2、线程B从主存读取S=1，并刷新本地内存副本S_B=1

这个过程其实就是线程A通过主存向线程B传递了一个消息（S=1），其中JMM控制了线程的本地内存与主存之间的交互，保证了多线程之间的可见性。

顺序一致性和缓存一致性

线程的状态

就绪

运行

阻塞

Thread类的方法：

Thread.sleep():当前线程休眠（阻塞），让出时间片

t.join():等待线程t执行完，当前线程在继续执行

Thread.yield():当前线程变为就绪状态，和其他相同优先级的线程一起竞争CPU时间片

线程同步

锁的实现原理

entermonitor

exitmonitor

synchronized关键字

java中每个对象的头中都保存有一个锁字段，sychronized(obj)表示获取此对象的锁，所有同步的代码块在进入执行之前都必须获取同步对象的锁，同步的方式有几种：

synchronized(obj)

synchronized method(),实际上是用该持有该方法的类实例对象的锁做同步

synchronized static mehtod(),实际上是用持有该静态方法的类的锁做同步

wait、notify/notifyAll

wait()、notify()/notifyAll()不是Thread类的方法，而是Object类的方法，主要用于对对象锁的操作（任何对象在对象头中都保存有锁字段）

wait()、notify()/notifyAll()必须在sychronized修饰的同步代码中执行，否则编译能通过，但是会报IllegaMonitorStateException运行时异常

wait()方法：当前线程（指的是当前取得CPU时间片正在运行的线程）释放对象锁，处于阻塞状态（等待锁），等待其他线程唤醒

notify()方法：唤醒锁上等待的线程中一个（JVM决定，不一定是优先级最高的），解除阻塞状态，能够竞争锁，但需要等到他获得锁之后才能真正执行

notifyAll()方法：唤醒锁上等待的所有线程（notify之前的线程），解除阻塞并可以争夺锁

JMM与多线程

原文：http://www.cnblogs.com/summerautumn/p/5158612.html