线程同步：synchronized及其原理

最新推荐文章于 2024-03-11 16:32:38 发布

Feathers .

最新推荐文章于 2024-03-11 16:32:38 发布

阅读量121

点赞数

分类专栏： # JUC 文章标签：指针多线程 java jvm 编程语言

本文链接：https://blog.csdn.net/xf616510229/article/details/115957338

版权

JUC 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

本文深入探讨了线程竞争问题及其在Java中的表现，以银行取钱问题为例展示了线程安全问题。文章指出，线程并发执行和非原子操作是引发线程安全问题的主要原因。接着，作者介绍了锁的概念，通过锁来确保资源在同一原子操作中被独占，以避免线程竞争。详细阐述了synchronized关键字的工作原理，包括锁的状态、锁升级的过程，并强调了锁升级后无法降级的特点。最后，讨论了不同锁机制在不同场景下的适用性。

摘要由CSDN通过智能技术生成

线程竞争问题

多个线程同时共享并操作同一个数据，就会发生线程竞争。就有可能引发线程安全问题；下面是经典的银行取钱问题：

public class ThreadSafeTest {

    public static class People implements Runnable {

        private int withdrawMoney = 0;

        public static Integer money = 1000;

        public People(int withdrawMoney) {
            this.withdrawMoney = withdrawMoney;
        }

        @Override
        public void run() {
            if (money - withdrawMoney >= 0) {
                money = money - withdrawMoney;
                System.out.println("取钱" + withdrawMoney + "成功，余额为" + money);
            } else {
                System.out.println("取钱" + withdrawMoney + "失败，余额为" + money);
            }
        }
    }

    public static void main(String[] args) {
        Thread t1 = new Thread(new People(200));
        Thread t2 = new Thread(new People(400));
        Thread t3 = new Thread(new People(300));
        Thread t4 = new Thread(new People(100));
        Thread t5 = new Thread(new People(200));

        t1.start();
        t2.start();
        t3.start();
        t4.start();
        t5.start();
    }

}

结果：

取钱200成功，余额为700
取钱200失败，余额为0
取钱400成功，余额为0
取钱300成功，余额为400
取钱100成功，余额为700

导致线程安全问题的根本原因主要是以下两点：

线程是并发执行的，CPU会在多个线程之前来回切换。即有线程竞争
CPU所执行的代码指令是多个，不是原子的。比如判断余额、扣减余额、显示余额三个就是三条CPU指令，执行完一个指令后，有可能执行其他线程的有关指令，导致资源混乱。

所以避免线程竞争是解决线程安全问题的一种解决方案

锁的概念

线程安全问题即是并发安全问题，无论是并发安全问题还是并行安全问题，都可以使用锁来解决。锁的办法比较直观，只要保证余额判断、扣减金额、显示金额针对统一资源处于同一原子操作，即是线程独占的。

所谓的锁就是在多个线程共同可访问的空间中放置一个标记，假设资源A的锁为：res_lock，当res_lock=0时代表资源A未被任何线程访问，而res_lock=1时代表资源A已被某个线程访问。

假设Thread1 与 Thread2 共同访问资源A，ThreadA被CPU先选中，开始执行逻辑代码：判断余额-扣减金额-查询余额。Thread1发现 res_lock=0 说明没有其他线程正在访问此资源，Thread1 将res_lock置为1——这个过程称为加锁；然后开始执行逻辑。此时Thread2被CPU选中，Thread1发现res_lock=1，他将不会继续执行(会阻塞或者直接返回)——此过程称为加锁失败；此时Thread1再次被CPU选中，继续执行业务逻辑；执行结束后，Thread1将res_lock重新置为0——这个过程称为所释放。此时阻塞中的Thread2发现res_lock=0，Thread2将会重复Thread1之前的逻辑。

在这个过程中，即使Thread1的操作被CPU打断，但是由于res_lock标记，其他线程无法执行业务代码，从而保证了Thread1的业务代码的原子性，从而保证了线程安全。

无论是 synchronized 还是 Lock，还是Redis、Zookeeper分布式锁，实现的方式原理都是上述描述的锁的原理。

synchronized

synchronized 关键字可以给一段代码加锁，既保证了原子性，也保证了可见性。并且是一个可重入锁。

// 加一把锁，锁是object对象
synchronized (object){
    // 拿到锁对象可以执行代码块中的内容，否则不可以
    // ...
    // 结束后进行锁释放
}

除此之外，synchronized有以下几个变种：

同步方法：

