线程安全
volite:java
在 java 垃圾回收整理一文中，描述了jvm运行时刻内存的分配。其中有一个内存区域是jvm虚拟机栈，每个线程运行时都有一个线程栈，数组
线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候，首先经过对象的引用找到对应在堆内存的变量的值，而后把堆内存缓存
变量的具体值load到线程本地内存中，创建一个变量副本，以后线程就再也不和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，安全
在修改完以后的某一个时刻（线程退出以前），自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了。下面一幅图数据结构
描述这写交互多线程
read and load 从主存复制变量到当前工做内存
use and assign 执行代码，改变共享变量值
store and write 用工做内存数据刷新主存相关内容架构
其中use and assign 能够屡次出现并发
可是这一些操做并非原子性，也就是 在read load以后，若是主内存count变量发生修改以后，线程工做内存中的值因为已经加载，不会产生对应的变化，因此计算出来的结果会和预期不同oracle
对于volatile修饰的变量，jvm虚拟机只是保证从主内存加载到线程工做内存的值是最新的jvm
例如假如线程1，线程2 在进行read,load 操做中，发现主内存中count的值都是5，那么都会加载这个最新的值
在线程1堆count进行修改以后，会write到主内存中，主内存中的count变量就会变为6
线程2因为已经进行read,load操做，在进行运算以后，也会更新主内存count的变量值为6
致使两个线程及时用volatile关键字修改以后，仍是会存在并发的状况。
synrhronized:
synrhronized关键字简洁、清晰、语义明确，所以即便有了Lock接口，使用的仍是很是普遍。其应用层的语义是能够把任何一个非null对象 做为"锁"，当synchronized做用在方法上时，锁住的即是对象实例（this）；看成用在静态方法时锁住的即是对象对应的Class实例，由于 Class数据存在于永久带，所以静态方法锁至关于该类的一个全局锁；当synchronized做用于某一个对象实例时，锁住的即是对应的代码块。在 HotSpot JVM实现中，锁有个专门的名字：对象监视器。
1. 线程状态及状态转换
当多个线程同时请求某个对象监视器时，对象监视器会设置几种状态用来区分请求的线程：
Contention List：全部请求锁的线程将被首先放置到该竞争队列
Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List
Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set
OnDeck：任什么时候刻最多只能有一个线程正在竞争锁，该线程称为OnDeck
Owner：得到锁的线程称为Owner
!Owner：释放锁的线程
下图反映了个状态转换关系：
新请求锁的线程将首先被加入到ConetentionList中，当某个拥有锁的线程（Owner状态）调用unlock以后，若是发现 EntryList为空则从ContentionList中移动线程到EntryList，下面说明下ContentionList和EntryList 的实现方式：
1.1 ContentionList 虚拟队列
ContentionList并非一个真正的Queue，而只是一个虚拟队列，缘由在于ContentionList是由Node及其next指 针逻辑构成，并不存在一个Queue的数据结构。ContentionList是一个后进先出（LIFO）的队列，每次新加入Node时都会在队头进行， 经过CAS改变第一个节点的的指针为新增节点，同时设置新增节点的next指向后续节点，而取得操做则发生在队尾。显然，该结构实际上是个Lock- Free的队列。
由于只有Owner线程才能从队尾取元素，也即线程出列操做无争用，固然也就避免了CAS的ABA问题。
1.2 EntryList
EntryList与ContentionList逻辑上同属等待队列，ContentionList会被线程并发访问，为了下降对 ContentionList队尾的争用，而创建EntryList。Owner线程在unlock时会从ContentionList中迁移线程到 EntryList，并会指定EntryList中的某个线程（通常为Head）为Ready（OnDeck）线程。Owner线程并非把锁传递给 OnDeck线程，只是把竞争锁的权利交给OnDeck，OnDeck线程须要从新竞争锁。这样作虽然牺牲了必定的公平性，但极大的提升了总体吞吐量，在 Hotspot中把OnDeck的选择行为称之为“竞争切换”。
OnDeck线程得到锁后即变为owner线程，没法得到锁则会依然留在EntryList中，考虑到公平性，在EntryList中的位置不 发生变化（依然在队头）。若是Owner线程被wait方法阻塞，则转移到WaitSet队列；若是在某个时刻被notify/notifyAll唤醒， 则再次转移到EntryList。
2. 自旋锁
那些处于ContetionList、EntryList、WaitSet中的线程均处于阻塞状态，阻塞操做由操做系统完成（在Linxu下通 过pthread_mutex_lock函数）。线程被阻塞后便进入内核（Linux）调度状态，这个会致使系统在用户态与内核态之间来回切换，严重影响 锁的性能
缓解上述问题的办法即是自旋，其原理是：当发生争用时，若Owner线程能在很短的时间内释放锁，则那些正在争用线程能够稍微等一等（自旋）， 在Owner线程释放锁后，争用线程可能会当即获得锁，从而避免了系统阻塞。但Owner运行的时间可能会超出了临界值，争用线程自旋一段时间后仍是没法 得到锁，这时争用线程则会中止自旋进入阻塞状态（后退）。基本思路就是自旋，不成功再阻塞，尽可能下降阻塞的可能性，这对那些执行时间很短的代码块来讲有非 常重要的性能提升。自旋锁有个更贴切的名字：自旋-指数后退锁，也即复合锁。很显然，自旋在多处理器上才有意义。
还有个问题是，线程自旋时作些啥？其实啥都不作，能够执行几回for循环，能够执行几条空的汇编指令，目的是占着CPU不放，等待获取锁的机 会。因此说，自旋是把双刃剑，若是旋的时间过长会影响总体性能，时间太短又达不到延迟阻塞的目的。显然，自旋的周期选择显得很是重要，但这与操做系统、硬 件体系、系统的负载等诸多场景相关，很难选择，若是选择不当，不但性能得不到提升，可能还会降低，所以你们广泛认为自旋锁不具备扩展性。
自旋优化策略
对自旋锁周期的选择上，HotSpot认为最佳时间应是一个线程上下文切换的时间，但目前并无作到。通过调查，目前只是经过汇编暂停了几个CPU周期，除了自旋周期选择，HotSpot还进行许多其余的自旋优化策略，具体以下：
若是平均负载小于CPUs则一直自旋
若是有超过(CPUs/2)个线程正在自旋，则后来线程直接阻塞
若是正在自旋的线程发现Owner发生了变化则延迟自旋时间（自旋计数）或进入阻塞
若是CPU处于节电模式则中止自旋
自旋时间的最坏状况是CPU的存储延迟（CPU A存储了一个数据，到CPU B得知这个数据直接的时间差）
自旋时会适当放弃线程优先级之间的差别
那synchronized实现什么时候使用了自旋锁？答案是在线程进入ContentionList时，也即第一步操做前。线程在进入等待队列时 首先进行自旋尝试得到锁，若是不成功再进入等待队列。这对那些已经在等待队列中的线程来讲，稍微显得不公平。还有一个不公平的地方是自旋线程可能会抢占了 Ready线程的锁。自旋锁由每一个监视对象维护，每一个监视对象一个。
3. JVM1.6偏向锁
在JVM1.6中引入了偏向锁，偏向锁主要解决无竞争下的锁性能问题，首先咱们看下无竞争下锁存在什么问题：
如今几乎全部的锁都是可重入的，也即已经得到锁的线程能够屡次锁住/解锁监视对象，按照以前的HotSpot设计，每次加锁/解锁都会涉及到一些CAS操 做（好比对等待队列的CAS操做），CAS操做会延迟本地调用，所以偏向锁的想法是一旦线程第一次得到了监视对象，以后让监视对象“偏向”这个 线程，以后的屡次调用则能够避免CAS操做，说白了就是置个变量，若是发现为true则无需再走各类加锁/解锁流程。但还有不少概念须要解释、不少引入的 问题须要解决：
3.1 CAS及SMP架构
CAS为何会引入本地延迟？这要从SMP（对称多处理器）架构提及，下图大概代表了SMP的结构：
其意思是全部的CPU会共享一条系统总线（BUS），靠此总线链接主存。每一个核都有本身的一级缓存，各核相对于BUS对称分布，所以这种结构称为“对称多处理器”。
而CAS的全称为Compare-And-Swap，是一条CPU的原子指令，其做用是让CPU比较后原子地更新某个位置的值，通过调查发现， 其实现方式是基于硬件平台的汇编指令，就是说CAS是靠硬件实现的，JVM只是封装了汇编调用，那些AtomicInteger类即是使用了这些封装后的 接口。
Core1和Core2可能会同时把主存中某个位置的值Load到本身的L1 Cache中，当Core1在本身的L1 Cache中修改这个位置的值时，会经过总线，使Core2中L1 Cache对应的值“失效”，而Core2一旦发现本身L1 Cache中的值失效（称为Cache命中缺失）则会经过总线从内存中加载该地址最新的值，你们经过总线的来回通讯称为“Cache一致性流量”，由于总 线被设计为固定的“通讯能力”，若是Cache一致性流量过大，总线将成为瓶颈。而当Core1和Core2中的值再次一致时，称为“Cache一致 性”，从这个层面来讲，锁设计的终极目标即是减小Cache一致性流量。
而CAS刚好会致使Cache一致性流量，若是有不少线程都共享同一个对象，当某个Core CAS成功时必然会引发总线风暴，这就是所谓的本地延迟，本质上偏向锁就是为了消除CAS，下降Cache一致性流量。
Cache一致性：
上面提到Cache一致性，实际上是有协议支持的，如今通用的协议是MESI（最先由Intel开始支持），具体参考：http://en.wikipedia.org/wiki/MESI_protocol，之后会仔细讲解这部分。
Cache一致性流量的例外状况：
其实也不是全部的CAS都会致使总线风暴，这跟Cache一致性协议有关，具体参考：http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot
NUMA(Non Uniform Memory Access Achitecture）架构：
与SMP对应还有非对称多处理器架构，如今主要应用在一些高端处理器上，主要特色是没有总线，没有公用主存，每一个Core有本身的内存，针对这种结构此处不作讨论。
3.2 偏向解除
偏向锁引入的一个重要问题是，在多争用的场景下，若是另一个线程争用偏向对象，拥有者须要释放偏向锁，而释放的过程会带来一些性能开销，但整体说来偏向锁带来的好处仍是大于CAS代价的。
4. 总结
关于锁，JVM中还引入了一些其余技术好比锁膨胀等，这些与自旋锁、偏向锁相比影响不是很大，这里就不作介绍。
经过上面的介绍能够看出，synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但得到了高吞吐量。
ReentrantLock :
实现Lock接口的基本思想
须要实现锁的功能，两个必备元素，一个是表示（锁）状态的变量（咱们假设0表示没有线程获取锁，1表示已有线程占有锁），另外一个是队列，队列中的节点表示因未能获取锁而阻塞的线程。为了解决多核处理器下多线程缓存不一致的问题，表示状态的变量必须声明为voaltile类型，而且对表示状态的变量和队列的某些操做要保证原子性和可见性。原子性和可见性的操做主要经过Atomic包中的方法实现。
线程获取锁的大体过程（这里没有考虑可重入和获取锁过程被中断或超时的状况）
1. 读取表示锁状态的变量
2. 若是表示状态的变量的值为0，那么当前线程尝试将变量值设置为1（经过CAS操做完成），当多个线程同时将表示状态的变量值由0设置成1时，仅一个线程能成功，其
它线程都会失败
2.1 若成功，表示获取了锁，
2.1.1 若是该线程（或者说节点）已位于在队列中，则将其出列（并将下一个节点则变成了队列的头节点）
2.1.2 若是该线程未入列，则不用对队列进行维护
而后当前线程从lock方法中返回，对共享资源进行访问。
2.2 若失败，则当前线程将自身放入等待（锁的）队列中并阻塞自身，此时线程一直被阻塞在lock方法中，没有从该方法中返回（被唤醒后仍然在lock方法中，并从下一条语句继续执行，这里又会回到第1步从新开始）。
3. 若是表示状态的变量的值为1，那么将当前线程放入等待队列中，而后将自身阻塞（被唤醒后仍然在lock方法中，并从下一条语句继续执行，这里又会回到第1步从新开始）
注意: 唤醒并不表示线程能马上运行，而是表示线程处于就绪状态，仅仅是能够运行而已
线程释放锁的大体过程
1. 释放锁的线程将状态变量的值从1设置为0，并唤醒等待（锁）队列中的队首节点，释放锁的线程从就从unlock方法中返回，继续执行线程后面的代码
2. 被唤醒的线程（队列中的队首节点）和可能和未进入队列而且准备获取的线程竞争获取锁，重复获取锁的过程
注意：可能有多个线程同时竞争去获取锁，可是一次只能有一个线程去释放锁，队列中的节点都须要它的前一个节点将其唤醒，例若有队列A<-B-<C ，即由A释放锁时唤醒B，B释放锁时唤醒C
3. 公平锁和非公平锁
锁能够分为公平锁和不公平锁，重入锁和非重入锁（关于重入锁的介绍会在ReentrantLock源代码分析中介绍），以上过程其实是非公平锁的获取和释放过程。
公平锁严格按照先来后到的顺去获取锁，而非公平锁容许插队获取锁。
公平锁获取锁的过程上有些不一样，在使用公平锁时，某线程想要获取锁，不只须要判断当前表示状态的变量的值是否为0，还要判断队列里是否还有其余线程，若队列中还有线程则说明当前线程须要排队，进行入列操做，并将自身阻塞；若队列为空，才能尝试去获取锁。而对于非公平锁，当表示状态的变量的值是为0，就能够尝试获取锁，没必要理会队列是否为空，这样就实现了插队获取锁的特色。一般来讲非公平锁的吞吐率比公平锁要高，咱们通常经常使用非公平锁。
这里须要解释一点，什么状况下才会出现，表示锁的状态的变量的值是为0并且队列中仍有其它线程等待获取锁的状况。
假设有三个线程A、B、C。A线程为正在运行的线程并持有锁，队列中有一个C线程，位于队首。如今A线程要释放锁，具体执行的过程操做可分为两步：
1. 将表示锁状态的变量值由1变为0，
2. C线程被唤醒，这里要明确两点：
（1）C线程被唤醒并不表明C线程开始执行，C线程此时是处于就绪状态，要等待操做系统的调度
（2）C线程目前还并未出列，C线程要进入运行状态，而且经过竞争获取到锁之后才会出列。
若是C线程此时尚未进入运行态，同时未在队列中的B线程进行获取锁的操做，B就会发现虽然当前没有线程持有锁，可是队列不为空（C线程仍然位于队列中），要知足先来后到的特色（B在C以后执行获取锁的操做），B线程就不能去尝试获取锁，而是进行入列操做。
4. 实现Condition接口的基本思想
Condition 本质是一个接口，它包含以下方法
// 让线程进入等通知待状态void await() throws InterruptedException; void awaitUninterruptibly();//让线程进入等待通知状态，超时结束等待状态，并抛出异常 long awaitNanos(long nanosTimeout) throws InterruptedException; boolean await(long time, TimeUnit unit) throws InterruptedException; boolean awaitUntil(Date deadline) throws InterruptedException; //将条件队列中的一个线程，从等待通知状态转换为等待锁状态 void signal(); //将条件队列中的全部线程，从等待通知阻塞状态转换为等待锁阻塞状态 void signalAll();
一个Condition实例的内部实际上维护了一个队列，队列中的节点表示因为（某些条件不知足而）线程自身调用await方法阻塞的线程。Condition接口中有两个重要的方法，即 await方法和 signal方法。线程调用这个方法以前该线程必须已经获取了Condition实例所依附的锁。这样的缘由有两个，（1）对于await方法，它内部会执行释放锁的操做，因此使用前必须获取锁。（2）对于signal方法，是为了不多个线程同时调用同一个Condition实例的singal方法时引发的（队列）出列竞争。下面是这两个方法的执行流程。
await方法：
1. 入列到条件队列（注意这里不是等待锁的队列）
2. 释放锁
3. 阻塞自身线程
------------被唤醒后执行-------------
4. 尝试去获取锁（执行到这里时线程已不在条件队列中，而是位于等待（锁的）队列中，参见signal方法）
4.1 成功，从await方法中返回，执行线程后面的代码
4.2 失败，阻塞本身（等待前一个节点释放锁时将它唤醒）
注意：await方法时自身线程调用的，线程在await方法中阻塞，并无从await方法中返回，当唤醒后继续执行await方法中后面的代码（也就是获取锁的代码）。能够看出await方法释放了锁，又尝试得到锁。当获取锁不成功的时候当前线程仍然会阻塞到await方法中，等待前一个节点释放锁后再将其唤醒。
signal方法：
1. 将条件队列的队首节点取出，放入等待锁队列的队尾
2. 唤醒该节点对应的线程
注意：signal是由其它线程调用
Lock和Condition的使用例程
下面这个例子，就是利用lock和condition实现B线程先打印一句信息后，而后A线程打印两句信息（不能中断），交替十次后结束
public class ConditionDemo {
volatile int key = 0;
Lock l = new ReentrantLock();
Condition c = l.newCondition();
public static void main(String[] args){
ConditionDemo demo = new ConditionDemo();
new Thread(demo.new A()).start();
new Thread(demo.new B()).start();
}
class A implements Runnable{
@Override
public void run() {
int i = 10;
while(i > 0){
l.lock();
try{
if(key == 1){
System.out.println("A is Running");
System.out.println("A is Running");
i--;
key = 0;
c.signal();
}else{
c.awaitUninterruptibly();
}
}
finally{
l.unlock();
}
}
}
}
class B implements Runnable{
@Override
public void run() {
int i = 10;
while(i > 0){
l.lock();
try{
if(key == 0){
System.out.println("B is Running");
i--;
key = 1;
c.signal();
}else{
c.awaitUninterruptibly();
}
}
finally{
l.unlock();
}
}
}
}
}
5. Lock与synchronized的区别
1. Lock的加锁和解锁都是由java代码配合native方法（调用操做系统的相关方法）实现的，而synchronize的加锁和解锁的过程是由JVM管理的
2. 当一个线程使用synchronize获取锁时，若锁被其余线程占用着，那么当前只能被阻塞，直到成功获取锁。而Lock则提供超时锁和可中断等更加灵活的方式，在未能获取锁的 条件下提供一种退出的机制。
3. 一个锁内部能够有多个Condition实例，即有多路条件队列，而synchronize只有一路条件队列；一样Condition也提供灵活的阻塞方式，在未得到通知以前能够经过中断线程以 及设置等待时限等方式退出条件队列。
4. synchronize对线程的同步仅提供独占模式，而Lock便可以提供独占模式，也能够提供共享模式
Atomic
Atomic包是java.util.concurrent下的另外一个专门为线程安全设计的Java包，包含多个原子操做类。这个包里面提供了一组原子变量类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具备排他性，即当某个线程进入方法，执行其中的指令时，不会被其余线程打断，而别的线程就像自旋锁同样，一直等到该方法执行完成，才由JVM从等待队列中选择一个另外一个线程进入，这只是一种逻辑上的理解。其实是借助硬件的相关指令来实现的，不会阻塞线程(或者说只是在硬件级别上阻塞了)。能够对基本数据、数组中的基本数据、对类中的基本数据进行操做。原子变量类至关于一种泛化的volatile变量，可以支持原子的和有条件的读-改-写操做