java中的volatile和synchronized

关于volatile和同步相关的东西，网上有太多错误和解释不清的东西， 所以查阅相关书籍和文章后总结如下， 如果还是也存在不正确的内容，请一定要指出来， 以免误人子弟:)

1. 原子性与可视性

原子性是指操作不能被线程调度机制中断， 除long和double之外的所有基本类型的读或写操作都是原子操作，注意这里说的读写， 仅指如return i, i = 10, 对于像i++这种操作，包含了读，加1，写指令，所以不是原子操作。 对于long和double的读写，在64位JVM上会把它们当作两个32位来操作，所以不具备原子性。

在定义long和double类型变量时，如果使用volatile来修饰，那么也可以获得原子性，除此以外，volatile与原子性没有直接关系。

可视性，volatile的主要作用就是确保可视性，那么什么是可视性？
    在系统中（多处理器更加明显），对某一变量的修改有时会暂时保存在本地处理器的缓存中，还没有写入共享内存，这时候有另外一个线程读取变量在共享内存的值，那么这个修改对这个线程就是不可视的。
    Volatile修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。而且，当成员变量发生变化时，强迫线程将变化值直接写到共享内存。这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。 原子操作不一定就有可视性， 比如赋值，i = 10,  如果i没有被特别修饰， 那么因为缓存的原因， 它仍然可能是不可视的

所以原子性和可视性是完全不同的两个概念

2. volatile的应用场景
    详细可以参考java语言架构师Brain Geotz的文章
    Java 中volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 优点是所需的编码较少，并且运行时开销也较少， 不会引起线程阻塞。Volatile 变量具有 synchronized 的可视性特性，但是不具备原子特性。
    这就导致Volatile 变量可用于提供线程安全，但是应用场景非常有限，在一些经典java书里，基本都不推荐使用volatile替代synchronized来实现同步，因为风险较大， 很容易出错。
Brain给出的使用volatile实现线程安全的条件：
    对变量的写操作不依赖于当前值。 (count++这种就不行了)
    该变量没有包含在具有其他变量的不变式中（Invariants，例如 “start <=end”）。

我的理解是， 这两个条件都是因为volatile不能提供原子性导致的， 如果多线程执行的一个操作不是原子性的， 使用volatile时就一定要慎重。
    如果满足这两个条件， 多线程执行的操作是原子性的， 那就是可以使用，如：
将 volatile 变量作为状态标志使用

volatile boolean shutdownRequested;
.
...
public void shutdown() { shutdownRequested = true; } //不依赖当前值，原子操作
public void doWork() { 

　　while (!shutdownRequested) {
　　// do stuff
　　}
}

文章中的其他几种模式， 也都差不多这个意思。

还有一种情况，如果读操作远远超过写操作，可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。
    结合使用 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; } //使用volatile替代synchronized

　　public synchronized int increment() {

　　return value++;

}

然而，你可以在读操作中使用 volatile 确保当前值的可见性，因此可以使用锁进行所有变化的操作，使用 volatile 进行只读操作。其中，锁一次只允许一个线程访问值，volatile 允许多个线程执行读操作，因此当使用 volatile 保证读代码路径时，要比使用锁执行全部代码路径获得更高的共享度 —— 就像读－写操作一样。

3. synchronized

class AtomTest implements Runnable {
    private volatile int i = 0;
    public int getVal() {return i;}

    public synchronized void inc() {i++; i++;}

    @Override
    public void run() {
        while (true) {
            inc();
        }
    }
}

public class TestThread {

    public static void main(String[] args) throws InterruptedException {

        ExecutorService exec = Executors.newCachedThreadPool();
        AtomTest at = new AtomTest();
        exec.execute(at);
        while (true) {
            int val = at.getVal();
            if (val % 2 != 0) {
                System.out.println(val);
                System.exit(0);
            }
        }
    }
}

结果会输出奇数， 退出程序， 原因是getVal读到了inc的中间值。 这种情况只能在getVal方法前加synchronized
    在读取的时候也加锁， 这样在读的时候如果正在写， 那么等待， 所以就不会读到inc的中间值。

关于synchronized值得注意的几个点：

1) 所有对象都含有一个锁，当调用到synchronized(object)块时，先检测obj有没有加锁，如果有， 阻塞， 如果没有， 对object加锁， 执行完后释放锁。

2) synchronized void f() {//...}    等价于  void f() { synchronized(this) {//...} },   在当前对象上加锁
    3) synchronized 提供原子性和可视性， 被它完全保护的变量不需要用volatile

4) synchronized关键字是不能继承的，也就是说，基类的方法synchronized f(){} 在继承类中并不自动是synchronized f(){}，而是变成了f(){}。继承类需要你显式的指定它的某个方法为synchronized方法。

注意第一点， 非常重要：虽然sync块可以包裹一段代码，但是锁是加对象上，不是加在代码上，它的工作机制如下：

对于synchronized(obj) {//...}： 先检测obj有没有加锁，如果有， 阻塞， 如果没有， 对obj加锁， 执行块中的代码，完毕后释放锁。这里只检测obj对象上的锁，不关注代码块里的代码或者对象。

所以， 加锁的范围由obj决定，理解了这一点， 下面的很多种情况就会很容易理解：

1. 当两个并发线程访问同一个对象object中的这个相同synchronized(this)同步代码块时，一个时间内针对该对象的操作只能有一个线程得到执行。另一个线程必须等待。

- 如果同一对象已经加锁， 另一线程执行到sync块，检测到有锁挂起。

　　2. 然而，另一个线程仍然可以访问该object中的非synchronized(this)同步代码块。

- 非sync代码，不关注对象是否加锁

　　3. 当一个线程访问object的一个synchronized(this)同步代码块时，其他线程对该object中所有其它synchronized(this)同步代码块的访问将被阻塞。

- synchronized(this) 只是关注this对象， 只要this已加锁，执行到同一对象中不同方法的sync块时，也会阻塞。

　　4. 不同的对象实例的synchronized(this)方法是不相干扰的。也就是说，其它线程照样可以同时访问相同类的另一个对象实例中的synchronized方法。

- 可以同时访问不同对象中的sync块， 原因很简单， 因为synchronized(this)，关注的是this对象，不同对象的this是不一样的。

5.  同理，也可以对其他对象加锁，

1） 对于类中的成员对象： private Integer i = new Integer(0);   synchronized(i) {//...}    i创建在堆上，每个对象有一个i，所以效果与synchronized(this)一样。

2） 对于静态成员对象： private static Integer i = new Integer(0);  synchronized(i) {//...}: i创建在静态区，属于类， 所以效果与synchronized(ClassName.class)一样。

　　6.对类对象加锁时，对该类的所有对象都起作用：synchronized(ClassName.class) {//...}

最后我在测试代码时，发现对于private Integer i = 0;   synchronized(i) {//...}

锁的效果是全局的，推测可能是Integer对0进程打包时，自动生成的这个对象可能在常量区。 后来查了下资料才发现并非如此：

Integer实现中有一个IntegerCache类，它包含一个静态的Integer数组，在类加载时就将-128 到 127 的Integer对象创建了，并保存在cache数组中，一旦程序调用valueOf 方法，如果i的值是在-128 到 127 之间就直接在cache缓存数组中去取Integer对象。 所以这里的i引用的是整个全局数组里值， 所以锁也是全局的了。。。

如果改成private Integer i = 300，  然后加锁就只在本对象有效了。 原因是i不在缓存范围，所以创建在了堆上。

refer  http://blog.csdn.net/xiaohai0504/article/details/6885137