美团一面:说说synchronized的实现原理?问麻了。。。。 ...

打印 上一主题 下一主题

主题 917|帖子 917|积分 2751

引言

在现代软件开发范畴,多线程并发编程已经成为提高系统性能、提升用户体验的重要手段。然而,多线程环境下的数据同步与资源共享问题也随之而来,处理不妥可能导致数据不一致、死锁等各种并发问题。为此,Java语言提供了一种内置的同步机制——synchronized关键字,它能够有用地解决并发控制的问题,确保共享资源在同一时间只能由一个线程访问,从而维护步伐的正确性与一致性。
synchronized作为Java并发编程的基础构建块,其简洁易用的语法形式背后蕴含着复杂的底层实现原理和技术细节。深入理解synchronized的运行机制,不仅有助于我们更好地利用这一特性编写出高效且安全的并发步伐,同时也有利于我们在面对复杂并发场景时,做出更为明智的计划决策和优化策略。
本文将从synchronized的基本概念出发,渐渐分析其内在的工作机制,探讨诸如监视器(Monitor)等关键技术点,并结合实际应用场景来展示synchronized的实际结果和最佳实践。通过对synchronized底层实现原理的深度解读,旨在为大家展现Java并发世界的一隅,提升对并发编程的认知高度和实战能力。
synchronized是什么?

synchronized是Java中实现线程同步的关键字,主要用于保护共享资源的访问,确保在多线程环境中同一时间只有一个线程能够访问特定的代码段或方法。它提供了互斥性和可见性两个重要特性,确保了线程间操纵的原子性和数据的一致性。
synchronized的特性

synchronized关键字具有三个基本特性,分别是互斥性、可见性和有序性。
互斥性

synchronized关键字确保了在其控制范围内的代码在同一时间只能被一个线程实验,实现了资源的互斥访问。当一个线程进入了synchronized代码块或方法时,其他试图进入该同步区域的线程必须等待,直至拥有锁的线程实验完毕并开释锁。
可见性

synchronized还确保了线程间的数据可见性。一旦一个线程在synchronized块中修改了共享变量的值,其他随后进入同步区域的线程可以看到这个更改。这是因为synchronized的解锁过程包含了将工作内存中的最新值革新回主内存的操纵,而加锁过程则会逼迫从主内存中重新加载变量的值。
有序性

synchronized提供的第三个特性是有序性,它可以确保在多线程环境下,对于同一个锁的解锁操纵总是先行于随后对同一个锁的加锁操纵。这就意味着,通过synchronized创建起了线程之间的内存操纵序次关系,有用地解决了由于编译器和处理器优化可能带来的指令重排序问题。
synchronized可以实现哪锁?

有上述synchronized的特性,我们可以知道synchronized可以实现这些锁:

  • 可重入锁(Reentrant Lock):synchronized 实现的锁是可重入的,这意味着同一个线程可以多次获取同一个锁,而不会被壅闭。这种锁机制答应线程在持有锁的情况下再次获取相同的锁,制止了死锁的发生。
  • 排它锁/互斥锁/独占锁:synchronized 实现的锁是互斥的,也就是说,在同一时间只有一个线程能够获取到锁,其他线程必须等待该线程开释锁才气继续实验。这确保了同一时候只有一个线程可以访问被锁定的代码块或方法,从而包管了数据的一致性和完整性。
  • 悲观锁:synchronized 实现的锁属于悲观锁,因为它默认情况下假设会发生竞争,并且会导致其他线程壅闭,直到持有锁的线程开释锁。悲观锁的特点是对并发访问持保守态度,认为会有其他线程来竞争共享资源,因此在访问共享资源之前会先获取锁。
  • 非公平锁: synchronized在早期的Java版本中,默认实现的是非公平锁,也就是说,线程获取锁的序次并不一定按照它们请求锁的序次来进行,而是答应“插队”,即已经在等待队列中的线程可能被后来请求锁的线程抢占。
有关Java中的锁的分类,请参考:阿里二面:Java中锁的分类有哪些?你能说全吗?
synchronized使用方式