synchronized void method1() {
}
// 等同于
void method1() {
    synchronzied (this) {
    }
}

静态同步方法：

// ClassA
static synchronized void method1() {
}
// 等同于
static void method1() {
    synchronzied (ClassA.class) {
    }
}

注意：

锁对象一般为final类型，保证引用不可变；如果引用发生变化，就锁不住了
锁对象不能为null，否则会抛出空指针异常
String、Integer等对象最好不要做为锁，因为String、Integer(0-127)位于常量池中，如果其他jar包中的资源也对同值的String进行了锁定，那么将会出现不可预知的问题。

锁释放

以下情况会进行锁释放：

代码块执行完毕
同步方法执行完毕
代码块、方法抛出异常

以下情况不会进行所释放：

sleep
wait
yield

锁原理

了解 synchronized 的实现原理，首先要知道Java对象头的概念。Java对象是存储在堆内存中，一个对象可以大致分为三个部分：

对象头：主要由MarkWord和Klass Point(类型指针)组成。
- MarkWord部分用于存储自身运行时的数据，比如表示对象的线程锁状态、存放该对象的hashCode、配合GC等功能
- Klass Point是一个指向方法区中Class信息的指针，通过这个指针随时可以知道此对象的类型
- 如果对象是数组对象，那么就会在第三个位置上记录数组的长度
对象体：是用于存储对象属性和值的主体部分，占用空间的大小取决于对象属性的数量和类型
填充字符：因为虚拟机要求对象字节必须是8字节的整数倍，填充字符就是用于凑齐这个整数倍的

既然synchronized存储在MarkWord对象头中，那么我们来看一下MarkWord在不同的锁状态下，组成的不同表现(64位虚拟机)：

首先，这五种状态 —— 正常、偏向锁、轻量级锁、重量级锁、GC标记，分别由64bit中的最后2bit表示，他们分别对应一个数值，具体如下：

状态	标志位	存储内容
正常	01，内部还是用based_lock来标记是否是偏向锁	hashCode(identity_hashcode)、对象分代年龄
偏向锁	01，内部还是用based_lock来标记是否是偏向锁	偏向线程ID、偏向时间戳、对象分代年龄
轻量级锁定	00	指向锁记录的指针
重量级锁	10	指向重量级锁的指针
GC标记	11	无任何信息，马上就被回收了

biased_lock：对象是否启用偏向锁标记， 1bit， 1表示启用了偏向锁，0表示未启用偏向锁
age： 4bit，Java对象的年龄，如果对象在Survivor区复制一次，年龄增加1，到达阈值时，会晋升到老年代
identity_hashcode： 31bit，hashCode值。对象的hashCode值将会调用System.identityHashCode()计算，然后写入到对象头中。当对象加锁后(偏向、轻量级、重量级)，MarkWord的字节没有足够的空间保存hashCode，因此该值会移动到管程Monitor中
thread：偏向锁所偏向的线程ID
epoch：偏向锁的时间戳
ptr_to_lock_record：轻量级锁状态下，指向栈中锁记录的指针
ptr_to_heavyweight_monitor：重量级锁状态下，指向对象监视器Monitor的指针

锁升级

在JVM虚拟机规范中，针对synchronized的实现并没有任何规定。早期的实现中，每次加锁都去操作系统申请，是重量级的。因为每次都去操作系统申请，导致synchronzied效率非常低，在JDK1.5之后，采取了锁升级，简单可以理解为先使用轻量级的方式，如果有需要则升级为重量级的方式。以Hotspot为例，锁升级大概经历了以下几个阶段：

无锁：没有任何线程竞争，MarkWord状态处于正常状态，lock状态为01， biased_lock偏向锁状态为0
偏向锁 (偏向某一线程 )：当有一个线程来竞争锁时，先使用偏向锁，表示对象偏爱这个线程。这个线程在执行这个锁关联的任何代码，不需要进行任何检查和切换，在竞争不激烈的情况下，效率非常高。
自旋锁(循环10次)：当有第二个线程去竞争这个锁对象，就不可以使用独占锁了，锁会自动升级为轻量级锁。谁先抢到锁谁就拥有执行权。轻量级锁内部是一个循环，他会不断的去获取锁，直到获取到为止。
重量级锁：即OS锁，如果竞争这个锁的线程太多，或者等待的时间过长，内部的循环会导致CPU负载过高，所以锁会自动升级为OS锁，也就是同步锁，此时MarkWord的状态最终会变为10，并指向监视器对象。

注意，锁升级后是无法降级的。