内存的原子性、可见性 & 有序性；
 volatile保证可见性 & 有序性，不保证原子性。

— 工作内存与主内存怎么进行交互？虚拟机定义了8种原子操作：
1.lock（锁定主内存的变量，使其被某一线程独占），
2.unlock（同理），
3.read（把一个主内存的变量传递到工作内存中，以便load），
4.load（将从主内存传递的值传递到工作内存的变量副本中），
5.store（将工作内存中变量副本传递到主内存中去，以便write），
6.write（将工作内存传递过来的值赋到主内存中变量），
7.use（将工作内存的值传递给执行引擎），
8.assign（将执行引擎的值传递到工作内存），这8中操作可以用来确定你的访问是否安全。

> 对象锁和类锁

– java的对象锁和类锁：java的对象锁和类锁在锁的概念上基本上和内置锁是一致的，但是，两个锁实际是有很大的区别的，对象锁是用于对象实例方法，或者一个对象实例上的，类锁是用于类的静态方法或者一个类的class对象上的。我们知道，类的对象实例可以有很多个，但是每个类只有一个class对象，所以不同对象实例的对象锁是互不干扰的，但是每个类只有一个类锁。但是有一点必须注意的是，其实类锁只是一个概念上的东西，并不是真实存在的，它只是用来帮助我们理解锁定实例方法和静态方法的区别的

– synchronized 
 在修饰代码块的时候需要一个reference对象作为锁的对象. 
 在修饰方法的时候默认是当前对象作为锁的对象. 
 在修饰类时候默认是当前类的Class对象作为锁的对象.

> syncrhoized ,reentrantLock,Atomic ,Lock,ThreadLocal,transient,volatile各自特点和比对:
 1. synchronized： 
 在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的。原因在于，编译程序通常会尽可能的进行优化synchronize，另外可读性非常好，不管用没用过5.0多线程包的程序员都能理解。
 synchronized在锁定时如果方法块抛出异常，JVM 会自动将锁释放掉，不会因为出了异常没有释放锁造成线程死锁。但是 Lock 的话就享受不到 JVM 带来自动的功能，出现异常时必须在 finally 将锁释放掉，否则将会引起死锁。
 synchronized和Lock保证了对象、变量的原子性和可见性,volatile保证变量的可见性。原子性的指令 CAS （compare and swap）。

深入理解Java并发之synchronized实现原理- http://blog.csdn.net/javazejian/article/details/72828483

 — synchronized实现同步的基础：
①:对于普通方法，锁是当前实例对象。
②：对于静态同步方法，锁是class对象。
③：同步方法块，锁是synchronized后面括号里的对象。

 synchronized在静态方法上表示调用前要获得类的锁，而在非静态方法上表示调用此方法前要获得对象的锁。
public class StaticSynDemo {
 private static String a=”test”;
 public void print2(String b){
   synchronized (this) {//取得StaticSynDemo实例化后对象的锁
    System.out.println(b+a);
   }
 }
  
 public static void print4(String b){
   synchronized (StaticSynDemo.class) { //取得StaticSynDemo.class类的锁
    System.out.println(b+a);
   }
 }

}

 2. ReentrantLock: 
 ReentrantLock提供了多样化的同步，比如有时间限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等。在资源竞争不激烈的情形下，性能稍微比synchronized差点点。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。 

 3. Atomic: 
 和上面的类似，不激烈情况下，性能比synchronized略逊，而激烈的时候，也能维持常态。激烈的时候，Atomic的性能会优于ReentrantLock一倍左右。但是其有一个缺点，就是只能同步一个值，一段代码中只能出现一个Atomic的变量，多于一个同步无效。因为他不能在多个Atomic之间同步。

 4. Lock 
 Lock的锁定是通过代码实现的，而 synchronized 是在 JVM 层面上实现的 。
 所以，我们写同步的时候，优先考虑synchronized，如果有特殊需要，再进一步优化。ReentrantLock和Atomic如果用的不好，不仅不能提高性能，还可能带来灾难。

 5. ThreadLocal? 
 ThreadLocal以空间换取时间，提供了一种非常简便的多线程实现方式。因为多个线程并发访问无需进行等待，所以使用ThreadLocal会获得更大的性能。虽然使用ThreadLocal会带来更多的内存开销，但这点开销是微不足道的。因为保存在ThreadLocal中的对象，通常都是比较小的对象。另外使用ThreadLocal不能使用原子类型，只能使用Object类型。ThreadLocal的使用比synchronized要简单得多。 

 — 常见的对于 ThreadLocal的介绍:
