Java资料网推荐关于synchronized-reentrantlock-volatile学习总结1.0这篇文章给大家，欢迎收藏Java资料网享受知识的乐趣

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，先来先获取锁，但是性能比非公平锁低

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

ReentrantLock的能力

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

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

if (lock.tryLock()) {
    try { ... } finally { lock.unlock(); }
} else {
    System.out.println("获取锁失败");
}

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

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

if (lock.tryLock(2, TimeUnit.SECONDS)) {
    try { ... } finally { lock.unlock(); }
}

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

3、lockInterruptibly – 可中断获取锁

try {
    lock.lockInterruptibly();
    try { ... } finally { lock.unlock(); }
} catch (InterruptedException e) {
    System.out.println("线程被中断，放弃等待锁");
}

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

4、多条件队列 – Condition

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

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….

文章来源:https://www.cnblogs.com/Lantz12/p/19287731
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！