深入理解Java中的Synchronized关键字

📕我是廖志伟，一名Java开发工程师、Java领域优质创作者、CSDN博客专家、51CTO专家博主、阿里云专家博主、清华大学出版社签约作者、产品软文创造者、技术文章评审老师、问卷调查设计师、个人社区创始人、开源项目贡献者。🌎跑过十五公里、徒步爬过衡山、🔥有过三个月减肥20斤的经历、是个喜欢躺平的狠人。

📘拥有多年一线研发和团队管理经验，研究过主流框架的底层源码(Spring、SpringBoot、Spring MVC、SpringCould、Mybatis、Dubbo、Zookeeper)，消息中间件底层架构原理(RabbitMQ、RockerMQ、Kafka)、Redis缓存、MySQL关系型数据库、 ElasticSearch全文搜索、MongoDB非关系型数据库、Apache ShardingSphere分库分表读写分离、设计模式、领域驱动DDD、Kubernetes容器编排等。🎥有从0到1的高并发项目经验，利用弹性伸缩、负载均衡、报警任务、自启动脚本，最高压测过200台机器，有着丰富的项目调优经验。

希望各位读者大大多多支持用心写文章的博主，现在时代变了，信息爆炸，酒香也怕巷子深，博主真的需要大家的帮助才能在这片海洋中继续发光发热，所以，赶紧动动你的小手，点波关注❤️，点波赞👍，点波收藏⭐，甚至点波评论✍️，都是对博主最好的支持和鼓励！

• 💂 博客主页： 我是廖志伟
• 👉开源项目：java_wxid
• 🌥 哔哩哔哩：我是廖志伟
• 🎏个人社区：幕后大佬
• 🔖个人微信号： SeniorRD

📥博主的人生感悟和目标

• 🍋程序开发这条路不能停，停下来容易被淘汰掉，吃不了自律的苦，就要受平庸的罪，持续的能力才能带来持续的自信。我本是是一个很普通程序员，放在人堆里，除了与生俱来的盛世美颜，就剩180的大高个了，就是我这样的一个人，默默写博文也有好多年了。
• 📺有句老话说的好，牛逼之前都是傻逼式的坚持，希望自己可以通过大量的作品、时间的积累、个人魅力、运气、时机，可以打造属于自己的技术影响力。
• 💥内心起伏不定，我时而激动，时而沉思。我希望自己能成为一个综合性人才，具备技术、业务和管理方面的精湛技能。我想成为产品架构路线的总设计师，团队的指挥者，技术团队的中流砥柱，企业战略和资本规划的实战专家。
• 🎉这个目标的实现需要不懈的努力和持续的成长，但我必须努力追求。因为我知道，只有成为这样的人才，我才能在职业生涯中不断前进并为企业的发展带来真正的价值。在这个不断变化的时代，我必须随时准备好迎接挑战，不断学习和探索新的领域，才能不断地向前推进。我坚信，只要我不断努力，我一定会达到自己的目标。

📙经过多年在CSDN创作上千篇文章的经验积累，我已经拥有了不错的写作技巧。同时，我还与清华大学出版社签下了四本书籍的合约，并将陆续在明年出版。这些书籍包括了基础篇、进阶篇、架构篇的📌《Java项目实战—深入理解大型互联网企业通用技术》📌，以及📚《解密程序员的思维密码–沟通、演讲、思考的实践》📚。具体出版计划会根据实际情况进行调整，希望各位读者朋友能够多多支持！

🌾阅读前，快速浏览目录和章节概览可帮助了解文章结构、内容和作者的重点。了解自己希望从中获得什么样的知识或经验是非常重要的。建议在阅读时做笔记、思考问题、自我提问，以加深理解和吸收知识。阅读结束后，反思和总结所学内容，并尝试应用到现实中，有助于深化理解和应用知识。与朋友或同事分享所读内容，讨论细节并获得反馈，也有助于加深对知识的理解和吸收。

💡在这个美好的时刻，本人不再啰嗦废话，现在毫不拖延地进入文章所要讨论的主题。接下来，我将为大家呈现正文内容。

---

📝 定义

Synchronized能保证同一时刻被Synchronized修饰的代码最多只有1个线程执行。

synchronized如果加在方法上/对象上，那么，它作用的对象是非静态的，它取得的锁是对象锁；
synchronized如果作用的对象是一个静态方法或一个类，它取到的锁是类锁，这个类所有的对象用的是同一把锁。

📝 JDK6以前

Synchronized加锁是通过对象内部的监视器锁来实现的，监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的，操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要比较长的时间。

Sun程序员发现大部分程序大多数时间都不会发生多个线程同时访问竞态资源的情况，大多数对象的加锁和解锁都是在特定的线程中完成，出现线程竞争锁的情况概率比较低，比例非常高，所以引入了偏向锁和轻量级锁。

🔥 对象从无锁到偏向锁转化的过程

