- 一、对象的发布与逸出
- 二、并发编程的三个重要特性
- 三、解决多线程遇到的问题
- 三、**synchronized**关键字
- 四、Volatile关键字
- 五、Synchronized与Volatile区别
一、对象的发布与逸出
发布(publish): 使对象能够在当前作⽤域之外的代码中使⽤
1.在静态域中直接初始化 : public static Person = new Person() ;
静态初始化由JVM在类的初始化阶段就执⾏了,JVM内部存在着同步机制,致使这种⽅式我们可以安全发布对象,对应的引⽤保存到volatile或者AtomicReferance引⽤中,保证了该对象的引⽤的可⻅性和原⼦性
2.由final修饰:该对象是不可变的,那么线程就⼀定是安全的,所以是安全发布~
3.由锁来保护:发布和使⽤的时候都需要加锁,这样才保证能够该对象不会逸出
逸出(escape) :当某个不应该发布的对象被发布了
1.静态域逸出
2.public修饰的get⽅法
3.⽅法参数传递
4.隐式的this
二、并发编程的三个重要特性
1.原子性 :
一个的操作或者多次操作,要么所有的操作全部都得到执行并且不会收到任何因素的干扰而中断,要么所有的操作都执行,要么都不执行。synchronized
可以保证代码片段的原子性。
2.可见性 :
当一个线程对共享变量进行了修改,那么另外的线程都是立即可以看到修改后的最新值。volatile
关键字可以保证共享变量的可见性。
3.有序性 :
由于Java 在编译器以及运行期间的优化,代码在执行过程中的先后顺序以及CPU指令的执行顺序不一定按照原来的顺序。volatile
关键字可以禁止指令进行重排序优化。
三、解决多线程遇到的问题
1、线程封闭
在多线程的环境下,只要我们不使用成员变量(不共享数据),那么就不会出现线程安全的问题了。
在方法上操作,只要我们保证不要在栈(方法)上发布对象(每个变量的作用域仅仅停留在当前的方法上),那么我们的线程就是安全的。
比较熟悉的例子是servlet,它的所有的数据都是在方法(栈封闭)上操作的,每个线程都拥有自己的变量,互不干扰。
2、不变性
不可变对象一定线程安全的。
上面我们共享的变量都是可变的,正由于是可变的才会出现线程安全问题。如果该状态是不可变的,那么随便多个线程访问都是没有问题的
Java提供了final修饰符给我们使⽤:final仅仅是不能修改该变的引⽤,但是引⽤⾥边的数据是可以改的
就好像下⾯这个HashMap,⽤final修饰了。但是它仅仅保证了该对象引⽤ hashMap变量 所指向是不可变的,但是hashMap内部的数据是可变的,也就是说:可以add,remove等等操作到集合中
因此,仅仅只能够说明该对象是⼀个不可变的对象引⽤,不可变的对象引⽤在使⽤的时候还是需要加锁的
final String a = "jflin";
a = "a";
//普通类型,直接改变对象的引用,报错(Cannot assign a value to final variable 'a')
final Map b = new HashMap<>();
b.put("a","a");
System.out.println(b);
//集合类型,不改变对象的引用,但是改变了内部数据,不报错
要想将对象设计成不可变对象,那么要满⾜下⾯三个条件:
-
对象创建后状态就不能修改
-
对象所有的域都是final修饰的
-
对象是正确创建的(没有this引⽤逸出)
*特例:String在我们学习的过程中我们就知道它是⼀个不可变对象,但是它没有遵循第⼆点(对象所有的域都是final修饰的),不过JVM在内部做了优化。
3、线程安全性委托
三、synchronized关键字
1.1.说一说自己对于 synchronized 关键字的了解
synchronized
关键字解决的是多个线程之间访问资源的同步性,synchronized
关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。
另外,在 Java 早期版本中,synchronized
属于 重量级锁,效率低下。
为什么呢?
因为监视器锁(monitor)是依赖于底层的操作系统的 Mutex Lock
来实现的,Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程,都需要操作系统帮忙完成,而操作系统实现线程之间的切换时需要从用户态转换到内核态,这个状态之间的转换需要相对比较长的时间,时间成本相对较高。
庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对 synchronized
较大优化,所以现在的 synchronized
锁效率也优化得很不错了。JDK1.6 对锁的实现引入了大量的优化,如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
所以,你会发现目前的话,不论是各种开源框架还是 JDK 源码都大量使用了 synchronized
关键字。
特点:
-
首先需要明确的一点是:Java多线程的锁都是基于对象的,Java中的每一个对象都可以作为一个锁。我们常听到的类锁其实也是对象锁。
-
Java类只有一个Class对象(可以有多个实例对象,多个实例共享这个Class对象),而Class对象也是特殊的Java对象。所以我们常说的类锁,其实就是Class对象的锁。
-
synchronized是⼀种互斥锁,⼀次只能允许⼀个线程进⼊被锁住的代码块
-
synchronized是⼀种内置锁**/监视器锁,Java中每个对象都有⼀个内置锁(监视器,也可以理解成锁标记),⽽synchronized就是使⽤对象的内置锁(监视器)**来将代码块(⽅法)锁定的! (锁的是对象,但我们同步的是⽅法/代码块)
优点:
- synchronized保证了线程的原⼦性。(被保护的代码块是⼀次被执⾏的,没有任何线程会同时访问)
- synchronized还保证了可⻅性。(当执⾏完synchronized之后,修改后的变量对其他的线程是可⻅的)
- 由于synchronized保证了一个变量在同一时刻只允许一条线程对其进行lock操作,在执行unlock之前,必须先把此变量同步回主内存,所以也保证了有序性,可以说是线程的有序性,而不是CPU指令的有序性
- Java中的synchronized,通过使⽤内置对象锁,来实现对变量的同步操作,进⽽实现了对变量操作的原⼦性和其他线程对变量的可⻅性,从⽽确保了并发情况下的线程安全。
1.2. 说说自己是怎么使用 synchronized 关键字
synchronized 关键字最主要的三种使用方式:
1.修饰实例方法: 作用于当前对象实例加锁,进入同步代码前要获得 当前对象实例的锁
synchronized void method() {
//业务代码
}
2.修饰静态方法: 也就是给当前类加锁,会作用于类的所有对象实例 ,进入同步代码前要获得 当前 class 的锁。因为静态成员不属于任何一个实例对象,是类成员( static 表明这是该类的一个静态资源,不管 new 了多少个对象,只有一份)。所以,如果一个线程 A 调用一个实例对象的非静态 synchronized
方法,而线程 B 需要调用这个实例对象所属类的静态 synchronized
方法,是允许的,不会发生互斥现象,因为访问静态 synchronized
方法占用的锁是当前类的锁,而访问非静态 synchronized
方法占用的锁是当前实例对象锁。
synchronized void staic method() {
//业务代码
}
3.修饰代码块 :指定加锁对象,对给定对象/类加锁。synchronized(this|object)
表示进入同步代码库前要获得给定对象的锁。synchronized(类.class)
表示进入同步代码前要获得 当前 class 的锁
synchronized(this) {
//业务代码
}
总结:
synchronized
关键字加到static
静态方法和synchronized(class)
代码块上都是是给 Class 类上锁。synchronized
关键字加到实例方法上是给对象实例上锁。- 尽量不要使用
synchronized(String a)
因为 JVM 中,字符串常量池具有缓存功能!
下面我以一个常见的面试题为例讲解一下 synchronized
关键字的具体使用。
面试中面试官经常会说:“单例模式了解吗?来给我手写一下!给我解释一下双重检验锁方式实现单例模式的原理呗!”
1.2.2. 双重校验锁实现对象单例(线程安全)
public class Singleton {
private volatile static Singleton uniqueInstance;
private Singleton() {
}
public static Singleton getUniqueInstance() {
//先判断对象是否已经实例过,没有实例化过才进入加锁代码
if (uniqueInstance == null) {
//类对象加锁
synchronized (Singleton.class) {
if (uniqueInstance == null) {
uniqueInstance = new Singleton();
}
}
}
return uniqueInstance;
}
}
另外,需要注意 uniqueInstance
采用 volatile
关键字修饰也是很有必要。
uniqueInstance
采用 volatile
关键字修饰也是很有必要的, uniqueInstance = new Singleton();
这段代码其实是分为三步执行:
- 为
uniqueInstance
分配内存空间 - 初始化
uniqueInstance
- 将
uniqueInstance
指向分配的内存地址
但是由于 JVM 具有指令重排的特性,执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题,但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如,线程 T1 执行了 1 和 3,此时 T2 调用 getUniqueInstance
() 后发现 uniqueInstance
不为空,因此返回 uniqueInstance
,但此时 uniqueInstance
还未被初始化。
使用 volatile
可以禁止 JVM 的指令重排,保证在多线程环境下也能正常运行。
1.3. 构造方法可以使用 synchronized 关键字修饰么?
先说结论:构造方法不能使用 synchronized 关键字修饰。
构造方法本身就属于线程安全的,不存在同步的构造方法一说。
1.3. 讲一下 synchronized 关键字的底层原理
1.3.1. synchronized 同步语句块的情况
public class SynchronizedDemo {
public void method() {
synchronized (this) {
System.out.println("synchronized 代码块");
}
}
}
通过 JDK 自带的 javap
命令查看 SynchronizedDemo
类的相关字节码信息:首先切换到类的对应目录执行 javac SynchronizedDemo.java
命令生成编译后的 .class 文件,然后执行javap -c -s -v -l SynchronizedDemo.class
。
从上面我们可以看出:
synchronized
同步语句块的实现使用的是 monitorenter
和 monitorexit
字节码指令,其中 monitorenter
指令指向同步代码块的开始位置,monitorexit
指令则指明同步代码块的结束位置。
当执行 monitorenter
指令时,线程试图获取锁也就是获取 对象监视器 monitor
的持有权。
在 Java 虚拟机(HotSpot)中,Monitor 是基于 C++实现的,由ObjectMonitor实现的。每个对象中都内置了一个
ObjectMonitor
对象。另外,
wait/notify
等方法也依赖于monitor
对象,这就是为什么只有在同步的块或者方法中才能调用wait/notify
等方法,否则会抛出java.lang.IllegalMonitorStateException
的异常的原因。
在执行monitorenter
时,会尝试获取对象的锁,如果锁的计数器为 0 则表示锁可以被获取,获取后将锁计数器设为 1 也就是加 1。
在执行 monitorexit
指令后,将锁计数器设为 0,表明锁被释放。如果获取对象锁失败,那当前线程就要阻塞等待,直到锁被另外一个线程释放为止。
如果获取monitor对象失败,该线程则会进入阻塞状态,直到其他线程释放锁。
1.3.2. synchronized
修饰方法的的情况
public class SynchronizedDemo2 {
public synchronized void method() {
System.out.println("synchronized 方法");
}
}
synchronized
修饰的方法并没有 monitorenter
指令和 monitorexit
指令,取得代之的确实是 ACC_SYNCHRONIZED
标识,该标识指明了该方法是一个同步方法。JVM 通过该 ACC_SYNCHRONIZED
访问标志来辨别一个方法是否声明为同步方法,从而执行相应的同步调用。
1.3.3.总结
synchronized
同步语句块的实现使用的是 monitorenter
和 monitorexit
指令,其中 monitorenter
指令指向同步代码块的开始位置,monitorexit
指令则指明同步代码块的结束位置。
synchronized
修饰的方法并没有 monitorenter
指令和 monitorexit
指令,取得代之的确实是 ACC_SYNCHRONIZED
标识,该标识指明了该方法是一个同步方法。
不过两者的本质都是对对象监视器 monitor 的获取。
1.4. 说说 JDK1.6 之后的 synchronized 关键字底层做了哪些优化,可以详细介绍一下这些优化吗
synchronized 关键字底层原理属于 JVM 层面。
JDK1.6 对锁的实现引入了大量的优化,如自旋锁、适应性自旋锁、锁消除、锁粗化、轻量级锁、偏向锁等技术来减少锁操作的开销。
自旋锁
互斥同步对性能影响最大的是阻塞的实现,挂起线程和恢复线程的操作都需要转入到内核态中完成,这些操作给系统的并发性能带来很大的压力。
于是在阻塞之前,我们让线程执行一个忙循环(自旋),看看持有锁的线程是否释放锁,如果很快释放锁,则没有必要进行阻塞。
锁消除
锁消除是指虚拟机即时编译器(JIT)在运行时,对一些代码上要求同步,但是检测到不可能发生数据竞争的锁进行消除。
锁粗化
如果虚拟机检测到有这样一串零碎的操作都对同一个对象加锁,将会把加锁同步的范围扩展(粗化)到整个操作序列的外部。
锁主要存在四种状态,依次是:无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态,他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级,这种策略是为了提高获得锁和释放锁的效率。
轻量级锁
轻量级锁也是在JDK1.6中引入的新型锁机制。它设计的初衷是在没有多线程竞争的情况下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
加锁过程:
在代码进入同步块的时候,如果此对象没有被锁定(锁标志位为“01”状态),虚拟机首先在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间,用于存储对象目前Mark Word的拷贝(官方把这份拷贝加了一个Displaced前缀,即Displaced Mark Word)。然后虚拟机使用CAS操作尝试将对象的Mark Word更新为指向锁记录(Lock Record)的指针。如果更新成功,那么这个线程就拥有了该对象的锁,并且对象的Mark Word标志位转变为“00”,即表示此对象处于轻量级锁定状态;如果更新失败,虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧,如果说明当前线程已经拥有了这个对象的锁,那就可以直接进入同步块中执行,否则说明这个锁对象已经被其他线程占有了。如果有两条以上的线程竞争同一个锁,那轻量级锁不再有效,要膨胀为重量级锁,锁标志变为“10”,Mark Word中存储的就是指向重量级锁的指针,而后面等待的线程也要进入阻塞状态。
解锁过程:
如果对象的Mark Word仍然指向线程的锁记录,那就用CAS操作将对象当前的Mark Word与线程栈帧中的Displaced Mark Word交换回来,如果替换成功,整个同步过程就完成了。如果替换失败,说明有其他线程尝试过获取该锁,那就要在释放锁的同时,唤醒被挂起的线程。
如果没有竞争,轻量级锁使用CAS操作避免了使用互斥量的开销,但如果存在竞争,除了互斥量的开销外,还额外发生了CAS操作,因此在有竞争的情况下,轻量级锁比传统重量级锁开销更大。
偏向锁
偏向锁是JDK1.6中引用的优化,它的目的是消除数据在无竞争情况下的同步原语,进一步提高程序的性能。如果说轻量级锁是在无竞争的情况下使用CAS去消除同步使用的互斥量,那么偏向锁就是在无竞争的情况下把整个同步都消除掉,连CAS操作也不用了。自JDK6开始,hotSpot虚拟机默认启用参数 -XX:+UseBiased Locking,表示开启偏向锁
加锁过程:
当锁对象第一次被线程获取的时候,虚拟机会把对象头中的标志位设置为“01”,把偏向模式设置为“1”,即偏向模式。同时使用CAS操作把获取到这个锁的线程ID记录在对象的Mark Word中,如果CAS操作成功。持有偏向锁的线程以后每次进入这个锁相关的同步块时,虚拟机都可以不再进行任何同步操作。
解锁过程:
一旦出现另外一个线程去尝试获取这个锁的情况,偏向模式就马上宣告结束,根据锁对象目前是否处于被锁定状态决定是否撤销偏向,撤销后偏向位恢复到未锁定或轻量级锁定的状态,后续的操作根据轻量级锁去执行。
同轻量级锁一样,如果没有竞争,那么偏向锁就是多余的。
1.5. 谈谈 synchronized 和 ReentrantLock 的区别
1.5.1. 两者都是可重入锁
“可重入锁” 指的是自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁,此时这个对象锁还没有释放,当其再次想要获取这个对象的锁的时候还是可以获取的,如果不可锁重入的话,就会造成死锁。同一个线程每次获取锁,锁的计数器都自增 1,所以要等到锁的计数器下降为 0 时才能释放锁。
1.5.2.synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API
synchronized
是依赖于 JVM 实现的,前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized
关键字进行了很多优化,但是这些优化都是在虚拟机层面实现的,并没有直接暴露给我们。ReentrantLock
是 JDK 层面实现的(也就是 API 层面,需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成),所以我们可以通过查看它的源代码,来看它是如何实现的。
1.5.3.ReentrantLock 比 synchronized 增加了一些高级功能
相比synchronized
,ReentrantLock
增加了一些高级功能。主要来说主要有三点:
- 等待可中断 :
ReentrantLock
提供了一种能够中断等待锁的线程的机制,通过lock.lockInterruptibly()
来实现这个机制。也就是说正在等待的线程可以选择放弃等待,改为处理其他事情。 - 可实现公平锁 :
ReentrantLock
可以指定是公平锁还是非公平锁。而synchronized
只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。ReentrantLock
默认情况是非公平的,可以通过ReentrantLock
类的ReentrantLock(boolean fair)
构造方法来制定是否是公平的。 - 可实现选择性通知(锁可以绑定多个条件):
synchronized
关键字与wait()
和notify()
/notifyAll()
方法相结合可以实现等待/通知机制。ReentrantLock
类当然也可以实现,但是需要借助于Condition
接口与newCondition()
方法。
Condition
是 JDK1.5 之后才有的,它具有很好的灵活性,比如可以实现多路通知功能也就是在一个Lock
对象中可以创建多个Condition
实例(即对象监视器),线程对象可以注册在指定的Condition
中,从而可以有选择性的进行线程通知,在调度线程上更加灵活。 在使用notify()/notifyAll()
方法进行通知时,被通知的线程是由 JVM 选择的,用ReentrantLock
类结合Condition
实例可以实现“选择性通知” ,这个功能非常重要,而且是 Condition 接口默认提供的。而synchronized
关键字就相当于整个 Lock 对象中只有一个Condition
实例,所有的线程都注册在它一个身上。如果执行notifyAll()
方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题,而Condition
实例的signalAll()
方法 只会唤醒注册在该Condition
实例中的所有等待线程。
如果你想使用上述功能,那么选择 ReentrantLock 是一个不错的选择。性能已不是选择标准
1.6 类锁和对象锁
synchronized修饰静态⽅法获取的是类锁(类的字节码⽂件对象),synchronized修饰普通⽅法或代码块获取的是对象锁。
获取了类锁的线程和获取了对象锁的线程是不冲突的!只有同个类型的锁才会冲突,互相等待!
public class SynchoronizedDemo {
/**
* synchronized修饰静态⽅法获取的是类锁(类的字节码⽂件对象),synchronized修饰普通⽅法或代码块获取的是对象锁。
* 获取了类锁的线程和获取了对象锁的线程是不冲突的!只有同个类型的锁才会冲突,互相等待!
* @throws InterruptedException
*/
//synchronized修饰⾮静态⽅法
public synchronized void function1() throws InterruptedException {
for (int i = 0; i <3; i++) {
Thread.sleep(2000);
System.out.println("function1 running...");
}
}
//synchronized修饰⾮静态⽅法
public synchronized void function2() throws InterruptedException {
for (int i = 0; i <3; i++) {
Thread.sleep(1000);
System.out.println("function2 running...");
}
}
//synchronized修饰静态⽅法
public static synchronized void staticFunction()
throws InterruptedException {
for (int i = 0; i < 3; i++) {
Thread.sleep(1000);
System.out.println("Static function running...");
}
}
public static void main(String[] args) {
final SynchoronizedDemo demo = new SynchoronizedDemo();
// 创建线程执⾏静态⽅法
Thread t1 = new Thread(() -> {
try {
staticFunction();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
// 创建线程执⾏实例⽅法
Thread t2 = new Thread(() -> {
try {
demo.function1();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
// 创建线程执⾏实例⽅法
Thread t3 = new Thread(() -> {
try {
demo.function2();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
// 启动
t1.start();
t2.start();
t3.start();
}
}
四、Volatile关键字
volatile关键字用来保证该变量对所有线程的可见性,但不保证原子性,可以说volatile是一种轻量级的同步机制
作用:
-
保证该变量对所有线程的可见性。当一个变量被修改时,任何访问这个字段的线程将会得到最新的值
-
不保证原子性
-
volatile可以防止重排序。重排序指的就是:程序执行的时候,CPU、编译器可能会对执行顺序做一些调整,导致执行的顺序并不是从上往下的。从而出现了一些意想不到的效果。而如果声明了volatile,那么CPU、编译器就会知道这个变量是共享的,不会被缓存在寄存器或者其他不可见的地方。
使用条件:
- 修改变量时不依赖变量的当前值(因为volatile是不保证原子性的)
- 该变量不会纳入到不变性条件中(该变量是可变的)
- 在访问变量的时候不需要加锁(加锁就没必要使用volatile这种轻量级同步机制了)
五、Synchronized与Volatile区别
synchronized
关键字和 volatile
关键字是两个互补的存在,而不是对立的存在!
- 性能上:
volatile
关键字是线程同步的轻量级实现,所以**volatile
性能肯定比synchronized
关键字要好**。 - 修饰范围上:
volatile
关键字只能用于变量而synchronized
关键字可以修饰方法以及代码块。 - 特性上:
volatile
关键字能保证数据的可见性,但不能保证数据的原子性。synchronized
关键字两者都能保证。 - 作用上:
volatile
关键字主要用于解决变量在多个线程之间的可见性,而synchronized
关键字解决的是多个线程之间访问资源的同步性。