synchronized关键字可以修饰方法、代码块或静态方法,用于确保同一时间只有一个线程可以访问被synchronized修饰的代码片断。
修饰实例方法

当synchronized修饰实例方法时,锁住的是当前实例对象(this)。这意味着在同一时候,只能有一个线程访问此方法,所有对该对象实例的其他同步方法调用将会被壅闭,直到该线程开释锁。
  1. public class SynchronizedInstanceMethod implements Runnable{
  2.     private static int counter = 0;
  3.     // 修饰实例方法,锁住的是当前实例对象
  4.     private synchronized void add() {
  5.         counter++;
  6.     }
  7.     @Override
  8.     public void run() {
  9.         for (int i = 0; i < 1000; i++) {
  10.             add();
  11.         }
  12.     }
  13.     public static void main(String[] args) throws Exception {
  14.         SynchronizedInstanceMethod sim = new SynchronizedInstanceMethod();
  15.         Thread t1 = new Thread(sim);
  16.         Thread t2 = new Thread(sim);
  17.         
  18.         t1.start();
  19.         t2.start();
  20.         t1.join();
  21.         t2.join();
  22.         System.out.println("Final counter value: " + counter);
  23.     }
  24. }
复制代码
像上述这个例子,大家在接触多线程时一定会看过或者写过类似的代码,i++在多线程的情况下是线程不安全的,以是我们使用synchronized作用在累加的方法上,使其变成线程安全的。上述打印结果为:
  1. Final block counter value: 2000
复制代码
而对于synchronized作用于实例方法上时,锁的是当前实例对象,但是如果我们锁住的是不同的示例对象,那么synchronized就不能包管线程安全了。如下代码:
  1. public class SynchronizedInstanceMethod implements Runnable{
  2.     private static int counter = 0;
  3.     // 修饰实例方法,锁住的是当前实例对象
  4.     private synchronized void add() {
  5.         counter++;
  6.     }
  7.     @Override
  8.     public void run() {
  9.         for (int i = 0; i < 1000; i++) {
  10.             add();
  11.         }
  12.     }
  13.     public static void main(String[] args) throws Exception {
  14.         Thread t1 = new Thread(new SynchronizedInstanceMethod());
  15.         Thread t2 = new Thread(new SynchronizedInstanceMethod());
  16.         t1.start();
  17.         t2.start();
  18.         t1.join();
  19.         t2.join();
  20.         System.out.println("Final counter value: " + counter);
  21.     }
  22. }
复制代码
实验结果为:
  1. Final counter value: 1491
复制代码
修饰静态方法

若synchronized修饰的是静态方法,那么锁住的是类的Class对象,因此,无论多少个该类的实例存在,同一时候也只有一个线程能够访问此静态同步方法。针对修饰实例方法的线程不安全的示例,我们只需要在synchronized修饰的实例方法上加上static,将其变成静态方法,此时synchronized锁住的就是类的class对象。
  1. public class SynchronizedStaticMethod implements Runnable{
  2.     private static int counter = 0;
  3.     // 修饰实例方法,锁住的是当前实例对象
  4.     private static synchronized void add() {
  5.         counter++;
  6.     }
  7.     @Override
  8.     public void run() {
  9.         for (int i = 0; i < 1000; i++) {
  10.             add();
  11.         }
  12.     }
  13.     public static void main(String[] args) throws Exception {
  14.         Thread t1 = new Thread(new SynchronizedStaticMethod());
  15.         Thread t2 = new Thread(new SynchronizedStaticMethod());
  16.         t1.start();
  17.         t2.start();
  18.         t1.join();
  19.         t2.join();
  20.         System.out.println("Final counter value: " + counter);
  21.     }
  22. }
复制代码
实验结果为:
  1. Final counter value: 2000
复制代码
修饰代码块