第一步，检测MarkWord是否为可偏向状态，是偏向锁是1，锁标识位是01。
第二步，如果是可偏向状态，测试线程ID是不是当前线程ID。如果是，就直接执行同步代码块。
第三步，如果测试线程ID不是当前线程ID，且当前对象的MarkWord标识为可偏向状态，这说明该对象已经被其他线程获取过锁，不能偏向于当前线程，就需要通过CAS操作竞争锁，竞争成功，就把MarkWord的线程ID替换为当前线程ID，同时执行同步代码块。
第四步，假设线程B来CAS失败了，需要将当前对象的偏向锁撤销，然后再进行锁竞争，这个时候JVM后台线程会启动偏向锁撤销过程。

偏向锁撤销触发通常有二种情况：当在对象头的Epoch字段计数到一定次数时会触发偏向锁撤销或者有多个线程尝试竞争该对象的锁，都失败了，也会触发偏向锁的撤销。

• 当有多个线程尝试获取同一个对象的锁时，通常只有一个线程能够获取成功，而其他线程则需要进入等待状态。当这个对象曾经被偏向锁优化过，且当前正在尝试获取锁的线程不是偏向线程时，如果该线程获取锁成功，JVM会撤销该对象的偏向锁状态，并重新获取锁。这个过程不需要等待其他线程都失败，只要有一个线程成功获取锁即可触发偏向锁的撤销。
• 在Java对象的内存布局中，有一个叫做对象头的部分，其中的Epoch字段是为了解决ABA问题而设置的。与此同时，当一个对象从偏向锁升级为轻量级锁或重量级锁时，对象的标记字（MarkWord）中保存的线程ID可能会发生变化。为了能够判断一个线程是否是因为ABA问题导致的线程变化，会将Epoch字段的值加一来表示变化次数。因此，在线程之间竞争锁时，可以通过比较Epoch字段的值是否相同来判断锁是否发生了变化。如果发生了变化，说明对象的状态已经被其他线程修改，需要重新竞争锁。与此同时，这个Epoch字段并没有直接关系到偏向锁撤销的过程。
• ABA问题指的是在多线程编程中，当多个线程对一个内存位置进行读取和修改时，可能会出现一种情况：最初的值被读取，然后被修改为新的值A，再次被修改为原来的值，也就是回到了最初的值B，但此时中间可能有其他线程对这个内存位置进行了修改，所以此时相对于最初的值B，这个内存位置已经发生了变化，无论是A还是其他值都与最初的B不同。在这种情况下，如果仅仅判断最终的值是否等于B，可能出现问题，需要使用其他机制来判断这个内存位置是否发生过变化。
• 偏向锁撤销不一定会挂起所有持有偏向锁的线程，只有在线程竞争锁时才会挂起线程。如果没有其他线程竞争锁，偏向锁撤销的过程只会涉及到当前对象的MarkWord，不会影响到其他线程。

撤销偏向锁的过程会挂起所有持有偏向锁的线程（例如线程A），并清除它们的MarkWord中的偏向锁信息（标记位、偏向线程ID、Epoch次数）。然后遍历偏向锁的对象所在的线程的栈，查找锁对象的锁记录，将那些已经被访问过的记录清除，以表明这些线程都不再持有该锁。

在撤销偏向锁的过程中，需要清除那些曾经持有该偏向锁对象的线程的锁记录。这是因为在偏向锁状态下，持有锁的线程会在对象头中记录一个标记位和持有该锁的线程ID。而在撤销偏向锁的过程中，需要清除这些锁记录，因为它们已经不再持有该锁，以便其他线程可以重新争夺锁的所有权。

第五步，完成偏向锁撤销后，持有偏向锁的线程不会被挂起，而是会继续执行同步代码块。线程A尝试获取该锁，如果获取成功，就可以继续执行同步代码块了，当线程A尝试获取该锁失败时，视情况继续进行自旋或者进行阻塞等待，导致进一步升级为轻量级锁或重量级锁。

安全点是jvm为了保证在垃圾回收的过程中引用关系不会发生变化，设置的安全状态，在这个状态上会暂停所有线程工作。一般有循环的末尾，方法临返回前，调用方法的call指令后，可能抛异常的位置，这些位置都可以算是安全点。

🔥 轻量级锁升级

轻量级锁升级过程是，在当前线程的栈帧中建立一个名为锁记录的空间，用于存储锁对象目前的MarkWord的拷贝，拷贝无锁状态对象头中的MarkWord复制到锁记录中。

• 这么做是因为在申请对象锁时，需要以该值作为CAS的比较条件。
• 同时在升级到重量级锁的时候，能通过这个比较，判定是否在持有锁的过程中，这个锁被其他线程申请过，如果被其他线程申请了，在释放锁的时候要唤醒被挂起的线程。
• 无锁的markword中可能存有hashCode，锁撤销之后必须恢复，这个markword要用于锁撤销后的还原。如果轻量级锁解锁为无锁状态，直接将拷贝的markword CAS修改到锁对象的markword里面就可以了。

