监视器锁规则的核心作用是保障共享变量的可见性，即一个线程释放锁前的修改对后续获取同一锁的线程可见；它通过JMM赋予加解锁操作的内存语义实现：解锁触发写屏障确保刷新主存，加锁触发读屏障强制重载最新值，并依托锁的互斥性建立happens-before顺序，同时提供原子性、可见性与有序性三重保障。

监视器锁规则的核心作用，是让一个线程在释放锁前对共享变量的修改，对后续获取同一把锁的其他线程可见。它不靠“强制刷新缓存”这种底层操作来实现，而是通过 Java 内存模型（JMM）对 synchronized 块加解锁动作赋予的内存语义来保障。

解锁操作触发写屏障，确保修改落主存

当线程退出 synchronized 块（即执行解锁）时，JMM 要求：

• 该线程本地工作内存中所有被修改过的共享变量，必须刷新回主内存
• 这个刷新过程由 JVM 插入的“写屏障（store barrier）”保证，防止编译器或 CPU 把写操作重排序到解锁之后
• 例如：count++ 发生在 synchronized 块内，解锁那一刻，更新后的 count 值已稳定写入主内存

加锁操作触发读屏障，强制从主存加载最新值

当另一个线程进入 synchronized 块（即执行加锁）时，JMM 要求：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 该线程必须清空本地工作内存中对应变量的副本
• 后续对该变量的首次读取，会从主内存重新加载最新值（而非复用旧缓存）
• 这个加载过程由 JVM 插入的“读屏障（load barrier）”保证，防止读操作被重排序到加锁之前
• 所以，即使前一线程刚写完、后一线程立刻抢到锁，也能看到 count 的最新值

锁的排他性为可见性提供执行前提

单纯有屏障还不够——关键在于锁的互斥特性：

立即学习“Java免费学习笔记（深入）”；

• 同一时刻最多一个线程能持有该锁，因此“解锁 → 其他线程加锁”构成确定的先后顺序
• JMM 利用这个同步点建立 happens-before 边：前一线程的解锁操作 happens-before 后一线程的加锁操作
• 再结合程序顺序规则，解锁前的所有写操作自然 happens-before 加锁后的所有读操作
• 这就串起了“写 → 刷主存 → 清缓存 → 读主存”的完整可见链

和 volatile 的区别在哪

volatile 变量也提供可见性，但只针对单个变量，且不保证原子性；而监视器锁规则：

• 保护的是整个临界区内的一组操作和多个变量
• 同时提供原子性 + 可见性 + 有序性三重保障
• 适用于需要协调多个状态变更的场景（比如先改 status 再改 data）