通过指定对象作为锁,可以更准确地控制同步范围。这种方式答应在一个方法内部对不同对象进行不同的同步控制。可以指定一个对象作为锁,只有持有该对象锁的线程才气实验被synchronized修饰的代码块。
  1. public class SynchronizedBlock implements Runnable{
  2.     private static int counter = 0;
  3.     @Override
  4.     public void run() {
  5.         // 这个this还可以是SynchronizedBlock.class,说明锁住的是class对象
  6.         synchronized (this){
  7.             for (int i = 0; i < 1000; i++) {
  8.                 counter++;
  9.             }
  10.         }
  11.     }
  12.     public static void main(String[] args) throws Exception {
  13.         SynchronizedBlock block = new SynchronizedBlock();
  14.         Thread t1 = new Thread(block);
  15.         Thread t2 = new Thread(block);
  16.         t1.start();
  17.         t2.start();
  18.         t1.join();
  19.         t2.join();
  20.         System.out.println("Final counter value: " + counter);
  21.     }
  22. }
复制代码
synchronized 内置锁作为一种对象级别的同步机制,其作用在于确保临界资源的互斥访问,实现线程安全。它本质上锁定的是对象的监视器(Object Monitor),而非详细的引用变量。这种锁具有可重入性,即同一个线程在已经持有某对象锁的情况下,仍能再次获取该对象的锁,这显著增强了线程安全代码的编写便利性,并在一定程度上有助于降低因线程交互引起的死锁风险。
关于如何制止死锁,请参考:阿里二面:如何定位&制止死锁?连着两个面试问到了!
synchronized的底层原理

在JDK 1.6之前,synchronized关键字所实现的锁机制确实被认为是重量级锁。这是因为早期版本的Java中,synchronized的实现依赖于操纵系统的互斥量(Mutexes)来实现线程间的同步,这涉及到了从用户态到内核态的切换以及线程上下文切换等相对昂贵的操纵。一旦一个线程获得了锁,其他试图获取相同锁的线程将会被壅闭,这种壅闭操纵会导致线程状态的改变和CPU资源的斲丧,因此在高并发、低锁竞争的情况下,这种锁机制可能会成为性能瓶颈。
而在JDK 1.6中,对synchronized进行了大量优化,其中包括引入了偏向锁(Biased Locking)、轻量级锁(Lightweight Locking)的概念。接下来我们先说一下JDK1.6之前synchronized的原理。
对象的组成布局

在JDK1.6之前,在Java虚拟机中,Java对象的内存布局主要有对象头(Object Header)实例数据(Instance Data)对齐添补(Padding) 三个部分组成。

  • 对象头(Object Header)
    对象头主要包含了两部分信息:Mark Word(标记字段)和指向类元数据(Class Metadata)的指针。Mark Word 包含了一些重要的标记信息,好比对象是否被锁定、对象的哈希码、GC相关信息等。类元数据指针指向对象的类元数据,用于确定对象的类型信息、方法信息等。
  • 实例数据(Instance Data)
    实例数据是对象的成员变量和实例方法所占用的内存空间,它们按照声明的序次依次存储在对象的实例数据区域中。实例数据包括对象的所有非静态成员变量和非静态方法。
  • 添补(Padding)
    在JDK 1.6及之前的版本中,为了包管对象在内存中的存储地点是8字节的整数倍,可能会在对象的实例数据之后添加一些添补字节。这些添补字节的目标是对齐内存地点,提高内存访问效率。添补字节通常不包含任何实际数据,只是用于占位。

对象头

在JDK 1.6之前的Java HotSpot虚拟机中,对象头的基本组成依然包含Mark Word和类型指针(Klass Pointer),但其时对于锁的实现还没有引入偏向锁和轻量级锁的概念,因此对象头中的Mark Word在处理锁状态时比较简单,主要是用来存储锁的状态信息以及与垃圾收集相关的数据。在一个32位系统重对象头大小通常约为32位,而在64位系统中大小通常为64位。
对象头组成部分:

  • Mark Word(标记字)
    在早期版本的HotSpot虚拟机中,Mark Word主要存储的信息包括:


  • 对象的hashCode(在没有锁定时)。
  • 对象的分代年龄(用于垃圾接纳算法)。
  • 锁状态信息,如无锁、重量级锁状态(在使用synchronized关键字时)。
  • 对象的锁指针(Monitor地点,当对象被重量级锁锁定时,存储的是指向重量级锁(Monitor)的指针)。

