关于synchronized-reentrantlock-volatile学习总结1.0

# Synchronized

## synchronized 是什么

`synchronized`是 java 提供的**原子性内置锁**，实现基本的同步机制，**不支持超时，非公平**，**不可中断，不支持多条件**，基于 JVM 的 Monitor（监视锁）机制实现，**主要解决**的是多个线程之间的访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只有一个线程执行，以及保证：

- 原子性

- 可见性

- 有序性

> 监视器锁（Monitor）是 JVM 内置的锁机制，开发者无法直接操作 Monitor，只能通过 `synchronized` 间接使用它。Monitor 的获取与释放对开发者是不可见的，由 JVM 自动管理

`synchronized`还是**排它锁**，当一个线程获得锁之后，其他线程就必须等到该线程释放锁之后才能获得锁，由于java中的线程和操作系统原生线程一一对应，线程被阻塞或者唤醒的时候会从用户态转换为内核态，这种转换非常消耗性能。

## synchronized 的可重入性

`synchronized`是可重入的，每获取一次锁，计数器加一，释放锁时，计数器减一，直到计数器为 0，锁才会真正释放。

# ReentrantLock

`ReentrantLock`是 JUC（java.util.concurrent.locks）提供的一个可重入锁、可中断、公平锁/非公平锁任选的显式锁（Explicit Lock）

## ReentrantLock 锁模式

### 非公平锁（默认）

获取锁的时候会“插队”，性能高，吞吐量大

### 公平锁

FIFO，先来先获取锁，但是性能比非公平锁低

```java

ReentrantLock lock = new ReentrantLock(true); // true = 公平锁

```

## ReentrantLock的能力

`ReentrantLock`底层实现主要是依赖于抽象类`AbstractQueuedSynchronizer(AQS)`，该类提供了基本同步机制的框架，其中包含了队列，状态值等。

### 1、tryLock() – 尝试获得锁，不等待

```java

if (lock.tryLock()) {

try { ... } finally { lock.unlock(); }

} else {

System.out.println("获取锁失败");

}

```

作用：防止线程永久等待 → 适合高性能场景（比如秒杀系统）

### 2、tryLock(timeout) – 超时获取锁

```java

if (lock.tryLock(2, TimeUnit.SECONDS)) {

try { ... } finally { lock.unlock(); }

}

```

作用：避免长时间等待，适用于读写混用、高并发业务。

### 3、lockInterruptibly – 可中断获取锁

```java

try {

lock.lockInterruptibly();

try { ... } finally { lock.unlock(); }

} catch (InterruptedException e) {

System.out.println("线程被中断，放弃等待锁");

}

```

作用：在等待锁期间可取消任务，适用于死锁检测等场景。

### 4、多条件队列 – Condition

相比于`synchronized`只有一个`wait-set`，而`ReentrantLock`可以创建多个`Condition`

```java

Condition condition = lock.newCondition();

```

作用：实现更复杂的线程通信（比如生产者 / 消费者 多条件控制）。

# Synchronized VS. ReentrantLock

| 能力 | synchronized | ReentrantLock |

| -------------- | ------------------------------------ | ------------------------------------------ |

| 可重入 | ✔ | ✔ |

| 公平锁 | ✘ | ✔（可选） |

| 非阻塞尝试 | ✘ | tryLock() ✔ |

| 可中断获取锁 | ✘ | lockInterruptibly() ✔ |

| 超时获取锁 | ✘ | tryLock(timeout) ✔ |

| 条件队列 | 1 个 wait-set | 多个 Condition ✔ |

| 必须手动释放锁 | 自动 | 必须 unlock() |

| 使用场景 | 一般情况用Synchronized就行，比较简单 | 比较灵活，支持的功能比较多，在复杂情况下用 |

# volatile

## volatile 的作用

主要保证**变量的可见性**和**禁止指令重排优化**，但是不能保证原子性

### 1、可见性（Visibility）

多个线程读写共享变量，如果不加 volatile：

- 线程可能读取到 **旧值**（因为线程读的是工作内存副本）

- volatile 让线程每次读取都从 **主内存** 读

避免线程间由于缓存一致性问题导致的 “看见” 旧值的现象。

### 2、禁止指令重排序（ordering）

volatile 会插入**内存屏障**（Memory Barrier），例如：

- LoadLoad

- StoreStore

- StoreLoad（最强）

从而阻止 JVM 和 CPU 进行重排序

# Synchronized VS. volatile

volatile 只保证可见性 + 禁止重排；synchronized 保证原子性 + 可见性 + 有序性。

volatile 是“轻量级读写”；synchronized 是“重量级加锁”。

| 对比项 | **volatile** | **synchronized** |

| ----------------------------- | ---------------------------- | ------------------------------------ |

| **是否保证原子性** | ❌ 不保证 | ✔ 保证 |

| **可见性** | ✔ 保证 | ✔ 保证 |

| **是否禁止指令重排** | ✔ 禁止 | ✔ 禁止（通过内存屏障） |

| **是否会阻塞线程** | ❌ 不会阻塞 | ✔ 可能阻塞（等待锁） |

| **是否适用于复合操作（i++）** | ❌ 不适用 | ✔ 适用 |

| **性能** | ⭐ 非常快 | 🐢 慢（涉及锁竞争） |

| **底层实现** | 内存屏障 + volatile 写入协议 | 监视器锁（Monitorenter/monitorexit） |

| **是否可重入** | 不适用 | ✔ 可重入锁 |

| **是否能实现临界区保护** | ❌ 不行 | ✔ 可以 |

| **适用场景** | 状态标志、DCL 单例、配置刷新 | 多线程共享修改的临界区 |

The end….