前沿
最近看《深入理解java虚拟机》这本书感触颇深，所以专门写了这一系列的博客。
java内存模型与线程
java内存模型
工作内存与住内存
java内存模型的主要目的就是确定变量的访问规则，及在ＪＶＭ中将变量存储到内存中和从内存中取出的底层细节，这里的变量包括实例字段、静态字段、数组中的元素。但不包括局部变量和方法的参数，因为后者是线程私有的不存在竞争问题。
java内存模型规定所有的变量都存储在主内存中，各个线程都有自己的工作内存，工作内存中包含此线程用到的主内存变量的副本，各个线程的工作内存之际是无法
直接访问的，必须通过主内存来完成，线程、 工作内存、主内存之间的关系如下图： 
内存间交互操作
主内存与工作内存的交互协议是指一个变量从
主内存中拷贝到工作内存和从工作内存同步到主内存的实现细节。jvm定义了8
种基本操作来实现这一功能，这些操作都是原子的。不可分割的：
lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中。
如果一个变量想从主内存拷贝到工作内存则必须严格执行read和load的操作，如果变量从工作内存同步到主内存则必须严格执行store和write操作。当然这两组操着中间可以执行其他的操作。不允许read和load、store和write之一的操作出现。
不允许一个线程丢弃它最近的assign操作，及变量在工作内存中修改了必须同步到主内存中。同时不允许无原因（没有assign操作）的将工作内存的数据同步到主内存中。
一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说，就是对一个变量实施use、 store操作之前，必须先执行过了assign和load操作。
一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定住的变量。
对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、 write操作）。
这8种内存访问操作以及上述规则限定，再加上稍后介绍的对volatile的一些特殊规定，就已经完全确定了Java程序中哪些内存访问操作在并发下是安全的。
原子性、可见性、有序性
java内存模型是围绕着并发过程中的原子性、可见性、有序性展开的。只要保证操作满足这三点，并发就是线程安全的，否则就是不安全的。
原子性：又java内存模型直接保证原子性的是对基本数据类型的读写（read load store write assign use）。要保证更大范围的原子性就要用到synchronized关键字。
可见性:可见性是指一个线程改变了变量的值，其他线程可以立刻知道。有volatile修饰的变量就具有可见性，当线程修改了普通变量时，这个线程需要同步到主内存中，其他线程再从主内存中取得这个变量的值，这样其他线程才能获得这个值的最新数据。如果多个线程同时修改一个变量的值，最终这个变量的值是不确定的。因为工作内存的变量值何时同步到主内存中是不确定的，由具体jvm的规则决定，从代码角度无法确定。当变量被volatile修饰时，这个变量在工作内存中没有副本，直接从主内存中读取和写入，不存在可见性问题，同时synchronized和final同样可以实现可见性功能。这些在后面会详细讲解
。
有序性： Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。 前半句是指“线程内表现为串行的语义”（Within-Thread As-If-Serial Semantics），后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进入。
volatile 关键字
volatile保证了代码的可见性和防止代码重排序，但不能保证原子性和同步代码块的有序性访问。在一定条件下是线程安全的，是一种轻量级的同步机制。在以下条件下是线程安全的：
运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
变量不需要与其他的状态变量共同参与不变约束。
这种限制特别适合赋值操作。例如：
public class Test{
public volatile int a;
public void setA(int a){
this.a=a;
}
} 在多个线程下对a赋值时对可以时其他线程可见，普通变量不具有这种特性，但volatile也就仅此而已。可用范围很小。但比synchronized同步消耗资源小。
先行发生原则
先行发生原则是指，无需任何同步机制也不会发生线程安全问题，其本质就是在某些条件下时间的先后顺序就是操作执行的先后顺序。符合这种条件的只有下面几种：
程序次序规则（Program Order Rule）：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。 准确地说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支、 循环等结构。
管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。 这里必须强调的是同一个锁，而“后面”是指时间上的先后顺序。
volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。
线程启动规则（Thread Start Rule）：Thread对象的start（）方法先行发生于此线程的每一个动作。
线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join（）方法结束、 Thread.isAlive（）的返回值等手段检测到线程已经终止执行。
线程中断规则（Thread Interruption Rule）：对线程interrupt（）方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted（）方法检测到是否有中断发生。
对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize（）方法的开始。
传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
除了上面的例子之外其他情况都是线程不安全的。例如
：
private int value=0；
pubilc void setValue（int value）{
this.value=value；
}p
ublic int getValue（）{
return value；
}线程A先（时间上的先后）调用了“setValue（1）”，然后线程B调用了同一个对象的“getValue（）”，那么线程B收到的返回值是什么？’你会发现他不符合上面的任何一种情况，所以并不保证setValue（1）一定先执行。除非这两个方法都被synchronized修饰。
java与线程
线程的实现
线程是比进程更加轻量级的调度单位，线程的引入将进程的资源分配与执行调度分开，线程之间既可以共享进程的资源（内存地址、I/O资源）又可以独立调度，是cup调度的基本单元。
Java语言则提供了在不同硬件和操作系统平台下对线程操作的统一处理，每个已经执行start（）且还未结束的java.lang.Thread类的实例就代表了一个线程。Thread类的很多方法都是native的，说明这些方法的实现都是与平台相关的。
实现线程主要有三种方式：使用内核线程、使用用户线程、使用用核线程加轻量级进程实现。
内核线程：内核线程是由操作系统内核直接支持的线程，内核通过调度器对线程进行调度并将其映射到各个处理器上。用户一般不直接操作内核线程而是操作轻量级进程。轻量级进程与内核线程之间是1：1的关系。轻量级进程是一个独立的调度单元，一个阻塞了不会影响整个进程进行。但其也有局限性：1）由于需要内核线程的支持，其创建、构析及同步都需要系统调用，而系统调用需要从用户态转到内核态，代价较大。2）每个轻量级进程到需要一个内核线程支持，消耗内核资源（内核线程的栈空间），因此其数量是有限的。
用户线程：用户线程是完全建立在用户空间的进程库中的，内核不能感知线程的存在，其建立、同步、销毁和调度都是在用户态完成的，不需要内核帮忙。其优点是操作快速低耗且支持大规模的线程。缺点恰恰也是其优点，由于所有操作都是用户独立完成，其线程的调度、线程切换、线程阻塞变得异常复杂。
用户线程与轻量级进程混合开发：轻量级进程作为用户线程与内核的桥梁，用户线程的创建、切换、析构依然廉价，同时又可以利用内核提供的线程调度及处理器映射。用户线程与轻量级进程之间数量关系是：N:M。在java的window和linux版本是1：1的关系。
java线程调度
线程调度是线程分配处理器使用权的过程，其分为两种：1）协同时线程调度，2）抢占式线程调度。
协同式线程调度是指线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上。这种在java中很少出现了。
抢占式线程调度：每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定。用户可以设置线程的级别来希望系统多分配某些线程多一些时间，但是不一定靠谱。
线程状态转换
java语言规定了线程的五种状态，一个时刻只能处于一种状态:
新建（New）：创建后尚未启动的线程处于这种状态。
运行（Runable）：Runable包括了操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间。
无限期等待（Waiting）：处于这种状态的线程不会被分配CPU执行时间，它们要等待被其他线程显式地唤醒。 以下方法会让线程陷入无限期的等待状态：
●没有设置Timeout参数的Object.wait（）方法。
●没有设置Timeout参数的Thread.join（）方法。
●LockSupport.park（）方法。
限期等待（Timed Waiting）：处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。 以下方法会让线程进入限期等待状态：
●Thread.sleep（）方法。
●设置了Timeout参数的Object.wait（）方法。
●设置了Timeout参数的Thread.join（）方法。
●LockSupport.parkNanos（）方法。
●LockSupport.parkUntil（）方法。
阻塞（Blocked）：线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状态”则是在等待一段时间，或者唤醒动作的发生。 在程序等待进入同步区域的时候，线程将进入这种状态。
结束（Terminated）：已终止线程的线程状态，线程已经结束执行。
五种状态的关系如下图所示：
线程安全与锁优化
线程安全
java语言中的线程的安全
按照线程安全的“安全程度”由强至弱来排序，我们可以将Java语言中各种操作共享的数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立，：
1.相对的线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作是线程安全的，我们在调用的时候不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。在Java语言中，大部分的线程安全类都属于这种类型，例如Vector、 HashTable、Collections的synchronizedCollection（）方法包装的集合等。
2.线程兼容：线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用，我们平常说一个类不是线程安全的，绝大多数时候指的是这一种情况。 Java API中大部分的类都是属于线程兼容的，如与前面的Vector和HashTable相对应的集合类ArrayList和HashMap等。
3.线程对立：线程对立是指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。 由于Java语言天生就具备多线程特性，线程对立这种排斥多线程的代码是很少出现的，而且通常都是有害的，应当尽量避免。
线程安全的实现方法
1.互斥同步
同步是指多个线程并发访问共享数据的时候，同一时刻只能被一个线程使用。互斥是实现同步的手段，临界区（Critical Section）、 互斥量（Mutex）和信号量（Semaphore）都是主要的互斥实现方式。 因此，在这4个字里面，互斥是因，同步是果；互斥是方法，同步是目的。
在Java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。 如果Java程序中的synchronized明确指定了对象参数，那就是这个对象的reference；如果没有明确指定，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。根据虚拟机规范的要求，在执行monitorenter指令时，首先要尝试获取对象的锁。 如果这
个对象没被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器加1，相应的，在执行monitorexit指令时会将锁计数器减1，当计数器为0时，锁就被释放。 如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另外一个线程释放为止。在虚拟机规范对monitorenter和monitorexit的行为描述中，有两点是需要特别注意的。 首先，synchronized同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题。 其次，同步块在已进入的线程执行完之前，会阻塞后面其他线程的进入。 Java的线程是映射到操作系统的原生线程之上的，如果要阻塞或唤醒一个线程，都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间。对于代码简单的同步块（如被synchronized修饰的getter（）或setter（）方法），状态转换消耗的时间有可能比用户代码执行的时间还要长。 所以synchronized是Java语言中一个重量级（Heavyweight）的操作，有经验的程序员都会在确实必要的情况下才使用这种操作。 而虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，避免
频繁地切入到核心态之中。
2.非阻塞同步
互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronization）。 从处理问题的方式上说，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享数据是否真的会出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁）、 用户态核心态转换、 维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。 随着硬件指令集的发展，我们有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步（Non-Blocking Synchronization）。为什么笔者说使用乐观并发策略需要“硬件指令集的发展”才能进行呢？因为我们需要操作和冲突检测这两个步骤具备原子性，靠什么来保证呢？如果这里再使用互斥同步来保证就失去意义了，所以我们只能靠硬件来完成这件事情，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类指令常用的有：
测试并设置（Test-and-Set）。
获取并增加（Fetch-and-Increment）。
交换（Swap）。
比较并交换（Compare-and-Swap，下文称CAS）。
加载链接/条件存储（Load-Linked/Store-Conditional，下文称LL/SC）。
其中，前面的3条是20世纪就已经存在于大多数指令集之中的处理器指令，后面的两条是现代处理器新增的，而且这两条指令的目的和功能是类似的。 在IA64、 x86指令集中有cmpxchg指令完成CAS功能，在sparc-TSO也有casa指令实现，而在ARM和PowerPC架构下，则需要使用一对ldrex/strex指令来完成LL/SC的功能。CAS指令需要有3个操作数，分别是内存位置（在Java中可以简单理解为变量的内存地址，用V表示）、 旧的预期值（用A表示）和新值（用B表示）。 CAS指令执行时，当且仅当V符合旧预期值A时，处理器用新值B更新V的值，否则它就不执行更新，但是无论是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作。在JDK 1.5之后，Java程序中才可以使用CAS操作，该操作由sun.misc.Unsafe类里面的compareAndSwapInt（）和compareAndSwapLong（）等几个方法包装提供，虚拟机在内部对这些方法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器CAS指令，没有方法调用的过程，或者可以认为是无条件内联进去了[2]。由于Unsafe类不是提供给用户程序调用的类（Unsafe.getUnsafe（）的代码中限制了只有启动类加载器（Bootstrap ClassLoader）加载的Class才能访问它），因此，如果不采用反射手段，我们只能通过其他的Java API来间接使用它，如J.U.C包里面的整数原子类，其中的compareAndSet（）和getAndIncrement（）等方法都使用了Unsafe类的CAS操作。
尽管CAS看起来很美，但显然这种操作无法涵盖互斥同步的所有使用场景，并且CAS从语义上来说并不是完美的，存在这样的一个逻辑漏洞：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然为A值，那我们就能说它的值没有被其他线程改变过了吗？如果在这段期间它的值曾经被改成了B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。 这个漏洞称为CAS操作的“ABA”问题。 J.U.C包为了解决这个问题，提供了一个带有标记的原子引用类“AtomicStampedReference”，它可以通过控制变量值的版本来保证CAS的正确性。 不过目前来说这个类比较“鸡肋”，大部分情况下ABA问题不会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效。
3.无同步方案
要保证线程安全，并不是一定就要进行同步，两者没有因果关系。 同步只是保证共享数据争用时的正确性的手段，如果一个方法本来就不涉及共享数据，那它自然就无须任何同步措施去保证正确性，因此会有一些代码天生就是线程安全的，笔者简单地介绍其中的两类。可重入代码（Reentrant Code）：这种代码也叫做纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。 相对线程安全来说，可重入性是更基本的特性，它可以保证线程安全，即所有的可重入的代码都是线程安全的，但是并非所有的线程安全的代码都是可重入的。可重入代码有一些共同的特征，例如不依赖存储在堆上的数据和公用的系统资源、 用到的状态量都由参数中传入、 不调用非可重入的方法等。 我们可以通过一个简单的原则来判断代码是否具备可重入性：如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。线程本地存储（Thread Local Storage）：如果一段代码中所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行？如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。符合这种特点的应用并不少见，大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会将产品的消费过程尽量在一个线程中消费完，其中最重要的一个应用实例就是经典Web交互模型中的“一个请求对应一个服务器线程”（Thread-per-Request）的处理方式，这种处理方式的广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全问题。Java语言中，如果一个变量要被多线程访问，可以使用volatile关键字声明它为“易变的”；如果一个变量要被某个线程独享，Java中就没有类似C++中__declspec（thread）[3]这样的关键字，不过还是可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。 每一个线程的Thread对象中都有一个ThreadLocalMap对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode为键，以本地线程变量为值的K-V值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V值对中找回对应的本地线程变量。
锁优化
1.自旋锁与自适应自旋
自旋锁是指当遇到互斥锁时不再阻塞，先自旋一段时间如果还无法获得同步锁
再阻塞，自适应自旋是指自旋的时间自适应
2.锁消除
锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。 锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。
3.锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。所以要将互斥锁的范围扩大。
4.轻量级锁
轻量级锁是JDK 1.6之中加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就称为“重量级”锁。 首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
5.偏向锁
偏向锁也是JDK 1.6中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。 如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。偏向锁的“偏”，就是偏心的“偏”、 偏袒“偏”，它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。