1.ThreadLocal为解决多线程程序的并发问题提供了一种新的思路;
2.ThreadLocal的目的是为了解决多线程访问资源时的共享问题;
3.ThreadLocal 适用于每个线程需要自己独立的实例且该实例需要在多个方法中被使用，也即变量在线程间隔离而在方法或类间共享的场景。

 — ThreadLocal 适用于如下两种场景：
1.每个线程需要有自己单独的实例
2.实例需要在多个方法中共享，但不希望被多线程共享

  ThreadLocal 并不解决线程间共享数据的问题;ThreadLocal 通过隐式的在不同线程内创建独立实例副本避免了实例线程安全的问题。
  每个线程持有一个 Map 并维护了 ThreadLocal 对象与具体实例的映射，该 Map 由于只被持有它的线程访问，故不存在线程安全以及锁的问题：
 1.ThreadLocalMap 的 Entry 对 ThreadLocal 的引用为弱引用，避免了 ThreadLocal 对象无法被回收的问题
 2.ThreadLocalMap 的 set 方法通过调用 replaceStaleEntry 方法回收键为 null 的 Entry 对象的值（即为具体实例）以及 Entry 对象本身从而防止内存泄漏
 3.ThreadLocal 适用于变量在线程间隔离且在方法间共享的场景

——-
 使用ThreadLocal的典型场景正如上面的数据库连接管理，线程会话管理等场景，只适用于独立变量副本的情况，如果
变量为全局共享的，则不适用在高并发下使用。
 每个ThreadLocal只能保存一个变量副本，如果想要上线一个线程能够保存多个副本以上，就需要创建多个ThreadLocal
。ThreadLocal内部的ThreadLocalMap键为弱引用，会有内存泄漏的风险。
  适用于无状态，副本变量独立后不影响业务逻辑的高并发场景。如果如果业务逻辑强依赖于副本变量，则不适合用
ThreadLocal解决，需要另寻解决方案。
 ThreadLocal是一个本地线程副本变量工具类。主要用于将私有线程和该线程存放的副本对象做一个映射，各个线程之
间的变量互不干扰，在高并发场景下，可以实现无状态的调用，特别适用于各个线程依赖不同的变量值完成操作的场景
。
 — ThreadLocal用法详解和原理:
1、ThreadLocal.get: 获取ThreadLocal中当前线程共享变量的值。
2、ThreadLocal.set: 设置ThreadLocal中当前线程共享变量的值。
3、ThreadLocal.remove: 移除ThreadLocal中当前线程共享变量的值。
4、ThreadLocal.initialValue: ThreadLocal没有被当前线程赋值时或当前线程刚调用remove方法后调用get方法，返回
此方法值。

 6. transient
 Java语言的关键字，变量修饰符，如果用transient声明一个实例变量，当对象存储时，它的值不需要维持。这里的对象存储是指，Java的serialization提供的一种持久化对象实例的机制。当一个对象被序列化的时候，transient型变量的值不包括在序列化的表示中，然而非transient型的变量是被包括进去的。使用情况是：当持久化对象时，可能有一个特殊的对象数据成员，我们不想用serialization机制来保存它。为了在一个特定对象的一个域上关闭serialization，可以在这个域前加上关键字transient。

 7. volatile
 volatile是轻量级的synchronized，它只是用来保证共享变量的可见性，不能保证操纵的原子性。volatile如何实现内存可见性？深入的说，通过加入内存屏障和禁止重排序优化实现的。
 对volatile变量执行写操作时，会在写操作后加入一条store屏障指令。
 对volatile变量执行读操作时，会在读操作前加入一条load屏障指令。
volatile保证共享变量可见性,有volatile修饰的变量进行写操作的时候会多出一行汇编代码，该行代码会有一个lock指令。

  volatile的两条实现原则：
①： Lock前缀指令会引起处理器缓存会写到内存（使处理器独占任何共享内存）。
②：一个处理器的缓存回写会导致其他处理器的缓存无效。

  Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start <=end”）
  出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile 变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile 变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。

  要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：
1.对变量的写操作不依赖于当前值。
2.该变量没有包含在具有其他变量的不变式中。

volatile关键字使用规则 http://blog.csdn.net/endlu/article/details/51180065
  volatile关键字是与Java的内存模型有关的.volatile,可变的，易变的。在DSP中，一些寄存器的值的变化有两种情况：（1）硬件上导致的变化，例如中断、ADC等；（2）软件上的变化，例如对某个变量赋值等。
  当加入了关键字volatile，则表示该变量的值可因上述两种情况而发生变化；即，对软件来说，硬件上变化的值是不可预知的，加入了该关键字，提示编译器每次读取该变量时，都要直接读取该变量地址中的寄存器，保证了数据的正确性。
  缓存一致性协议出名的就是Intel 的MESI协议.并发编程中，我们通常会遇到以下三个问题：原子性问题，可见性问题，有序性问题.

