不同的平台，内存模型是不一样的，但是jvm的内存模型规范是统一的。其实java的多线程并发问题最终都会反映在java的内存模型上，所谓线程安全无非是要控制多个线程对某个资源的有序访问或修改。总结java的内存模型，要解决两个主要的问题：可见性和有序性。

我们都知道计算机有高速缓存的存在，处理器并不是每次处理数据都是取内存的。JVM定义了自己的内存模型，屏蔽了底层平台内存管理细节，对于java开发人员，要清楚在jvm内存模型的基础上，如果解决多线程的可见性和有序性。

多个线程之间是不能互相传递数据通信的，它们之间的沟通只能通过共享变量来进行。Java内存模型（JMM）规定了jvm有主内存，主内存是多个线程共享的。当new一个对象的时候，也是被分配在主内存中，每个线程都有自己的工作内存，工作内存存储了主存的某些对象的副本，当然线程的工作内存大小是有限制的。当线程操作某个对象时，执行顺序如下：
(1) 从主存复制变量到当前工作内存 (read and load)
(2) 执行代码，改变共享变量值 (use and assign)
(3) 用工作内存数据刷新主存相关内容 (store and write)

JVM规范定义了线程对主存的操作指令：read，load，use，assign，store，write。当一个共享变量在多个线程的工作内存中都有副本时，如果一个线程修改了这个共享变量，那么其他线程应该能够看到这个被修改后的值，这就是多线程的可见性问题。

线程不能直接为主存中中字段赋值，它会将值指定给工作内存中的变量副本(assign),完成后这个变量副本会同步到主存储区(store- write)，至于何时同步过去，根据JVM实现系统决定.有该字段,则会从主内存中将该字段赋值到工作内存中,这个过程为read-load,完成后线程会引用该变量副本

Java作为平台无关性语言，JLS(Java语言规范)定义了一个统一的内存管理模型JMM(Java Memory Model)，JMM屏蔽了底层平台内存管理细节，在多线程环境中必须解决可见性和有序性的问题。JMM规定了jvm有主内存(Main Memory)和工作内存(Working Memory) ，主内存存放程序中所有的类实例、静态数据等变量，是多个线程共享的，而工作内存存放的是该线程从主内存中拷贝过来的变量以及访问方法所取得的局部变量，是每个线程私有的其他线程不能访问，每个线程对变量的操作都是以先从主内存将其拷贝到工作内存再对其进行操作的方式进行，多个线程之间不能直接互相传递数据通信，只能通过共享变量来进行。

线程要引用某变量，如果线程工作内存中没有该个变量，通过read-load从主内存中拷贝一个副本到工作内存中，完成后线程会引用该副本，当同一个线程再次引用该变量时，有可能重新从主存中获取变量副本(read-load-use)，也有可能直接引用原来的副本(use)，也就是说read、load、use顺序可以由jvm实现系统决定。

线程要写入某变量，它会将值指定给工作内存中的变量副本(assign)，完成后这个变量副本会同步到主存(store-write)，至于何时同步过去，即assign,store,write顺序由jvm实现系统决定。

多线程对主存的有序性操作有可能会导致并发问题，看一个例子：

public class Test{
    public int i = 0;
    public void add(){
        i++;
    }
} 

前提：线程a、b使用类Test的同一个实例,执行顺序1-6

线程a从主存读取i副本x到工作内存，工作内存中x值为0
线程b从主存读取i副本y到工作内存，工作内存中y值为0
线程a将工作内存中x加1，工作内存中x值变为1
线程a将x提交到主存，主存中i变为1
线程b将工作内存中y加1，工作内存中y值变为1
线程b将y提交到主存中，主存中i变为1
*单线程环境下，i进行两次加1，结果必定是2，但多线程环境下，i进行两次加1，结果不一定是2，这取决于上例中第2和第4步的执行顺序！

