在并发编程中,需要解决两个问题:线程间如何通信&线程间如何同步
线程同步:控制不同线程操作顺序的机制
解决这两个问题的方案有两种:共享内存&消息传递
共享内存:通过使用共享内存,隐式通信和同步;这里程序员必须显式的指定某个方法或代码块要在线程间互斥执行
消息传递:通过发消息来通信和同步;由于接收消息必须在发送消息之后,因此算是隐式的设置了同步
而JAVA采用的是共享内存模型。
JMM(Java内存模型)如下
如上图所示,JMM定义了线程和主内存之间的关系:线程之间的共享内存都存储在共享内存中,每个线程有自己的本地内存,本地内存存储了该线程以读/写共享变量的副本。
JMM是通过控制主内存与每个线程的本地内存之间的交互,来为java程序员提供内存可见性保证(例如有共享变量x=1,线程A和线程B都要修改这个共享变量,那么线程A将x设置为2,同时将x回写到共享内存,那么线程2拿到的就是x=2)
一、概念
说到JMM,就不得不提重排序、happends-before、as-if-serial
1、重排序
处理器对代码的执行顺序并非按照程序编写的源代码顺序执行,而是编译器和处理器会对源代码做重排序,处理器按照重排序后的结果执行,从而提高性能。
重排序分为三类:
编译器优化的重排序:编译器在不改变单线程程序语义的情况下重排序
指令并行重排序:如果不存在数据依赖,处理器可以重排序
内存系统重排序:处理器使用缓存和读写缓存区,这使得加载和存储操作看起来乱序。
从JAVA源代码到最终执行的指令序列所经历的重排序如下:
其中1是属于编译器的重排序,2和3属于处理器的重排序。
上述重排序中,对于内存系统的重排序,由于读写缓存只对当前线程可见,因此会造成多线程运行时的结果异常,因此处理器一般都只会允许对读写进行重排序。
2、happends-before
如果A happends-before于B,那么A的执行一定在B之前
3、as-if-serial
不管怎么重排序,单线程的执行结果不能被改变。所有的重排序都要遵循这个原则。
二、内存语义
但是如果要是多线程运行,那么由于指令重排和线程的读写缓存问题,会造成执行结果异常,因此就需要使用volatile、锁、final来处理
1、volatile的内存语义
可见性:对一个volatile修饰的变量的读,总能看到任意线程对这个volatile修饰的变量最后的写入
原子性:对于任意由volatile修饰的变量的读和写操作都是原子操作;但是对于volatile++这样的操作是非原子性的。
当写一个volatile修饰的变量时,JMM会把该线程对应的本地内存中的共享变量值刷新到内存中(只要有一个共享变量是volatile修饰,所有的共享变量都会被刷新到主内存中)
当读一个volatile修饰的变量时,JMM会把该线程对应的内存置为无效,线程将从主内存读取共享变量。
2、锁的内存语义
当锁释放时,JMM会把该线程对应的共享内存刷新到主内存中
当获取锁时,JMM会把该线程对应的本地内存置为无效
由以上两点可见,释放锁的内存语义和volatile的写拥有相同的内存语义,获取锁的内存语义和volatile的读有相同的内存语义。
3、final的内存语义
写final重排序:禁止把final域的写重排序到构造函数之外。这样可以确保在每次引用为任意线程可见之前,对象的final域已经正确初始化。
读final重排序:在一个线程中,初次读对象的引用和读该对象中的fianl域之间禁止重排序。
为什么要将fianl的写限制在构造方法之内:比如一个线程看到一个整形的final域为0(还未初始化,默认值),过一段时间去读取时,发现已经变为1(被初始化完成后的值),因此会造成获取final修饰的值不一致的问题,为了修复该问题,限制了final修饰的写必须在构造方法之内。
三、happends-before
happends-before是JMM最核心的概念,JMM为了平衡程序员(要求强内存模型,保证内存可见性)和处理器(要求若内存模型,处理器可以自行优化)的需求,设计了happends-before。
1、happends-before定义:
a、如果一个操作happends-before另一个操作,那么第一个操作的结果将对第二个操作结果可见,且第一个操作必须在第二个操作之前。
b、两个操作之间存在happend-before关系,并不意味着java平台具体的实现必须按照happends-before的顺序来执行。如果重排序的结果与happends-before的执行结果一致,那么重排序并不非法。
上述a是对程序员做出的承诺:如果A happends-before B,那么A的操作必须对B可见,且A的操作在B之前。
b是对处理器的约束原则:只要不改变程序运行结果,编译器和处理器可以自行优化(这里的程序指的是单线程程序或正确同步的多线程程序)
2、happends-before规则
a、程序顺序规则:一个线程中的每个操作,happends-before于该线程任意的后续操作
b、监视器锁规则:对于一个锁的解锁操作,happends-before于后续对该锁的加锁操作
c、volatile规则:对于一个volatile修饰的写,hanppends-before于对这个volatile修饰的读
d、传递性:如果A happends-before B,B happends-before C,那么A hanppends-before C
e、start()规则:如果线程A中调用了线程B的start方法,那么线程A中调用B线程的start方法的操作happends-before于线程B的任何操作
f、join()规则:如果线程A调用线程B的join方法,那么线程B中的任意操作happend-before于线程A从B.join()操作返回成功
四、双重检查锁定与延迟初始化
对于很多场景,都会延迟加载类,来降低初始化类和创建对象的开销,待使用时在延迟加载。
其实这里就是我们常说的单例模式。
public class InitDemo { private static InitDemo instance; public static InitDemo getInstance(){ if(instance == null){ instance = new InitDemo(); } return instance; } public static InitDemo getInstance1(){ synchronized (InitDemo.class){ if(instance == null){ instance = new InitDemo(); } } return instance; } public static InitDemo getInstance2(){ if(instance == null){ synchronized (InitDemo.class){ if(instance == null){ instance = new InitDemo();//有问题 } } } return instance; } }
以上写法都是有问题的:
getInstance方法的问题:非线程安全,可能会创建多个实例(俗称:懒汉式)
getInstance1方法的问题:每次使用都加锁,性能消耗大
getInstance2方法的问题:同样是非线程安全的
解决方案:
解决方案一:使用volatile
public class InitDemo { private volatile static InitDemo instance; public static InitDemo getInstance(){ if(instance == null){ synchronized (InitDemo.class){ if(instance == null){ instance = new InitDemo();//有问题 } } } return instance; } }
由于使用了volatile,因此多线程(都是第一次访问)创建对象时,就可以保证线程安全。
解决方案二:基于类初始化方式
public class InitDemo { private static class InitDemoFactory{ public static InitDemo instance = new InitDemo(); } public static InitDemo getInstance(){ return InitDemoFactory.instance; } }
优缺点对比:
基于类加载模式的方案,代码更简洁;但是只能对静态字段实现延迟加载
使用volatile,除了可以对静态字段做延迟加载外,还可以对实例字段实现延迟加载。