— 结合使用 volatile 和 synchronized 实现 “开销较低的读－写锁”
@ThreadSafe
public class CheesyCounter {
    // Employs the cheap read-write lock trick
    // All mutative operations MUST be done with the ‘this’ lock held
    @GuardedBy(“this”) 
    private volatile int value;
    public int getValue() { 
    return value;
    }
    public synchronized int increment() {
        return value++;
    }
}
  之所以将这种技术称之为 “开销较低的读－写锁” 是因为您使用了不同的同步机制进行读写操作。因为本例中的写操作违反了使用 volatile 的第一个条件，因此不能使用 volatile 安全地实现计数器 —— 您必须使用锁。然而，您可以在读操作中使用 volatile 确保当前值的可见性，因此可以使用锁进行所有变化的操作，使用 volatile 进行只读操作。其中，锁一次只允许一个线程访问值，volatile 允许多个线程执行读操作，因此当使用 volatile 保证读代码路径时，要比使用锁执行全部代码路径获得更高的共享度 —— 就像读－写操作一样。然而，要随时牢记这种模式的弱点：如果超越了该模式的最基本应用，结合这两个竞争的同步机制将变得非常困难。

  volatile:Java 语言提供了一种稍弱的同步机制,即 volatile 变量.用来确保将变量的更新操作通知到其他线程,保证了新值能立即同步到主内存,以及每次使用前立即从主内存刷新. 当把变量声明为volatile类型后,编译器与运行时都会注意到这个变量是共享的.
  volatile修饰的变量可以实现基本的加载和赋值的原子性.在JDK1.5之前我们只能通过 synchronized(阻塞的方式)实现这些复合操作的原子性,在JDK1.5中java.util.concurrent.atomic 包提供了若干个类能实现对int,long,boolean,reference的几个特殊方法非阻塞原子性。

> 对象锁和类锁 
  加锁非静态方法，即是对象锁。synchronized修饰非静态方法、同步代码块的synchronized (this)用法和synchronized (非this对象)的用法锁的是对象，线程想要执行对应同步代码，需要获得对象锁。
 synchronized 加到 static 方法前面是给class 加锁，即类锁；而synchronized 加到非静态方法前面是给对象上锁。

线程同步的方法：sychronized、lock、reentrantLock分析 

 对象锁是用来控制实例方法之间的同步，类锁是用来控制静态方法（或静态变量互斥体）之间的同步。　
 synchronized修饰非静态方法、同步代码块的synchronized (this)用法和synchronized (非this对象)的用法锁的是对象，线程想要执行对应同步代码，需要获得对象锁。
 

synchronized修饰静态方法以及同步代码块的synchronized (类.class)用法锁的是类，线程想要执行对应同步代码，需要获得类锁。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。

— Synchronized、Lock、ReentrantLock的区别:
 Synchronzied实现同步的表现形式分为：代码块同步和方法同步。
 Lock，锁对象。在Java中锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源.
  ReentrantLock lock = new ReentrantLock(); //参数默认false，不公平锁    
lock.lock(); //如果被其它资源锁定，会在此等待锁释放，达到暂停的效果   
try {    
    //操作    
} finally {    
    lock.unlock();  //释放锁  
}
 Java里面内置锁(synchronized)和Lock(ReentrantLock)都是可重入的。在Java中，synchronized就不是可中断锁，而Lock是可中断锁。

— synchronized和ReentrantLock的比较 区别：
1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
 3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
 4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。
 5）Lock可以提高多个线程进行读操作的效率。
 总结：ReentrantLock相比synchronized，增加了一些高级的功能。但也有一定缺陷。

  在JDK1.5中，synchronized是性能低效的。因为这是一个重量级操作，它对性能最大的影响是阻塞的是实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力。相比之下使用Java提供的ReentrankLock对象，性能更高一些。到了JDK1.6，发生了变化，对synchronize加入了很多优化措施，有自适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在JDK1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地，所以还是提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步。
  根类 Object 包含某些特殊的方法，用来在线程的 wait() 、 notify() 和 notifyAll() 之间进行通信。

 ReentrantLock（CAS,AQS,java内存可见性（voliate））是可重入的独占锁或者叫排他锁。同时只能有一个线程获取该锁，其实现分为公平实现和非公平实现。
 由于Volatile不能保证操作的原子性，因此，一般情况下，Volatile不能代替Synchronized。此外，使用Volatile会阻止编译器对代码的优化，因此会降低程序的执行效率。除非迫不得已，一般能不用就不要用。
 

