什么是自旋？字面意思是 "自我旋转" 。在 Java 中也就是循环的意思，比如 for 循环，while 循环等等。那自旋锁顾名思义就是「线程循环地去获取锁」。
从JDK6版本开始，HotSpot虚拟机开发团队就花费了大量的资源来实现各种的锁优化技术，前面介绍到的轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）就是其中的两种方式，而今天要讲的自旋锁（Adaptive Spinning）也是为了在线程之间更高效地共享数据及解决竞争问题，从而提高程序的执行效率。
Java中的锁是多线程编程中重要的同步机制。在并发环境下，锁的性能和效率对系统的性能和可伸缩性至关重要。Java的锁机制在不同的场景下会采用不同的锁升级策略，从最轻量级的偏向锁到最重量级的重量级锁。本博客将深入探讨Java锁的升级过程，解释每个阶段的原理和适用场景。
我们都知道 synchronized 关键字能实现线程安全，但是你知道这背后的原理是什么吗？今天我们就来讲一讲 synchronized 实现线程同步背后的原因，以及相关的锁优化策略吧。
上一篇介绍了乐观锁和悲观锁，它们的分类依据是线程间是否需要锁住资源，需要锁住就是悲观锁，不需要锁住就是乐观锁。
分享一个我自己总结的Java学习的系统知识点以及面试问题，目前已经开源，会一直完善下去，欢迎建议和指导欢迎Star： https://github.com/Snailclimb/Java-Guide
在读很多并发文章中，会提及各种各样锁如公平锁，乐观锁等等，这篇文章介绍各种锁的分类。介绍的内容如下：
Java中的分很多种类，按照场景的不同、特性的不同等分为了很多类，下面就来讲讲Java中锁的概念：
乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。
乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为 别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数 据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新）， 如果失败则要重复读-比较-写的操作。
自旋锁是并发编程实战里面一个关于锁优化的非常重要的一个概念，通常情况下会配合CAS原语来实现轻量级的同步操作。
自旋锁(spin lock)是一个典型的对临界资源的互斥手段，自旋锁是基于CAS原语的，所以它是轻量级的同步操作，它的名称来源于它的特性。自旋锁是指当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。由于自旋锁只不进行线程状态的改变（挂起线程），所以当线程竞争不激烈时，它的响应速度极快（因为避免了线程调度的上下文切换）。自旋锁适用于锁保护的临界区很小的情况，线程竞争不激烈的场景下。如果线程之间竞争激烈或者临界区的操作特别耗时，那么线程的自旋操作就会耗费大量的cpu资源，所以这种情况下性能就会下降明显。
在读很多并发文章中，会提及各种各样锁如公平锁，乐观锁等等，这篇文章介绍各种锁的分类，介绍的内容如下：
重量级锁？自旋锁？自适应自旋锁？轻量级锁？偏向锁？悲观锁？乐观锁？执行一个方法咋这么辛苦，到处都是锁。
Java在语言上支持了锁的特性，在很多常用类的实现中也使用了锁，对于Java开发者来说就可以很方便的使用这些锁及常用类。但是，随着锁的频繁使用及错用，随之而来的就是程序执行效率变低、应用变的缓慢。为了提高线程对共享数据访问的效率，HotSpot虚拟机从JDK1.5到JDK1.6做了重大改进，提供了很多锁优化技术，包括自旋锁、自适应自旋锁、锁消除、锁粗化、轻量级锁和偏向锁。
为了换取性能，JVM在内置锁上做了非常多的优化，膨胀式的锁分配策略就是其一。理解偏向锁、轻量级锁、重量级锁的要解决的基本问题，几种锁的分配和膨胀过程，有助于编写并优化基于锁的并发程序。
来到多线程的第十五篇，对前十四篇感兴趣的请点文末底部的上、下一篇标签。这篇来聊聊 JVM 对 synchronized 做了那些优化？
本文是对 synchronized 关键字使用、底层原理、JDK1.6之后的底层优化以及和ReenTrantLock对比做的总结。如果没有学过 synchronized 关键字使用的话，阅读起来可能比较费力。两篇比较基础的讲解 synchronized 关键字的文章：
由于需要限制不同的程序之间的访问能力，防止他们获取别的程序的内存数据，或者获取外围设备的数据，CPU 划分出两个权限等级：用户态和内核态。
记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronized是这么的神奇而又强大，那个时候我们赋予它一个名字“同步”，也成为了我们解决多线程情况的百试不爽的良药。但是，随着我们学习的进行我们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以至于我们认为它不是那么的高效而慢慢摒弃它。 诚然，随着Javs SE 1.6对synchronized进行的各种优化后，synchronized并不会显得那么重了。下面跟随LZ一起
记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized。对于当时的我们来说，synchronized是如此的神奇且强大。我们赋予它一个名字“同步”，也成为我们解决多线程情况的良药，百试不爽。但是，随着学习的深入，我们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以至于我们认为它不是那么的高效，并慢慢抛弃它。
记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronized是这么的神奇而又强大，那个时候我们赋予它一个名字“同步”，也成为了我们解决多线程情况的百试不爽的良药。但是，随着我们学习的进行我们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以至于我们认为它不是那么的高效而慢慢摒弃它。 诚然，随着Javs SE 1.6对synchronized进行的各种优化后，synchronized并不会显得那么重了。下面跟随LZ一起来探索synchronized的实现机制、Java是如何对它进行了优化、锁优化机制、锁的存储结构和升级过程；
记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronized是这么的神奇而又强大，那个时候我们赋予它一个名字“同步”，也成为了我们解决多线程情况的百试不爽的良药。但是，随着我们学习的进行我们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以至于我们认为它不是那么的高效而慢慢摒弃它。 诚然，随着Javs SE 1.6对synchronized进行的各种优化后，synchronized并不会显得那么重了。下面跟随LZ一
这三种锁指的是synchronized锁的状态，Java1.6之前是基于重量级锁，Java1.6之后对synchronized进行了优化，为了减少获取和释放锁带来的性能消耗，引入了偏向锁、轻量级锁以及锁的升级机制。锁升级的路径：无锁→偏向锁→轻量级锁→重量级锁。
java中如何实现可重入的自旋锁 📷 说明 1、是指试图获得锁的线程不会堵塞，而是通过循环获得锁。 2、优点：减少上下文切换的消耗。 缺点：循环消耗CPU。 实例 public class ReentrantSpinLock { private AtomicReference<Thread> owner = new AtomicReference<>(); // 可重入次数 private int count = 0; // 加锁 public voi
在多线程的软件世界里，对共享资源的争抢过程(Data Race)就是并发，而对共享资源数据进行访问保护的最直接办法就是引入锁！。
Java 中锁的种类包括偏向锁，自旋锁，轻量级锁，重量级锁。锁的使用方式先提供偏向锁，如果不满足的时候，升级为轻量级锁，再不满足，升级为重量级锁。自旋锁是一个过渡的锁状态，不是一种实际的锁类型。锁只能升级，不能降级。
从JDK1.6开始，JVM对锁进行了各种优化，目的就是为了在线程间更高效的共享数据和解决互斥同步的问题。从锁优化的话题开始，可以引申出很多考点面试题，比如锁优化的技术、各优化技术的细节、CAS实现原理、CAS的ABA问题及如何解决等，持续发散还会引发更多问题，例如逃逸分析等，可以看出技术点都是相关联的，需要不断积累和梳理。
2.1-volatile的应用(wall la tai l 还是 wall lei tai l)
乐观锁和悲观锁并不是一种真实存在的锁，而是一种设计思想，乐观锁和悲观锁对于理解后端多线程和数据库来说至关重要，那么本篇文章就来详细探讨一下这两种锁的概念以及实现方式。
乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为 别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数 据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新）， 如果失败则要重复读-比较-写的操作。 java 中的乐观锁基本都是通过 CAS 操作实现的，CAS 是一种更新的原子操作，比较当前值跟传入 值是否一样，一样则更新，否则失败。
关于线程安全的专有名词有一大堆。你们突然之间问我这个名词是什么意思，那个名词是什么意思我还真不一定能给你准确的回答。这还别说一门语言一堆名词。其实有些名词叫法不同，实际上就是一个意思。
可重入锁是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。 ReentrantLock和synchronized都是可重入锁。可重入锁的一个好处是可一定程度避免死锁。
锁作为并发共享数据，保证一致性的工具，在JAVA平台有多种实现(如 synchronized 和 ReentrantLock等等 ) 。这些已经写好提供的锁为我们开发提供了便利，但是锁的具体性质以及类型却很少被提及。本系列文章将分析JAVA下常见的锁名称以及特性，为大家答疑解惑。
接触过线程安全的同学想必都使用过synchronized这个关键字，在java同步代码快中，synchronized的使用方式无非有两个:
高效并发是JDK5升级到JDK6后一项重要的改进，HotSpot虚拟机开发团队在这个版本上花费了巨大的资源去实现各种锁优化。比如，自旋锁，自适应自旋锁，锁消除，锁膨胀，轻量级锁，偏向锁等。这些技术都是为了在线程之间更高效的共享数据及解决竞争问题。从而提高程序的运行效率。
何为同步？JVM规范规定JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用monitorenter和monitorexit指令实现，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明，但是方法的同步同样可以使用这两个指令来实现。monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处， JVM要保证每个monitorenter必须有对应的monitorexit与之配对。任何对
一切互斥操作的依赖是 自旋锁（spin_lock），互斥量（semaphore）等其他需要队列的实现均需要自选锁保证临界区互斥访问。
之前做过一个测试，反复执行过多次，发现结果是一样的: 1. 单线程下synchronized效率最高（当时感觉它的效率应该是最差才对）； 2. AtomicInteger效率最不稳定，不同并发情况下表现不一样：短时间低并发下，效率比synchronized高，有时甚至比LongAdder还高出一点，但是高并发下，性能还不如synchronized，不同情况下性能表现很不稳定； 3. LongAdder性能稳定，在各种并发情况下表现都不错，整体表现最好,短时间的低并发下比AtomicInteger性能差一点，长时间高并发下性能最高（可以让AtomicInteger下台了）；
java中有各种同步机制，尤其是JDK1.5以后引入Lock后，衍生出各种功能不一的锁，比如ReentrantLock、Semaphore、CountDownLatch等等。本文便从浅入深，聊聊这些锁背后的概念和机制。
博客：https://juejin.im/user/5c629a3051882562191755d8
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
