java并发包中的锁机制底层实现主要有两种方式：1.synchronized关键字基于jvm的monitor机制和对象头中的mark word实现，并通过锁升级（偏向锁→轻量级锁→重量级锁）优化性能；2.java.util.concurrent.locks包中的锁基于abstractqueuedsynchronizer（aqs）实现，通过volatile state变量、cas操作和clh队列管理线程同步。synchronized在字节码层面依赖monitorenter/monitorexit指令控制锁的获取与释放，而aqs则通过子类重写tryacquire/tryrelease方法定义同步语义，并利用locksupport进行线程阻塞唤醒。除此之外，并发包中还包括atomic系列类（基于cas实现无锁操作）、countdownlatch（基于aqs实现计数等待）、semaphore（基于aqs实现资源许可控制）、reentrantreadwritelock（基于aqs拆分state实现读写分离）以及cyclicbarrier（基于reentrantlock和condition实现循环屏障）等重要同步工具，它们共同构成了java并发编程的核心支撑体系。
Java并发包中的锁机制，其底层实现原理主要围绕着两个核心点展开：一个是JVM层面基于对象头和操作系统互斥量实现的synchronized关键字，另一个则是java.util.concurrent.locks包中，以AbstractQueuedSynchronizer（AQS）为基础构建的各类锁和同步器。理解它们，关键在于把握JVM对线程状态的管理、操作系统原语的调用，以及如何通过CAS（Compare-And-Swap）操作来保证原子性和可见性。在我看来，这两种机制虽然路径不同，但都殊途同归地解决了并发场景下的资源竞争问题，只不过synchronized更像是JVM的“黑盒魔法”，而AQS则提供了一种更灵活、更可控的“积木搭建”方式。
解决方案
要深入剖析Java并发包中锁机制的底层实现，我们得从两个主要分支入手：synchronized关键字和J.U.C（java.util.concurrent）包下的锁。
synchronized关键字：synchronized是Java语言层面的同步原语，它能够作用于方法（实例方法和静态方法）或代码块。其底层实现依赖于JVM的Monitor（管程）机制。当一个线程尝试获取synchronized锁时，JVM会尝试在对象的对象头（Object Header）中进行操作。对象头中的Mark Word字段是其核心，它记录了对象的哈希码、GC信息以及锁状态。
立即进入“豆包AI人工智官网入口”；
立即学习“豆包AI人工智能在线问答入口”；
JVM为了优化synchronized的性能，引入了锁升级（Lock Escalation）机制：
偏向锁（Biased Locking）： 当一个线程首次访问同步块时，如果该对象没有被其他线程锁定，JVM会将对象的Mark Word设置为偏向模式，并记录下当前线程的ID。后续该线程再次进入同步块时，无需任何CAS操作，只需检查Mark Word中的线程ID是否是自己即可，性能开销极低。轻量级锁（Lightweight Locking）： 当有第二个线程尝试获取同一个synchronized锁时，偏向锁会升级为轻量级锁。此时，JVM会在当前线程的栈帧中创建一个Lock Record，并将对象的Mark Word复制到其中。然后，线程会尝试使用CAS操作将Mark Word指向Lock Record。如果CAS成功，则获取锁；如果失败，说明有其他线程也在尝试获取，轻量级锁就会膨胀为重量级锁。重量级锁（Heavyweight Locking）： 当多个线程竞争同一个锁，或者轻量级锁CAS失败时，锁会升级为重量级锁。此时，JVM会调用操作系统底层的互斥量（Mutex）来实现线程的阻塞和唤醒。被阻塞的线程会被挂起，不再消耗CPU资源，直到锁被释放并被唤醒。
synchronized的这种锁升级机制，旨在根据竞争程度动态调整锁的开销，从低竞争时的几乎无开销，到高竞争时的操作系统级同步。
J.U.C包下的锁（基于AQS）：java.util.concurrent.locks包提供了更灵活、功能更丰富的锁机制，如ReentrantLock、ReentrantReadWriteLock、Semaphore、CountDownLatch等。这些高级并发工具的基石是AbstractQueuedSynchronizer（AQS）。
AQS是一个抽象的队列式同步器，它提供了一个框架，用于实现依赖于先进先出（FIFO）等待队列的阻塞锁和同步器。其核心思想包括：
一个整型的state变量： 用于表示同步状态。例如，ReentrantLock中state为0表示无锁，大于0表示锁被持有，其值代表重入次数；Semaphore中state表示可用许可数；CountDownLatch中state表示计数器。一个CLH（Craig, Landin, and Hagersten）风格的FIFO等待队列： 当线程获取同步状态失败时，会被封装成一个Node节点，加入到等待队列的尾部。基于CAS操作： 所有对state变量的修改以及队列的操作（如添加/移除节点）都通过CAS来保证原子性。LockSupport.park()和LockSupport.unpark()： AQS使用这两个方法来阻塞和唤醒等待队列中的线程，而不是使用Object.wait()和Object.notify()，这使得线程的挂起和唤醒更加精准，避免了“假唤醒”等问题。
AQS的子类通过实现tryAcquire()、tryRelease()等抽象方法来定义具体的同步语义（独占模式或共享模式），而AQS本身则负责管理队列、线程阻塞/唤醒的通用逻辑。
Java中synchronized关键字是如何实现线程同步和锁升级的？
synchronized关键字在Java中实现线程同步，其本质是通过JVM层面的Monitor（监视器）机制来完成的。每当一个对象被创建时，它在内存中就带有一个对象头，这个对象头里就包含了Mark Word和Klass Pointer等信息。Mark Word，这个地方特别有意思，它就是synchronized实现锁的关键所在。它会动态地存储对象的哈希码、GC分代年龄，以及最重要的——锁标志位和指向锁记录的指针或线程ID。
当你用synchronized修饰一个代码块或方法时，JVM会在编译时生成monitorenter和monitorexit这两个字节码指令。
monitorenter指令尝试获取锁，如果成功，就将Mark Word中的锁标志位设置为已锁定状态。monitorexit指令则是在同步块执行完毕或抛出异常时释放锁。
而说到锁升级，这真是JVM为了性能做出的一个精妙设计。它不是一上来就用最重的锁，而是根据实际竞争情况，从轻到重逐步升级：
偏向锁（Biased Locking）： 想象一下，一个对象通常只会被一个线程反复访问。在这种情况下，每次都去CAS或者调用操作系统原语，那开销也太大了。所以，JVM会“偏向”第一个获取到这个锁的线程。当线程A第一次进入同步块时，JVM会把对象头里的Mark Word设置为偏向模式，并记录下线程A的ID。之后，只要还是线程A来访问这个同步块，它都不需要再做任何同步操作，直接就能进入。这几乎是零开销的。但如果另一个线程B也尝试获取这个锁，偏向锁就会被撤销。撤销过程需要等到全局安全点（Safepoint），然后暂停持有偏向锁的线程，将锁升级。
轻量级锁（Lightweight Locking）： 当偏向锁被撤销，或者一开始就有两个线程交替竞争（但不是激烈竞争）同一个锁时，锁就会升级为轻量级锁。此时，JVM不再直接调用操作系统，而是利用CAS操作。每个线程在自己的栈帧里会创建一个Lock Record，然后尝试用CAS把对象的Mark Word指向这个Lock Record。如果CAS成功，说明获取到了锁。如果失败，说明有其他线程也在尝试CAS，这时候就意味着竞争比较激烈了，轻量级锁会进一步膨胀。
重量级锁（Heavyweight Locking）： 当轻量级锁的CAS操作失败，或者多个线程持续激烈竞争时，锁会膨胀为重量级锁。这个时候，Mark Word会指向一个真正的操作系统级别的互斥量（Mutex）。那些没有抢到锁的线程会被阻塞（park），进入等待队列，不再消耗CPU资源。当持有锁的线程释放锁时，会唤醒（unpark）等待队列中的一个或多个线程去重新竞争。
这个锁升级的过程，是一个动态适应的过程，它让synchronized在不同并发场景下都能表现出较好的性能。但值得一提的是，一旦升级到重量级锁，就无法降级了，这通常是因为重量级锁的开销较大，且线程上下文切换的成本也高。
AbstractQueuedSynchronizer (AQS) 在J.U.C包中扮演了怎样的核心角色？
在我看来，AbstractQueuedSynchronizer（AQS）在Java并发包（J.U.C）里，简直就是“基石”般的存在，它定义了大部分高级并发工具的骨架和灵魂。可以说，没有AQS，J.U.C包就不会有今天的强大和灵活。
AQS本身并不是一个锁，而是一个用于构建锁和同步器的抽象框架。它把所有复杂的同步逻辑，比如线程的排队、阻塞、唤醒，以及同步状态的管理，都封装在自己内部。开发者只需要关注具体的同步语义，也就是如何获取和释放资源，而不用操心底层的线程调度细节。
AQS的核心构成包括：
一个volatile int state变量： 这是AQS的灵魂所在，它代表了同步状态。这个状态的具体含义完全由AQS的子类来定义。比如，ReentrantLock用它来表示锁的重入次数，Semaphore用它表示可用的许可数量，CountDownLatch用它表示需要等待的事件数量。volatile关键字确保了state变量在多线程间的可见性。一个FIFO的等待队列： 这是一个双向链表，用于存放那些未能成功获取同步状态而被阻塞的线程。每个线程被封装成一个Node节点，这个节点不仅包含线程本身，还包含线程的状态（比如是否需要被唤醒，是否是共享模式等）。当一个线程尝试获取同步状态失败时，它就会被包装成一个Node并加入到这个队列的尾部，然后被挂起。基于CAS的操作： AQS内部所有的对state变量的修改，以及对等待队列的添加、移除操作，都是通过CAS（Compare-And-Swap）原语来保证原子性的。这避免了使用传统的重量级锁，从而提高了并发效率。LockSupport.park()和LockSupport.unpark()： AQS使用这两个底层工具来精确地阻塞和唤醒等待队列中的线程。相比于Object.wait()和Object.notify()，park/unpark更加灵活，它不需要先获取对象的监视器锁，可以针对特定的线程进行操作，避免了死锁和虚假唤醒等问题。
AQS的工作流程大致是这样的：当一个线程调用AQS子类的acquire方法（如ReentrantLock.lock()）时：
它会尝试调用子类实现的tryAcquire方法去获取同步状态。如果tryAcquire成功，则表示获取到锁，方法返回。如果tryAcquire失败，线程就会被封装成一个Node，加入到AQS的等待队列中。接着，线程会被park（挂起），直到它在队列中排到合适的位置，或者被其他线程unpark。
当一个线程调用AQS子类的release方法（如ReentrantLock.unlock()）时：
它会尝试调用子类实现的tryRelease方法去释放同步状态。如果tryRelease成功，并且队列中有等待的线程，它会unpark队列头部的线程，使其有机会重新尝试获取同步状态。
正是因为AQS提供了这样一套通用且高效的同步机制，像ReentrantLock（独占锁）、Semaphore（计数信号量）、CountDownLatch（倒计时门闩）、CyclicBarrier（循环屏障，虽然它不是直接基于AQS，但其内部也使用了ReentrantLock和Condition来模拟AQS的排队机制）以及ReentrantReadWriteLock（读写锁）等，才能在它的基础上，通过简单地实现tryAcquire和tryRelease等抽象方法，就构建出功能各异但底层逻辑一致的并发工具。AQS的出现，极大地简化了并发编程中同步工具的开发难度。
除了synchronized和AQS，Java并发包中还有哪些重要的同步工具及其底层原理？
除了synchronized和AQS这两个核心支柱，Java并发包（J.U.C）中还有一系列重要的同步工具，它们有些是基于AQS构建的，有些则依赖于更底层的硬件原语或JVM特性。理解它们，能让我们对Java的并发世界有更全面的认知。
Atomic系列类（如AtomicInteger, AtomicLong, AtomicReference等）：
底层原理： 这些类并非基于传统的锁机制，而是利用了硬件级别的CAS（Compare-And-Swap）操作。CAS是一种无锁（Lock-Free）的乐观并发策略。它涉及到三个操作数：内存位置（V）、预期原值（A）和新值（B）。如果内存位置V的值与预期原值A相等，那么处理器就会把V更新为新值B；否则，什么也不做。这个操作是原子的。在Java中，CAS操作是通过sun.misc.Unsafe类暴露出来的本地方法实现的。Unsafe类提供了直接操作内存的能力，包括compareAndSwapInt、compareAndSwapLong等方法。Atomic类通过循环CAS（自旋）的方式来保证操作的原子性，避免了线程阻塞，在高并发低竞争的场景下，性能往往优于基于锁的方案。
CountDownLatch：
底层原理： 它是基于AQS实现的。内部的state变量表示需要等待的计数。当调用countDown()方法时，state会递减；当await()方法被调用时，如果state不为0，当前线程就会被阻塞并加入到AQS的等待队列中。只有当state减到0时，所有等待的线程才会被唤醒。它是一种“一次性”的同步工具，计数器一旦归零就不能重置。
Semaphore（信号量）：
底层原理： 同样是基于AQS实现的。其state变量表示可用的许可数量。线程通过acquire()方法获取许可，如果许可不足则被阻塞；通过release()方法释放许可。Semaphore可以用于控制对某个资源的并发访问数量，比如数据库连接池的连接数限制。它支持公平（FIFO）和非公平模式。
ReentrantReadWriteLock（可重入读写锁）：
底层原理： 也是基于AQS实现的，但其state变量的设计更为巧妙。AQS的state变量是一个int类型，ReentrantReadWriteLock将这个int拆分为两部分：高16位用于表示读锁的计数，低16位用于表示写锁的计数。读写互斥，读读共享： 写锁是独占的，任何时候只有一个线程可以持有写锁。读锁是共享的，多个线程可以同时持有读锁，但读锁和写锁是互斥的，即在有读锁存在时不能获取写锁，有写锁存在时不能获取读锁。这种设计大大提升了读多写少场景下的并发性能。
CyclicBarrier（循环屏障）：
底层原理： 与前几个AQS的直接子类不同，CyclicBarrier内部并没有直接继承AQS。它使用了ReentrantLock和Condition来实现同步。当达到指定数量的线程都调用了await()方法时，屏障就会被打开，所有等待的线程会被同时释放。它的特点是“循环”的，一旦屏障被打开，它可以被重置并再次使用。
这些工具各有侧重，共同构成了Java并发编程的强大工具箱。它们有的侧重于无锁的性能优化（Atomic类），有的侧重于资源访问控制（Semaphore），有的侧重于协调多个线程的步调（CountDownLatch, CyclicBarrier），还有的则在读写场景下提供了更细粒度的控制（ReentrantReadWriteLock）。理解它们各自的底层实现，特别是AQS如何作为通用框架支撑起大部分高级锁，以及CAS如何实现无锁原子操作，是掌握Java并发编程的关键。
以上就是Java并发包中锁机制的底层实现原理剖析的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/143374.html
微信扫一扫 
支付宝扫一扫 