对象头中的Mark Word是一个非固定的数据布局,它会根据对象的状态复用自己的存储空间,存储不同的数据。在Java HotSpot虚拟机中,Mark Word会随着步伐运行和对象状态的变化而存储不同的信息。其信息变化如下:

从存储信息的变化可以看出:

  • 对象头的最后两位存储了锁的标记位,01表示初始状态,即未加锁。此时,对象头内存储的是对象自身的哈希码。无锁和偏向锁的锁标记位都是01,只是在前面的1bit区分了这是无锁状态还是偏向锁状态。
  • 当进入偏向锁阶段时,对象头内的标记位变为01,并且存储当前持有锁的线程ID。这意味着只有第一个获取锁的线程才气继续持有锁,其他线程不能竞争同一把锁。
  • 在轻量级锁阶段,标记位变为00,对象头内存储的是指向线程栈中锁记录的指针。这种情况下,多个线程可以通过比较锁记录的地点与对象头内的指针地点来确定自己是否拥有锁。
其中轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增加的。重量级锁也就是通常说synchronized的对象锁,锁标识位为10,其中指针指向的是monitor对象(也称为管程或监视器锁)的起始地点。

  • 类型指针(Klass Pointer 或 Class Pointer)
    类型指针指向对象的类元数据(Class Metadata),即对象属于哪个类的类型信息,用于确定对象的方法表和字段布局等。在一个32位系统重大小通常约为32位,而在64位系统中大小通常为64位。
  • 数组长度(Array Length)(仅对数组对象适用):
    如果对象是一个数组,对象头中会额外包含一个字段来存储数组的长度。在一个32位系统中大小通常约为32位,而在64位系统中大小通常为64位。
监视器(Monitor)

在Java中,每个对象都与一个Monitor关联,Monitor是一种同步机制,负责管理线程对共享资源的访问权限。当一个Monitor被线程持偶然,对象便处于锁定状态。Java的synchronized关键字在JVM层面上通过MonitorEnter和MonitorExit指令实现方法同步和代码块同步。MonitorEnter实验获取对象的Monitor所有权(即获取对象锁),MonitorExit确保每个MonitorEnter操纵都有对应的开释操纵。
在HotSpot虚拟机中,Monitor详细由ObjectMonitor实现,其布局如下:
  1. ObjectMonitor() {
  2.     _header       = NULL;
  3.     _count        = 0; //锁计数器,表示重入次数,每当线程获取锁时加1,释放时减1。
  4.     _waiters      = 0, //等待线程总数,不一定在实际的ObjectMonitor中有直接体现,但在管理线程同步时是一个重要指标。
  5.     _recursions   = 0; //与_count类似,表示当前持有锁的线程对锁的重入次数。
  6.     _object       = NULL; // 通常指向关联的Java对象,即当前Monitor所保护的对象。
  7.     _owner        = NULL; // 持有ObjectMonitor对象的线程地址,即当前持有锁的线程。
  8.     _WaitSet      = NULL; //存储那些调用过`wait()`方法并等待被唤醒的线程队列。
  9.     _WaitSetLock  = 0 ; // 用于保护_WaitSet的锁。
  10.     _Responsible  = NULL ;
  11.     _succ         = NULL ;
  12.     _cxq          = NULL ; //阻塞在EntryList上的单向线程列表,可能用于表示自旋等待队列或轻量级锁的自旋链表。
  13.     FreeNext      = NULL ; // 在对象Monitor池中可能用于链接空闲的ObjectMonitor对象。
  14.     _EntryList    = NULL ; // 等待锁的线程队列,当线程请求锁但发现锁已被持有时,会被放置在此队列中等待。
  15.     _SpinFreq     = 0 ;
  16.     _SpinClock    = 0 ;
  17.     OwnerIsThread = 0 ; // 标志位,可能用于标识_owner是否指向一个真实的线程对象。
  18.   }
