以前的一篇文章有过Syncronized和Volatile的使用，是单例中用到的，原文如下
同步(synchronized)简单说可以理解为共享的意思，如果资源不是共享的，就没必要进行同步。设置共享资源为同步的话，可以避免一些脏读情况。
synchronized的4种修饰位置
public synchronized void synMethod() { //方法体
}
2.对某一代码块使用,synchronized后跟括号,括号里是变量,这样,一次只有一个线程进入该代码块，如:
public int synMethod(int a1){ 代码块
synchronized(a1) {
//一次只能有一个线程进入
}
}
3.synchronized后面括号里是一对象,此时,线程获得的是对象锁.例如:
public class MyThread implements Runnable {
public static void main(String args[]) {
MyThread mt = new MyThread();
Thread t1 = new Thread(mt, "t1");
Thread t2 = new Thread(mt, "t2");
t1.start();
t2.start();
}
public void run() {
synchronized (this) {
System.out.println(Thread.currentThread().getName());
}
}
}
4.synchronized后面括号里是类.例如:
public static class Single2 { private static Single2 instance; private Single2() {} public static Single2 getInstance() { synchronized(Single2.class) { if (instance == null) { instance = new Single2(); } return instance; } }}锁类型
- 可重入锁：在执行对象中所有同步方法不用再次获得锁
- 可中断锁：在等待获取锁过程中可中断
- 公平锁： 按等待获取锁的线程的等待时间进行获取，等待时间长的具有优先获取锁权利
- 读写锁：对资源读取和写入的时候拆分为2部分处理，读的时候可以多线程一起读，写的时候必须同步地写
java中另一个使用锁的基本工具 Lock
synchronized与Lock的区别
看一下Lock的部分源码：
public interface Lock {
/**
* Acquires the lock.
*/
void lock();
/**
* Acquires the lock unless the current thread is
* {@linkplain Thread#interrupt interrupted}.
*/
void lockInterruptibly() throws InterruptedException;
/**
* Acquires the lock only if it is free at the time of invocation.
*/
boolean tryLock();
/**
* Acquires the lock if it is free within the given waiting time and the
* current thread has not been {@linkplain Thread#interrupt interrupted}.
*/
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
/**
* Releases the lock.
*/
void unlock();
}
从Lock接口中我们可以看到主要有个方法，这些方法的功能从注释中可以看出：
- lock()：获取锁，如果锁被暂用则一直等待
- unlock():释放锁
- tryLock(): 注意返回类型是boolean，如果获取锁的时候锁被占用就返回false，否则返回true
- tryLock(long time, TimeUnit unit)：比起tryLock()就是给了一个时间期限，保证等待参数时间
- lockInterruptibly()：用该锁的获得方式，如果线程在获取锁的阶段进入了等待，那么可以中断此线程，先去做别的事
Lock实现和synchronized不一样，后者是一种悲观锁，它胆子很小，它很怕有人和它抢吃的，所以它每次吃东西前都把自己关起来。而Lock呢底层其实是CAS乐观锁的体现，它无所谓，别人抢了它吃的，它重新去拿吃的就好啦，所以它很乐观。具体底层怎么实现，后期对current包下面的机制好好和大家说说，如果面试问起，你就说底层主要靠volatile和CAS操作实现。
使用synchronized 代码块相比方法有两点优势：
1、可以只对需要同步的使用 2、与wait()/notify()/nitifyAll()一起使用时，比较方便 ,前面 有过应用
volatile
作用：volatile关键字的作用是：使变量在多个线程间可见（具有可见性），但是仅靠volatile是不能保证线程的安全性，volatile关键字不具备synchronized关键字的原子性。
volatile关键字的两层语义
一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：
- 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
- 禁止进行指令重排序。
- volatile不保证原子性
大家想一下这段程序的输出结果是多少？也许有些朋友认为是10000。但是事实上运行它会发现每次运行结果都不一致，都是一个小于10000的数字。
可能有的朋友就会有疑问，不对啊，上面是对变量inc进行自增操作，由于volatile保证了可见性，那么在每个线程中对inc自增完之后，在其他线程中都能看到修改后的值啊，所以有10个线程分别进行了1000次操作，那么最终inc的值应该是1000*10=10000。
这里面就有一个误区了，volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的操作的原子性。
自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行，就有可能导致下面这种情况出现：
假如某个时刻变量inc的值为10，
线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了；
然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值，由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，所以线程2会直接去主存读取inc的值，发现inc的值时10，然后进行加1操作，并把11写入工作内存，最后写入主存。
然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11，然后将11写入工作内存，最后写入主存。
那么两个线程分别进行了一次自增操作后，inc只增加了1。
解释到这里，可能有朋友会有疑问，不对啊，前面不是保证一个变量在修改volatile变量时，会让缓存行无效吗？然后其他线程去读就会读到新的值，对，这个没错。这个就是上面的happens-before规则中的volatile变量规则，但是要注意，线程1对变量进行读取操作之后，被阻塞了的话，并没有对inc值进行修改。然后虽然volatile能保证线程2对变量inc的值读取是从内存中读取的，但是线程1没有进行修改，所以线程2根本就不会看到修改的值。
根源就在这里，自增操作不是原子性操作，而且volatile也无法保证对变量的任何操作都是原子性的。
可以通过synchronized，Lock或者AtomicInteger结合进行修饰保证原子性。
volatile能保证有序性吗？
在前面提到volatile关键字能禁止指令重排序，所以volatile能在一定程度上保证有序性。
volatile关键字禁止指令重排序有两层意思：
1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；
2）在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。
volatile的原理和实现机制
前面讲述了源于volatile关键字的一些使用，下面我们来探讨一下volatile到底如何保证可见性和禁止指令重排序的。
下面这段话摘自《深入理解Java虚拟机》：
“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”
lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：
1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；
2）它会强制将对缓存的修改操作立即写入主存；
3）如果是写操作，它会导致其他CPU中对应的缓存行无效。
volatile 与 synchronized 的比较：
①volatile轻量级，只能修饰变量。synchronized重量级，还可修饰方法
②volatile只能保证数据的可见性，不能用来同步，因为多个线程并发访问volatile修饰的变量不会阻塞。
synchronized不仅保证可见性，而且还保证原子性，因为，只有获得了锁的线程才能进入临界区，从而保证临界区中的所有语句都全部执行。多个线程争抢synchronized锁对象时，会出现阻塞。
线程安全性包括 原子性问题，可见性问题，有序性问题。
CAS
无锁的非堵塞算法采用一种比较交换技术CAS（compare and swap）来鉴别线程冲突，一旦检测到冲突，就充实当前操作指导没有冲突为止。CAS基于硬件实现，不需要进入内核，不需要切换线程，因此可以获得更高的性能。但对于资源竞争严重的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源。
CAS是项乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。
CAS（比较并交换）是CPU指令级的操作，只有一步原子操作，CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。CAS语义是“我认为V的值应该是A，如果是，那么就将V的值更新成B， 否则不更新，并告诉V的实际是是多少”。
伪代码可以这样表示：
do{ 备份旧数据； 基于旧数据构造新数据； }while(!CAS( 内存地址，备份的旧数据，新数据 )) 就是指当两者进行比较时，如果相等，则证明共享数据没有被修改，替换成新值，然后继续往下运行；如果不相等，说明共享数据已经被修改，放弃已经所做的操作，然后重新执行刚才的操作。容易看出 CAS 操作是基于共享数据不会被修改的假设，采用了类似于数据库的 commit-retry 的模式。当同步冲突出现的机会很少时，这种假设能带来较大的性能提升。
JVM中的CAS
堆中对象的分配
我们都知道java调用new object()会创建一个对象，这个对象会被分配到JVM的堆中。那么这个对象到底是怎么在堆中保存的呢？
首先，new object()执行的时候，这个对象需要多大的空间，其实是已经确定的，因为java中的各种数据类型，占用多大的空间都是固定的（对其原理不清楚的请自行Google）。那么接下来的工作就是在堆中找出那么一块空间用于存放这个对象。 在单线程的情况下，一般有两种分配策略：
指针碰撞
这种一般适用于内存是规整的（内存是否规整取决于内存回收策略），分配空间的工作只是将指针像空闲内存一侧移动对象大小的距离即可。
空闲列表
这种适用于内存非规整的情况，这种情况下JVM会维护一个内存列表，记录那些内存区域是空闲的，大小是多少哦啊。给对象分配空间的时候去空闲列表里查询到合适的区域然后进行分配即可
但是JVM不可能一直在单线程状态下运行，那样效率太差了。由于再给一个对象分配内存的时候不是原子性的操作，至少需要以下几步：查找空闲列表、分配内存、修改空闲列表等等，这是不安全的。解决并发时的安全问题也有两种策略
CAS缺点：
虽然CAS有效的解决了原子操作的问题，但是其仍然有三个劣势：
1、ABA问题：因为CAS需要在操作前检查下值有没有发生变化，如果没有则更新。但是如果一个值开始的时候是A，变成了B，又变成了A，那么使用CAS进行检查的时候会发现它的值没有发生变化，但是事实却不是如此。
ABA问题的解决思路是使用版本号，如A-B-A变成1A-2B-3A
2、循环时间长开销大：自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
3、只能保证一个共享变量的原子操作：对一个共享变量可以使用CAS进行原子操作，但是多个共享变量的原子操作就无法使用CAS，这个时候只能使用锁。
synchronized在jdk1.6之后，已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。
如有错误或者补充欢迎留言指正，谢谢
閱讀更多 全棧取經之路 的文章