volatile是java提供的一种同步手段，只不过它是轻量级的同步，为什么这么说，因为volatile只能保证多线程的内存可见性，不能保证多线程的执行有序性。而最彻底的同步要保证有序性和可见性。当同一线程多次重复对字段赋值时，线程有可能只对工作内存中的副本进行赋值，直到最后一次赋值后才同步到主存储区。任何被volatile修饰的变量，都不拷贝副本到工作内存，任何修改都及时写在主存。因此对于valatile修饰的变量的修改，所有线程马上就能看到，但是volatile不能保证对变量的修改是有序的。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件:

1、对变量的写操作不依赖于当前值。

2、该变量没有包含在具有其他变量的不变式中。

错误的例子:

public class VolatileFalse{   
    public volatile int i;
    public void add(){
        i++;
    }
}

说明：虽然volatile 保证对i的修改“及时”写在主存，所有线程马上能看到，但i = i + 1 对变量i的写操作依赖于当前值，而当前值是可变的，由于多线程下读写i的值是无序的，所以多个线程运行VolatileFalse的同一个实例后的到i的最终值不一定是正确。

正确的例子:

public class VolatileTrue{
    public volatile int i;
    public void setI(int j){
        this.i = j;
    }
} 

说明：没有volatie声明，在多线程环境下，i的值不一定是正确的，因为this.i = j;涉及给i赋值和将i的值同步主存的步骤，这个顺序可能被打乱。如果用volatie声明了，读取主存副本到工作内存和同步i到主存的步骤，相当于是一个原子操作，因此是线程安全的。

volatile适合这种场景：一个变量被多个线程共享，线程直接给这个变量赋值。这是一种很简单的同步场景，这时候使用volatile的开销将会非常小。

synchronized关键字作为多线程并发环境的执行有序性的保证手段之一，如果某个线程访问一个标识为synchronized的方法，并对相应变量做操作，那么根据JLS，JVM的执行步骤如下：

取得该对象锁(普通方法的锁为this对象，静态方法则为该类的class对象)并将其锁住(lock)。
将需要的数据从主内存拷贝到自己的工作内存(read and load)。
根据程序流程读取或者修改相应变量值(use and assign)。
将自己工作内存中修改了值的变量拷贝回主内存(store and write)。
释放对象锁(unlock)。
对synchronized的一些总结：

public class Test{
    public void method0(){...} 
    public synchronized void method1(){...} 
    public void method2() { 
        synchronized (this){...}
    }
    public void method3(SomeObject so) { 
 　　   synchronized(so) {...}
    } 
    public void method4() { 
 　　   ...
 　　   private byte[] lock = new byte[0]; 
 　　   synchronized (lock){...} 
 　　   ...
    }
    public synchronized static void method5(){...}
    public void method6(){
        synchronized(Test.class){...}
    } 
}

1) method1同步函数和method2中同步块synchronized (this){…}所取得的同步锁都是类Test的实例对象，即对象锁，所以method1和method2效果等同。

2) 当多个并发线程访问”同一个”对象中的同步函数或同步块时，取得对象锁的线程得到执行，该线程执行期间，其他要访问该对象同步函数或同步块(不管是不是相同的同步函数或同步块)的线程将会阻塞，直到获取该对象锁后才能执行，当然要访问该对象的非同步方法或同步块的线程不受对象锁的限制，可以直接访问。

3) method2同步块synchronized (this){…}中this是指调用这个方法的对象，如果两个线程中分别调用的是t1和t2(类Test的实例化)两个对象，则这个同步块对于这两个线程来说无效，这时可以使用method3中同步块synchronized(so) {…}方式，将锁挂在其他对象上面。

4) 如果要对函数中的部分代码进行同步处理，怎么办？method4中通过一个特别的实例变量充当锁来实现。

5) method5静态同步函数和method6中同步块synchronized(Test.class){…}所取得的同步锁是类锁，即类Test的锁，而非类Test的对象锁。

6) 因为类锁跟对象锁是不同的锁，所以在多线程并发环境下method1和method5不构成同步。