复制代码
其中最重要的就是_owner、_WaitSet、_EntryList和count几个字段,他们之间的转换关系:

  • _owner:
    当一个线程首次成功实验synchronized代码块或方法时,会实验获取对象的Monitor(即ObjectMonitor),并将自身设置为_owner。该线程现在拥有了对象的锁,可以独占访问受保护的资源。
  • _EntryList → _owner:
    当多个线程同时实验获取锁时,除第一个成功获取锁的线程外,其余线程会进入_EntryList列队等待。一旦_owner线程开释锁,_EntryList中的下一个线程将有时机获取锁并成为新的_owner。
  • _owner → _WaitSet:
    当_owner线程在持有锁的情况下调用wait()方法时,它会开释锁(即_owner置为NULL),并把自己从_owner变化为等待状态,然后将自己添加到_WaitSet中。这时,线程进入等待状态,暂停实验,等待其他线程通过notify()或notifyAll()唤醒。
  • _WaitSet → _EntryList:
    当其他线程调用notify()或notifyAll()方法时,会选择一个或全部在_WaitSet中的线程,将它们从_WaitSet移除,并重新加入到_EntryList中。这样,这些线程就有时机再次实验获取锁并成为新的_owner。
有上述转换关系我们可以发现,当多线程访问同步代码时:

  • 线程起首实验进入_EntryList竞争锁,成功获取Monitor后,将_owner设置为当火线程并将count递增。
  • 若线程调用wait()方法,会开释Monitor、清空_owner,并将线程移到_WaitSet中等待被唤醒。
  • 当线程实验完毕或调用notify()/notifyAll()唤醒等待线程后,会开释Monitor,使得其他线程有时机获取锁。
在Java对象的对象头(Mark Word)中,存储了与锁相关的状态信息,这使得恣意Java对象都能作为锁来使用,同时,notify/notifyAll/wait等方法正是基于Monitor锁对象来实现的,因此这些方法必须在synchronized代码块中调用。
我们查看上述同步代码块SynchronizedBlock的字节码文件:

从上述字节码中可以看到同步代码块的实现是由monitorenter 和monitorexit指令完成的,其中monitorenter指令所在的位置是同步代码块开始的位置,第一个monitorexit指令是用于正常结束同步代码块的指令,第二个monitorexit指令是用于异常结束时所实验的开释Monitor指令。
关于查看class文件的字节码文件,有两种方式:1、通过下令:  javap -verbose /class文件。2、IDEA中通过插件:jclasslib Bytecode viewer。
我们再看一下作用于同步方法的字节码:

我们可以看出同步方法上没有monitorenter 和 monitorexit 这两个指令了,而在查看该方法的class文件的布局信息时发现了Access flags后边的synchronized标识,该标识表明了该方法是一个同步方法。Java虚拟机通过该标识可以来辨别一个方法是否为同步方法,如果有该标识,线程将持有Monitor,在实验方法,最后开释Monitor。

总结

synchronized作用于同步代码块时的原理:
Java虚拟机使用monitorenter和monitorexit指令实现同步块的同步。monitorenter指令在进入同步代码块时实验,实验获取对象的Monitor(即锁),monitorexit指令在退出同步代码块时实验,开释Monitor。
而对于方法级别的同步的原理:
Java虚拟机通过在方法的访问标记(Access flags)中设置ACC_SYNCHRONIZED标记来实现方法同步。当一个方法被声明为synchronized时,编译器会在生成的字节码中插入monitorenter和monitorexit指令,确保在方法实验前后正确地获取和开释对象的Monitor。
本文已收录于我的个人博客:码农Academy的博客,专注分享Java技术干货,包括Java基础、Spring Boot、Spring Cloud、Mysql、Redis、Elasticsearch、中心件、架构计划、面试题、步伐员攻略等

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

科技颠覆者

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表