共享模型之管程
一、引入
看看下面的例子，两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？
static int counter = 0;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(new Runnable() {
public void run() {
for (int i = 0; i < 5000; i++){
counter++;
}
}
}, "t1");
Thread t2 = new Thread(new Runnable() {
public void run() {
for (int i = 0; i < 5000; i++){
counter--;
}
}
}, "t2");
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("counter = " + counter);
}
可以从下面的图中看出，结果不为零。
问题分析
以上的结果可能是正数、负数、零。为什么呢？因为 Java 中对静态变量的自增，自减并不是原子操作，要彻底理 解，必须从字节码来进行分析：
例如对于i++ 而言（i 为静态变量），实际会产生如下的 JVM 字节码指令：
getstatic i // 获取静态变量i的值
iconst_1 // 准备常量1
iadd // 自增
putstatic i // 将修改后的值存入静态变量i
而对应i--也是类似：
getstatic i // 获取静态变量i的值
iconst_1 // 准备常量1
isub // 自减
putstatic i // 将修改后的值存入静态变量i
而 Java 的内存模型如下，完成静态变量的自增，自减需要在主存和工作内存中进行数据交换：
在多线程下这 8 行代码可能交错运行，如下图所示：
这样就会导致结果出现-1。
临界区 Critical Section
- 一个程序运行多个线程本身是没有问题的
- 问题出在多个线程访问共享资源
- 多个线程读取共享资源也不会产生问题
- 但是在多个线程对共享资源读写操作时发生指令交错，就会出现问题
- 一段代码块如果出现对共享资源的多线程读写操作，这个代码块称为临界区
例如，下面代码中的临界区
static int counter = 0;
static void increment()
// 临界区
{
counter++;
}
static void decrement()
// 临界区
{
counter--;
}
竞态条件 Race Condition
多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件
避免临界区的竞态条件发生的手段有：
- 阻塞式的解决方案：Synchronized、lock
- 非阻塞式的解决方法：原子变量
二、synchronized用在代码块上
Synchronized俗称【对象锁】，它采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】，其他线程想要再获取这个对象锁时就会阻塞。这样就保证了拥有锁的线程可以安全的执行临界区中的代码，不用担心上下文切换。
注意：虽然Java中互斥和同步都是使用Synchronized关键字来实现的，但是他们还是有区别的
- 互斥是保证临界区的竞态条件发生时，同一时刻只能有一个线程执行临界区的代码
- 同步是指由于多个线程的执行先后顺序不同，需要一个线程等待其他线程运行到某个点上
语法:
synchronized(对象){ // 线程1， 线程2(blocked)
//临界区
}
将上面的代码使用Synchronized实现互斥
static int counter = 0;
static final Object lock = new Object();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(new Runnable() {
public void run() {
for (int i = 0; i < 5000; i++){
synchronized(lock){
counter++;
}
}
}
}, "t1");
Thread t2 = new Thread(new Runnable() {
public void run() {
for (int i = 0; i < 5000; i++){
synchronized(lock){
counter--;
}
}
}
}, "t2");
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("counter = " + counter);
}
下面使用时序图来展示加锁之后，上面代码的工作流程：
从上面的分析可以看出，synchronized实际是用对象锁保证了临界区内代码的原子性，使得临界区内的代码变成了不可分割的，不会被线程切换所打断。
请思考下面的问题：
- 如果把 synchronized(obj) 放在 for 循环的外面，如何理解？
- 会对整个for循环进行加锁，只有当t2的for循环执行完成之后，t1才会继续执行
- 如果 t1 synchronized(obj1) 而 t2 synchronized(obj2) 会怎样运作？
- 两个线程使用了不同的对象锁，仍然会出现被打断的现象
- 如果 t1 synchronized(obj) 而 t2 没有加会怎么样？如何理解？
- 和上面的问题类型，t1虽然能获得对象锁，但是t2执行时不会检测是否已经加锁，仍然会出现大段的现象
面向对象改进：实现线程安全的对象
public class AutoIncreaseTest {
public static void main(String[] args) throws InterruptedException {
Room room = new Room();
Thread t1 = new Thread(new Runnable() {
public void run() {
for (int i = 0; i < 5000; i++){
room.incr();
}
}
}, "t1");
Thread t2 = new Thread(new Runnable() {
public void run() {
for (int i = 0; i < 5000; i++){
room.decr();
}
}
}, "t2");
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("counter = " + room.getCounter());
}
}
/**
* 实现线程安全的自增自减类
*/
class Room{
private int counter = 0;
public void incr(){
synchronized(this){ //使用当前对象对自增进行加锁
counter++;
}
}
public void decr(){
synchronized (this){//使用当前对象对自减进行加锁
counter--;
}
}
public int getCounter(){
synchronized (this){//使用当前对象对获取值进行加锁
return counter;
}
}
}
三、synchronized用在方法上
synchronized除了可以用在代码块上，还可以用在普通同步方法（实例方法），锁是当前实例对象 ，进入同步代码前要获得当前实例的锁
class Test{
public synchronized void test() {
}
}
等价于
class Test{
public void test() {
synchronized(this) {
}
}
}
同时也可以锁静态同步方法，锁是当前类的class对象 ，进入同步代码前要获得当前类对象的锁
class Test{
public synchronized static void test() {
}
}
等价于
class Test{
public static void test() {
synchronized(Test.class) {
}
}
}
四、变量的线程安全分析
1、成员变量和静态变量是否线程安全？
- 如果它们没有共享，则线程安全
- 如果它们被共享了，根据它们的状态是否能够改变，又分两种情况
- 如果只有读操作，则线程安全
- 如果有读写操作，则这段代码是临界区，需要考虑线程安全
查下面的代码，向一个成员变量ArrayList中添加和删除元素，单线程时不会出现任何问题，但是多线程的情况下可能会出现删除空的ArrayList从而引发异常（如下图所示）：
ArrayList<String> list = new ArrayList<>();
static final int THREAD_NUMBER = 2;
static final int LOOP_NUMBER = 200;
public static void main(String[] args) {
ThreadUnsafe test = new ThreadUnsafe();
for (int i = 0; i < THREAD_NUMBER; i++) {
new Thread(() -> {
test.method1(LOOP_NUMBER);
}, "Thread" + i).start();
}
}
public void method1(int loopNumber) {
for (int i = 0; i < loopNumber; i++) {
// 临界区, 会产生竞态条件
method2();
method3();
// 临界区
}
}
private void method2() {
list.add("1");
}
private void method3() {
list.remove(0);
}
那为什么会这样呢？因为无论哪个线程中的 method2或者method3都 引用的都是同一个对象中的 list 成员变量，如下图所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BdMn8uLG-1590666361668)(C:\Users\韩壮\AppData\Roaming\Typora\typora-user-images\image-20200527184004424.png)]
2、局部变量是否线程安全？
- 局部变量是线程安全的
- 但局部变量引用的对象则未必
- 如果该对象没有逃离方法的作用访问，它是线程安全的
- 如果该对象逃离方法的作用范围，需要考虑线程安全
对于下面的代码：虽然也有i++操作，但是在多线程操作下却是安全的，因为其中的i是局部变量
public static void test1() {
int i = 10;
i++;
}
下面从字节码和JVM的角度分析为什么局部变量在多线程是安全的，上面的这段代码字节码为：
0: bipush 10
2: istore_0
3: iinc 0, 1
6: return
自增操作使用iinc一条指令就完成了，而且每个线程的i都存储在线程私有的栈桢中，多线程是不共享的，如下图所示：
五、常见线程安全类
当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些线程将如何交替执行，并且在主调代码中不需要任何额外的同步和协同，这个类都能表现出正确的行为，那么就可以说这个类是线程安全的
常见线程安全类包括：
- String
- Integer
- StringBuffer
- Random
- Vector
- Hashtable
- java.util.concurrent 包下的类，如ConcurrentHashMap
这里说它们是线程安全的是指，多个线程调用它们同一个实例的某个方法时，是线程安全的。也可以理解为
- 它们的每个方法都是原子的，synchronized修饰的
- 但它们多个方法的组合不是原子的
也就是说多线程运行下面的代码是安全的：
Hashtable table = new Hashtable();
new Thread(() -> {
table.put("key", "value1");
}).start();
new Thread(() -> {
table.put("key", "value2");
}).start();
但是下面代码就不是线程安全的，因为虽然put和get方法中代码执行是原子的，但是这两个方法之间可能发生线程的下文的切换，从而导致执行发生不正确的结果，如下图所示：
Hashtable table = new Hashtable();
// 线程1，线程2
if( table.get("key") == null) {
table.put("key", value);
}
不可变类线程安全性 ：String、Integer 等都是不可变类，因为其内部的状态不可以改变，因此它们的方法都是线程安全的。
六、Monitor概念
1、Java 对象头
对象头中的内容（以 32 位虚拟机为例），共8个字节，4字节存储Mark Word，另外4个字节存储类对象的位置：
而数组多了一部分用于存储数组长度：
其中 Mark Word 结构如下图所示，在不同的状态下 Mark Word 中存储的内容不同。正常情况下（normal）存储了hashcode，还有垃圾回收的年龄age，biased_lock，以及当前的状态（01）。加锁（重量级）状态下（Heavyweight Locked）存储了指向的monitor的地址（ptr_to_heavyweight_monitor）还有当前的状态（10）。
2、Monitor（锁）
Monitor被翻译为监视器或者管程
每个java对象都可以关联一个Monitor对象，如果使用synchronized给对象上锁（重量级）之后，该对象的Mark Word就会被设为指向monitor对象的指针。monitor的结构如下图所示：
使用Monitor给对象上锁（重量级锁）的过程（如下图所示）：
- 刚才是Monitor的Owner为null
- 当Thread-2执行synchronized(obj) 就会将monitor的所有者Owner更改为Thread-2，monitor只能有一个所有者Owner
- 在Thread-2上锁的过程中，如果Thread-3、Thread-4、Thread-5也来执行执行synchronized(obj) ，就进入EntryList处于阻塞状态（BLOCKED）
- 当Thread-2执行完同步代码块中的内容，就会唤醒EntryList处于阻塞状态的线程来竞争锁，竞争时是非公平的
- 其中WaitSet中的线程是获得过锁，但是进入WAIT状态的
注意：
- synchronized必须进入同一个对象的monitor才会有上述过程，不同的锁对象拥有不同的monitor
- 不加synchronized锁的对象不会管理monitor监视器，不会遵循上述规则
七、synchronized 原理
1、基本原理
先看下面的代码：
static final Object lock = new Object();
static int counter = 0;
public static void main(String[] args) {
synchronized (lock) {
counter++;
}
}
对上面的代码它的字节码为：
0: getstatic #2 // <- lock引用 （synchronized开始）
3: dup
4: astore_1 // lock引用 -> slot 1
5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
6: getstatic #3 // <- i
9: iconst_1 // 准备常数 1
10: iadd // +1
11: putstatic #3 // -> i
14: aload_1 // <- lock引用
15: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
16: goto 24
19: astore_2 // e -> slot 2
20: aload_1 // <- lock引用
21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
22: aload_2 // <- slot 2 (e)
23: athrow // throw e
24: return
Exception table:
from to target type
6 16 19 any
19 22 19 any
从字节码的第5行可以看出，在临界区进入临界区的时候使用monitorenter指令将 lock对象 MarkWord 置为 Monitor 指针 。
而临界区结束之后使用了monitorexit将 lock对象 MarkWord 重置, 唤醒 EntryList。
为了防止6~16行出现异常时无法释放锁，异常处理中第21行也是用monitorexit对锁进行了释放。
注意：方法级别的 synchronized 不会在字节码指令中有所体现
2、轻量级锁
轻量级锁的使用场景：如果一个对象虽然有多线程要对其加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化
注意：轻量级锁对于开发者是透明的，即语法仍然是 synchronized
假设有两个方法同步块，利用同一个对象加锁，
static final Object obj = new Object();
public static void method1() {
synchronized (obj) {
// 同步块 A
method2();
}
}
public static void method2() {
synchronized (obj) {
// 同步块 B
}
}
它们使用的轻量级锁的流程如下面分析所示：
- 创建锁记录（Lock Record）对像，每个线程的栈桢中都包含一个锁记录结构，内部可以存储锁定对的Mark Word，和锁对象的引用
- 让锁记录中 Object reference 指向锁对象，并尝试使用cas替换 Object 的 Mark Word，将 Mark Word （Normal状态）存入锁记录中。
- 如果 cas 替换成功，对象头中存储了 锁记录地址和状态 00 ，表示由该线程给对象加锁，这时图示如下
- 有两种情况会发生 cas 失败：
- 如果其他线程已经持有该对象的轻量级锁，这时表明有竞争，会进入锁膨胀过程（下面会讲）
- 如果是自己执行了synchronized 导致锁重入（如上面method2方法所示），那么会再添加一条lock record作为重入的计数，其中内容为null
- 当退出synchronized 代码块（解锁时），如果有取值为null的锁记录，表示有重入，这时删除该条锁记录，表示重入指减一
- 当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用cas将Mark Word的值恢复给对象头
- 成功，则解锁成功
- 失败，说明轻量级锁进行了锁膨胀已经升级为重量级锁，进入重量级锁解锁流程
2）锁膨胀
如果尝试加轻量级锁过程中，CAS无法操作成功，这时就是已经给锁对象上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁，步骤如下所示：
static Object obj = new Object();
public static void method1() {
synchronized (obj) {
// 同步块
}
}
- 当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁
- Thread-1 进行轻量级加锁失败，进入锁膨胀流程
- 为Object对象申请Monitor锁，让Object指向重量级锁Monitor地址
- 然后自己进入的 EntryList 进行阻塞BLOCKED
- 当Thread-0退出同步块进行解锁时，使用 cas 将 Mark Word 的值恢复给对象头，失败。这时进入重量级锁解锁流程，即按照Monitor地址找到Monitor对象，设置Owner为null，唤醒 EntryList 中 BLOCKED 线程
3、自旋优化
重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步 块，释放了锁），这时当前线程就可以避免阻塞。
自旋的出现是因为Thead线程进入EntryList 进行阻塞BLOCKED需要进行上下文切换，会消耗资源。如果自旋几轮之后发现锁已经释放，则可以直接获得锁，不用进入阻塞状态。
自旋重试成功的情况：
自旋重试失败的情况：
注意：
- 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
- 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会 高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
- Java 7 之后不能控制是否开启自旋功能
4、偏向锁
1）简介
引入：轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。
Java 6 中引入了偏向锁来做进一步优化：第一次加锁使用CAS将线程ID设置到对象头的Mark Word头，之后重入时发现这个线程ID是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有
public static void m1() {
synchronized (obj) {
// 同步块 A
m2();
}
}
public static void m2() {
synchronized (obj) {
// 同步块 B
m3();
}
}
public static void m3() {
synchronized (obj) {
// 同步块 C
}
}
使用轻量级锁的示意图如下图所示：
使用偏向锁时：
2）偏向状态
回忆一下对象头格式
偏向锁的特点：
-
如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即后 3 位为 101，这时它的 thread、epoch、age 都为 0
-
偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数
-XX:BiasedLockingStartupDelay=0来禁用延迟 -
处于偏向锁的对象解锁后，线程 id 仍存储于对象头中
-
如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即后 3 位为 001，这时它的 hashcode、 age 都为 0，第一次用到 hashcode 时才会赋值
-
添加 VM 参数 -XX:-UseBiasedLocking 禁用偏向锁
-
会发生撤销偏向锁的情况
- 正常状态对象一开始是没有 hashCode 的，第一次调用才生成，hashCode调用之后偏向锁被撤销
- 轻量级锁会在锁记录中记录 hashCode
- 重量级锁会在 Monitor 中记录 hashCode
- 当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁
- 调用 wait/notify
- 正常状态对象一开始是没有 hashCode 的，第一次调用才生成，hashCode调用之后偏向锁被撤销
-
批量重偏向 ：如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象 的 Thread ID。当撤销偏向锁阈值超过 20 次后，jvm 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程(T2)
-
批量撤销 : 当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象 都会变为不可偏向的，新建的对象也是不可偏向的
5、锁消除
当即时编译器（JIT）对代码进行优化时发现，没必要加锁就会将锁进行消除。使用-XX:-EliminateLocks参数就可以禁止锁消除。对于下面的代码：
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 3)
@Measurement(iterations = 5)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {
static int x = 0;
@Benchmark
public void a() throws Exception {
x++;
}
@Benchmark
public void b() throws Exception {
Object o = new Object();
synchronized (o) {
x++;
}
}
}
下图是对上面的代码分别进行锁优化和禁用掉锁优化之后方法a和b的新跟那个比较，可以看出锁优化之后a和b方法性能相近，而禁用掉锁优化之后b方法明显慢于a方法
总结：
synchronized的执行过程：
- 检测Mark Word里面是不是当前线程的ID，如果是，表示当前线程处于偏向锁
- 如果不是，则使用CAS将当前线程的ID替换Mard Word，如果成功则表示当前线程获得偏向锁，置偏向标志位1
- 如果失败，则说明发生竞争，撤销偏向锁，进而升级为轻量级锁。
- 当前线程使用CAS将对象头的Mark Word替换为锁记录指针，如果成功，当前线程获得锁
- 如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
- 如果自旋成功则依然处于轻量级状态。
- 如果自旋失败，则升级为重量级锁。
扫一扫
3476
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