> Synchronized与ThreadLocal区别：
  Synchronized用于线程间的数据共享，而ThreadLocal则用于线程间的数据隔离。
  ThreadLocal和Synchonized都用于解决多线程并发访问。但是ThreadLocal与synchronized有本质的区别。synchronized是利用锁的机制，使变量或代码块在某一时该只能被一个线程访问。而ThreadLocal为每一个线程都提供了变量的副本，使得每个线程在某一时间访问到的并不是同一个对象，这样就隔离了多个线程对数据的数据共享。而Synchronized却正好相反，它用于在多个线程间通信时能够获得数据共享。 
  当然ThreadLocal并不能替代synchronized,它们处理不同的问题域。Synchronized用于实现同步机制，比ThreadLocal更加复杂。 

 ThreadLocal是一个线程隔离(或者说是线程安全)的变量存储的管理实体（注意：不是存储用的），它以Java类方式表现；
 synchronized是Java的一个保留字，只是一个代码标识符，它依靠JVM的锁机制来实现临界区的函数、变量在CPU运行访问中的原子性。
 Java提供了同步机制来解决并发问题。synchonzied关键字可以用来同步变量，方法，甚至同步一个代码块。

  ThreadLocal与Synchronize，一个是锁机制进行时间换空间，一个是存储拷贝进行空间换时间。
  ThreadLocal是解决线程安全问题一个很好的思路，它通过为每个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。

> Synchronized与Lock
 主要相同点：Lock能完成Synchronized所实现的所有功能。
 主要不同点：Lock有比Synchronized更精确的线程予以和更好的性能。Synchronized会自动释放锁，但是Lock一定要求程序员手工释放，并且必须在finally从句中释放。
   synchronized 修饰方法时 表示同一个对象在不同的线程中 表现为同步队列.如果实例化不同的对象 那么synchronized就不会出现同步效果了。
   1.对象的锁 
所有对象都自动含有单一的锁。 
   JVM负责跟踪对象被加锁的次数。如果一个对象被解锁，其计数变为0。在任务（线程）第一次给对象加锁的时候，计数变为1。每当这个相同的任务（线程）在此对象上获得锁时，计数会递增。 
   只有首先获得锁的任务（线程）才能继续获取该对象上的多个锁。 
每当任务离开一个synchronized方法，计数递减，当计数为0的时候，锁被完全释放，此时别的任务就可以使用此资源。 
    2.synchronized同步块 
2.1同步到单一对象锁 
当使用同步块时，如果方法下的同步块都同步到一个对象上的锁，则所有的任务（线程）只能互斥的进入这些同步块。

> Lock的使用参见下面的代码（把Lock换成synchronized的效果是一样的）
import java.util.concurrent.TimeUnit;  
import java.util.concurrent.locks.Lock;  
import java.util.concurrent.locks.ReentrantLock;  
  
public class Resource3 {  
    private Lock lock = new ReentrantLock();  
    public void f() {  
      // other operations should not be locked…  
  
        System.out.println(Thread.currentThread().getName()  
                + “:not synchronized in f()”);  
        lock.lock();  
        try {  
            for (int i = 0; i < 5; i++) {  
                System.out.println(Thread.currentThread().getName()  
                        + “:synchronized in f()”);  
                try {  
                    TimeUnit.SECONDS.sleep(3);  
                } catch (InterruptedException e) {  
                    e.printStackTrace();  
                }  
            }  
        } finally {  
            lock.unlock();  
        }  
    }  
  
    public void g() {  
        // other operations should not be locked…  
        System.out.println(Thread.currentThread().getName()  
                + “:not synchronized in g()”);  
        lock.lock();  
        try {  
            for (int i = 0; i < 5; i++) {  
                System.out.println(Thread.currentThread().getName()  
                        + “:synchronized in g()”);  
                try {  
                    TimeUnit.SECONDS.sleep(3);  
                } catch (InterruptedException e) {  
                    e.printStackTrace();  
                }  
            }  
        } finally {  
            lock.unlock();  
        }  
    }  
  
    public void h() {  
        // other operations should not be locked…  
        System.out.println(Thread.currentThread().getName()  
                + “:not synchronized in h()”);  
        lock.lock();  
        try {  
            for (int i = 0; i < 5; i++) {  
                System.out.println(Thread.currentThread().getName()  
                        + “:synchronized in h()”);  
                try {  
                    TimeUnit.SECONDS.sleep(3);  
                } catch (InterruptedException e) {  
                    e.printStackTrace();  
                }  
            }  
        } finally {  
            lock.unlock();  
        }  
    }  
  
    public static void main(String[] args) {  
        final Resource3 rs = new Resource3();  
        new Thread() {  
            public void run() {  
                rs.f();  
            }  
        }.start(); 
 
        new Thread() {  
            public void run() {  
                rs.g();  
            }  
        }.start(); 
 
        rs.h();  
    }  
}