拷贝成功后，虚拟机将使用CAS操作把对象中对象头MarkWord替换为指向锁记录的指针，然后把锁记录空间里的owner指针指向加锁的对象。

这个过程的目的是为了实现轻量级锁的互斥访问。CAS操作的作用是将对象头MarkWord指针指向锁记录空间，从而表示当前线程持有这个对象的锁。锁记录空间里的owner指针指向加锁的对象，是为了在释放锁的时候，能够知道哪个对象需要进行通知，从而唤醒被挂起等待锁的线程。同时，轻量级锁的升级过程也可以通过锁记录空间来判断是否在持有锁的过程中，这个锁被其他线程申请过，如果被其他线程申请了，在释放锁的时候要唤醒被挂起的线程，从而保证多个线程对同一个对象的访问是互斥的。

如果这个更新动作成功了，那么当前线程就拥有了该对象的锁，并且对象MarkWord的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态。

如果这个更新操作失败了，虚拟机首先会检查对象MarkWord中的Lock Word是否指向当前线程的栈帧。

Lock Word是一个对象头的一部分，用于实现Java对象的锁定。当一个线程获取了对象的锁时，Lock Word就会被设置为指向该线程的栈帧，表示这个对象被该线程持有了锁。其他线程如果要获取该对象的锁，会检查Lock Word中的锁标志是否为0，如果为0则表示该对象没有被锁定，可以获取锁。如果锁标志为1，则表示对象已经被锁定，其他线程必须等待锁的释放。

如果是，就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。如果不是说明多个线程竞争锁，进入自旋，若自旋结束时仍未获得锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，MarkWord中存储的就是指向重量级锁（互斥量）的指针，当前线程以及后面等待锁的线程也要进入阻塞状态。

当锁升级为轻量级锁之后，如果依然有新线程过来竞争锁，首先新线程会自旋尝试获取锁，尝试到一定次数（默认10次）依然没有拿到，锁就会升级成重量级锁。一般来说，同步代码块内的代码应该很快就执行结束，这时候线程B自旋一段时间是很容易拿到锁的，但是如果不巧，没拿到，自旋其实就是死循环，很耗CPU的，因此就直接转成重量级锁咯，这样就不用了线程一直自旋了。

🔥 自旋锁

自旋锁不是一种锁状态，而是一种策略。线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作。

引入自旋锁，当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。自旋等待不能替代阻塞，虽然它可以避免线程切换带来的开销，但是它占用了CPU处理器的时间。

自旋锁适用于锁保护的临界区很小的情况，临界区很小的话，锁占用的时间就很短。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好。

自旋的次数必须要有一个限度，如果自旋超过了定义的限度仍然没有获取到锁，就应该被挂起。但是这个限度不能固定，程序锁的状况是不可预估的，所以JDK1.6引入自适应的自旋锁，线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。如果对于某个锁，很少有自旋能够成功，那么在以后要或者这个锁的时候自旋的次数会减少，甚至省略掉自旋过程，以免浪费处理器资源。

通过–XX:+UseSpinning参数来开启自旋（JDK1.6之前默认关闭自旋）。
通过–XX:PreBlockSpin修改自旋次数，默认值是10次。

🔥 重量级锁

当一个线程在等锁时会不停的自旋（底层就是一个while循环），当自旋的线程达到CPU核数的1/2时，就会升级为重量级锁。

将锁标志为置为10，将MarkWord中指针指向重量级的monitor，阻塞所有没有获取到锁的线程。

Synchronized是通过对象内部的监视器锁（Monitor）来实现的，监视器锁本质又是依赖于底层的操作系统的MutexLock来实现的，操作系统实现线程之间的切换这就需要从用户态转换到核心态，状态之间的转换需要比较长的时间，这就是为什么Synchronized效率低的原因，这种依赖于操作系统MutexLock所实现的锁我们称之为“重量级锁”。

重量级锁的加锁-等待-撤销流程：
曾经获得过锁的线程，被唤醒后，优先得到锁。

举个例子，假设有A，B，C三个线程依次进入synchronized区，并且A已经膨胀成重量级锁。如果有一个线程 a 先进入 synchronized , 但是调用了 wait释放锁，这是线程 b 进入了 synchronized，b还在synchronized中执行，c线程又进来了。此时 a 在 wait_set ，b 不在任何队列，c 在 cxq_list ，假如 b 调用 notify唤醒线程，会把 a 插到 c 前面，也就是 b 退出synchronized的时候，会唤醒 a，a退出之后再唤醒 c。

重量级锁撤销之后是无锁状态，撤销锁之后会清除创建的monitor对象并修改markword，这个过程需要一段时间。Monitor对象是通过GC来清除的。GC清除掉monitor对象之后，就会撤销为无锁状态。

🔔如果您需要转载或者搬运这篇文章的话，非常欢迎您私信我哦~