**Java 内置的锁主要包括基于对象监视器的 `synchronized` 锁、基于虚拟机层面的偏向锁/轻量级锁/重量级锁优化形态，以及并发包中由 JVM 原生支持的可重入互斥机制。**这些锁共同构成了 Java 语言在并发控制上的“内建能力”，它们不依赖外部库即可使用，并与 Java 内存模型紧密协作，保障线程安全与可见性。理解 Java 内置锁的类型、工作原理与适用场景，是进行高质量并发编程与性能优化的基础。

## 一、Java 内置锁的整体框架与设计背景
在 Java 并发体系中，“内置锁”并不是单一实现，而是一组由语言规范与虚拟机共同定义的同步机制。它们的设计目标并非单纯追求极致性能，而是在**易用性、正确性与运行时优化**之间取得平衡。Java 从最早版本开始就提供 `synchronized` 关键字，确保开发者在不理解底层并发细节的情况下，也能获得可靠的互斥与内存可见性保证。随着多核处理器的普及，HotSpot 虚拟机逐步在不改变语义的前提下，引入多种锁状态以降低无竞争或低竞争场景下的开销。

从信息架构角度看，Java 内置锁可分为**语言级语法支持**与**虚拟机级实现细节**两个层面。前者是开发者可直接使用的同步手段，后者则决定了这些锁在不同竞争程度下的实际成本。理解这一分层，有助于在性能分析与故障排查时，避免将“语义问题”与“实现问题”混为一谈。

## 二、synchronized：Java 最核心的内置锁
`synchronized` 是 Java 语言层面最具代表性的内置锁，它通过对象监视器（Monitor）实现互斥访问。无论是修饰实例方法、静态方法，还是代码块，本质上都要求线程在进入临界区前获取某个对象的监视器。**其最大特点在于语义清晰、使用简单，并与 Java 内存模型天然绑定**：进入同步块等同于获取锁，退出同步块等同于释放锁，伴随发生的是内存屏障语义。

从正确性角度看，`synchronized` 保证了**互斥性、可见性与有序性**。这意味着在绝大多数业务并发场景中，只要使用得当，就不需要额外考虑指令重排或缓存不一致问题。代价在于，若锁竞争激烈，线程可能发生阻塞与唤醒，带来上下文切换开销。因此，在高并发系统中，是否使用 `synchronized` 往往需要结合竞争强度与临界区大小综合评估。

## 三、对象锁与类锁：监视器的两种常见形态
在使用 `synchronized` 时，开发者常听到“对象锁”和“类锁”这两个概念。严格来说，它们并不是两种不同的锁实现，而是**监视器所绑定对象不同**所导致的行为差异。对象锁绑定在实例对象上，不同实例之间互不影响；类锁则绑定在 `Class` 对象上，整个类加载器范围内共享。

这种区分在设计并发策略时非常重要。例如，业务中若每个请求对应独立实例，对象锁能最大限度减少竞争；而对于全局共享资源，类锁可以提供更强的一致性约束。需要注意的是，**错误地扩大锁粒度（如不必要地使用类锁）是导致性能问题的常见原因**。因此，理解监视器绑定关系，是合理使用 Java 内置锁的前提。

## 四、可重入性：Java 内置锁的重要语义特征
Java 内置锁天然支持可重入性，即同一线程在已持有某个锁的情况下，可以再次获取该锁而不会发生死锁。这一特性由虚拟机在监视器中记录“持有线程”与“重入次数”来实现。**可重入性极大降低了并发编程的心智负担**，使得方法之间可以安全地相互调用，而无需开发者显式拆分同步逻辑。

在大型系统中，可重入锁的价值尤为突出。业务方法往往由多层调用组成，如果锁不可重入，就需要在架构层面避免嵌套调用，显著增加复杂度。Java 通过在语言层面内置可重入锁，为并发代码的模块化设计提供了重要支撑。这也是 `synchronized` 在长期演进中仍被广泛使用的关键原因之一。

## 五、偏向锁：为无竞争场景而生的优化
偏向锁是 HotSpot 虚拟机引入的一种锁优化策略，目标是**降低单线程或无竞争场景下的同步开销**。在这种状态下，锁会“偏向”第一个获取它的线程，后续该线程再次进入同步块时，几乎不需要任何原子指令操作。这使得 `synchronized` 在很多实际业务场景中，其成本接近于普通方法调用。

需要强调的是，偏向锁对开发者是透明的，属于虚拟机内部实现细节。当其他线程尝试竞争该锁时，偏向状态会被撤销并升级。虽然在 JDK 后续版本中，偏向锁的默认策略有所调整，但其设计思想仍然体现了 Java 内置锁**“以常见场景为优化目标”**的理念。理解偏向锁，有助于正确解读一些性能测试中 `synchronized` 看似“几乎没有成本”的现象。

## 六、轻量级锁与重量级锁：竞争升级的路径
当锁不再是完全无竞争状态时，虚拟机会将偏向锁升级为轻量级锁。轻量级锁通过 CAS 操作和自旋来避免线程阻塞，适用于短时间竞争的场景。**其核心思想是用 CPU 忙等换取避免上下文切换**，在多核环境下尤为有效。

如果竞争持续加剧，自旋失败，锁最终会膨胀为重量级锁，此时线程会被挂起并进入操作系统层面的阻塞队列。重量级锁的成本最高，但在高竞争、长临界区的场景下反而更加稳定。这种从偏向到轻量级再到重量级的升级路径，体现了 Java 内置锁在运行时根据实际负载动态调整策略的能力。

## 七、内置锁与 Java 内存模型的关系
Java 内置锁不仅是互斥工具，也是**内存可见性与有序性的重要保障机制**。根据 Java 内存模型规定，释放锁之前，线程对共享变量的写入必须刷新到主内存；获取同一把锁的线程，必须从主内存中读取最新值。这一“先行发生”关系，使得 `synchronized` 成为最可靠的并发语义构建块之一。

相比之下，单纯依赖 `volatile` 只能保证可见性和部分有序性，无法提供复合操作的原子性。因此，在需要同时满足**原子性与可见性**的场景中，Java 内置锁仍然具有不可替代的价值。从规范角度理解这一点，有助于避免错误的并发设计假设。

## 八、Java 内置锁的类型与特征对比
为了更直观地理解 Java 内置锁在不同层面的差异，下表从实现层级、竞争适用性与性能特征等方面进行对比：

| 锁形态 | 所在层级 | 适用竞争程度 | 主要特征 |
|---|---|---|---|
| synchronized（语义层） | 语言级 | 全部 | 简单可靠，自动释放，支持可重入 |
| 偏向锁 | JVM 实现 | 无竞争 | 几乎零开销，偏向单线程 |
| 轻量级锁 | JVM 实现 | 低竞争 | 自旋 + CAS，避免阻塞 |
| 重量级锁 | JVM 实现 | 高竞争 | 线程阻塞，稳定但成本高 |

通过该对比可以看出，**开发者面对的始终是统一的 `synchronized` 语义**，而性能差异主要由虚拟机在后台根据运行态动态决定。这也是 Java 内置锁设计的一大优势。

## 九、实践总结与未来演进趋势
综合来看，Java 内置锁通过 `synchronized` 这一统一入口，配合虚拟机内部的多级优化策略，构建了一套兼顾正确性与性能的并发基础设施。**在绝大多数业务系统中，合理使用内置锁即可满足需求**，并不一定需要引入复杂的并发工具。随着虚拟机与硬件架构的持续演进，内置锁的实现细节仍在不断调整，但其核心语义保持高度稳定。

展望未来，Java 内置锁可能会进一步与硬件事务内存、虚拟线程等新特性协同，以降低同步成本并提升可扩展性。但可以预见的是，**以清晰语义为中心、由运行时负责优化**的设计思想，仍将是 Java 并发模型的重要基石。

参考与资料来源  
- Oracle. *The Java Language Specification*, Java SE 17, 2021.  
- OpenJDK. *HotSpot Runtime Overview*, 2022.

Java内置主要有两种锁类型：对象锁和类锁。对象锁是每个对象自带的锁，使用synchronized关键字在实例方法或代码块上实现；类锁则是基于Class对象的锁，常见于static方法或static代码块。

Java的内置锁类型

我想了解Java语言内置提供了哪些锁机制以实现线程同步。

Java中有哪些类型的内置锁？

synchronized用于修饰方法或代码块，确保同一时间只有一个线程持有相应的锁，进入临界区执行，避免多个线程同时操作共享资源引发的数据不一致问题。

synchronized关键字的功能

Java内置锁是怎么通过synchronized关键字实现的？它如何保证线程安全？

synchronized关键字在Java锁机制中扮演何种角色？

当多个线程需要访问共享资源且必须保证操作的原子性或状态的一致性时，使用内置锁非常适合。常见场景包括多线程环境下对变量的安全修改、同步代码块保护关键业务逻辑等。

内置锁的应用场景

什么情况下需要使用Java内置锁？是否有一些典型的应用场景？

Java内置锁的使用场景有哪些？

PingCodeDocs

本文系统梳理了 Java 内置锁的类型与工作机制，围绕 synchronized 这一核心入口，解释了对象监视器、可重入性以及偏向锁、轻量级锁和重量级锁等虚拟机优化形态。文章强调 Java 内置锁在互斥性、可见性和有序性上的语言级保障，并通过对比分析说明不同锁状态在竞争程度下的性能差异。整体结论是，Java 内置锁通过稳定语义与运行时自适应优化，为并发编程提供了可靠而长期演进的基础。

java内置有哪些锁