Java并发:synchronized机制与wait/notify的深度解析

java并发:synchronized机制与wait/notify的深度解析

本文深入探讨Java并发编程中synchronized方法与synchronized块的使用,特别是涉及共享资源访问和wait()/notify()机制时的最佳实践。文章将分析使用不同锁对象可能导致的并发问题,强调确保内存同步和正确唤醒等待线程的关键原则,并提供避免常见陷阱的指导。

1. synchronized 方法与 synchronized 块基础

在Java中,synchronized关键字是实现线程同步的基本机制,它确保同一时刻只有一个线程可以执行被同步的代码块或方法。理解其工作原理对于编写正确的并发程序至关重要。

1.1 synchronized 方法

当一个方法被声明为 synchronized 时,它会锁定当前实例对象(this)。如果是静态 synchronized 方法,则会锁定该方法所属的 Class 对象。这意味着在任何给定时间,只有一个线程可以执行该对象的任何 synchronized 方法。

示例:

立即学习“Java免费学习笔记(深入)”;

class CircularBuffer {    private byte[] buffer;    private int size;    private int head = 0;    private int tail = 0;    private int availableObjects = 0;    public CircularBuffer(int capacity) {        this.size = capacity;        this.buffer = new byte[capacity];    }    synchronized void add(byte b) throws InterruptedException {        if (availableObjects == size) { // 这里的 if 存在风险,应为 while            wait(); // wait() 和 notifyAll() 默认作用于当前对象 (this)        }        buffer[tail] = b;        tail = (tail + 1) % size;        availableObjects++;        notifyAll();    }    synchronized byte remove() throws InterruptedException {        if (availableObjects == 0) { // 这里的 if 存在风险,应为 while            wait();        }        byte element = buffer[head];        head = (head + 1) % size;        availableObjects--;        notifyAll();        return element;    }}

在上述实现中,add 和 remove 方法都锁定了 CircularBuffer 实例本身。这意味着在任何给定时间,只有一个线程可以执行 add 或 remove 方法,从而保证了对 buffer、head、tail 和 availableObjects 等共享状态的原子性访问。

1.2 synchronized 块

synchronized (object) 语法允许我们指定一个任意对象作为锁。这提供了更细粒度的控制,可以只同步代码的特定部分,或者使用不同的锁对象来同步不同的资源。

示例(存在问题的设计):

TextCortex TextCortex

AI写作能手,在几秒钟内创建内容。

TextCortex 62 查看详情 TextCortex

class CircularBufferProblematic {    private final Object addLock = new Object();    private final Object removeLock = new Object();    private byte[] buffer;    private int size;    private int head = 0;    private int tail = 0;    private int availableObjects = 0; // 假设这里是 AtomicInteger 或普通 int    public CircularBufferProblematic(int capacity) {        this.size = capacity;        this.buffer = new byte[capacity];    }    void add(byte b) throws InterruptedException {        synchronized (addLock) { // 锁定 addLock            while (availableObjects == size) { // 使用 while 循环是正确的改进                addLock.wait();            }            buffer[tail] = b;            tail = (tail + 1) % size;            availableObjects++;        }        // 为什么这里需要第二个 synchronized 块?        synchronized (removeLock) { // 锁定 removeLock            removeLock.notifyAll();        }    }    byte remove() throws InterruptedException {        byte element;        synchronized (removeLock) { // 锁定 removeLock            while (availableObjects == 0) { // 使用 while 循环是正确的改进                removeLock.wait();            }            element = buffer[head];            head = (head + 1) % size;            availableObjects--;        }        // 为什么这里需要第二个 synchronized 块?        synchronized (addLock) { // 锁定 addLock            addLock.notifyAll();        }        return element;    }}

2. wait()/notify() 机制与锁对象

Object 类的 wait()、notify() 和 notifyAll() 方法是Java中实现线程间协作的关键。它们允许线程在特定条件不满足时释放锁并进入等待状态,并在条件满足时被其他线程唤醒。

核心原则:调用 wait()、notify() 或 notifyAll() 方法时,当前线程必须持有该方法所属对象的监视器(即锁)。如果不在相应的 synchronized 块中调用,会抛出 IllegalMonitorStateException。

这就是 CircularBufferProblematic 示例中额外 synchronized 块的根本原因:

在 add 方法中,removeLock.notifyAll() 必须在 synchronized (removeLock) 块中执行,因为它需要持有 removeLock 的监视器。在 remove 方法中,addLock.notifyAll() 必须在 synchronized (addLock) 块中执行,因为它需要持有 addLock 的监视器。

这种设计是为了确保 wait() 和 notify() 调用的原子性,并防止在没有正确持有锁的情况下操作等待队列。

3. 使用不同锁对象引发的并发问题

尽管使用不同的锁对象可以实现更细粒度的控制,但当这些锁对象保护的是相同的共享状态时,就会引入严重的并发问题。CircularBufferProblematic 示例就存在这样的缺陷:

add 方法在 synchronized (addLock) 块中修改 buffer、tail 和 availableObjects。remove 方法在 synchronized (removeLock) 块中读取 buffer、head 和 availableObjects。

问题分析:由于 addLock 和 removeLock 是两个独立的锁,一个线程可以持有 addLock 并修改 buffer,而另一个线程同时持有 removeLock 并读取 buffer。这可能导致:

数据不一致: 读者可能读取到部分更新或过时的数据。例如,add 线程更新了 buffer 中的一个元素并递增了 availableObjects,但 remove 线程在看到 availableObjects 变化之前就读取了 buffer,从而读取到 null 或旧值。内存可见性问题: synchronized 关键字除了提供互斥访问外,还保证了内存可见性。当一个线程释放锁时,它所做的所有写入操作都会被刷新到主内存;当一个线程获取锁时,它会从主内存中读取最新值。如果 add 和 remove 使用不同的锁,它们之间的内存同步就无法保证,一个线程对共享变量的修改可能对另一个线程不可见。

解决方案:当多个操作(如生产者和消费者)需要访问和修改同一组共享状态变量时,它们必须使用同一个锁对象来保护这些共享状态。这样可以确保任何时候只有一个线程能够修改或读取这些变量,从而保证数据的一致性和内存可见性。

改进示例(使用单一锁):

class CircularBufferCorrected {    private final Object lock = new Object(); // 单一锁对象    private byte[] buffer;    private int size;    private int head = 0;    private int tail = 0;    private int availableObjects = 0; // 可以是普通 int,因为有锁保护    public CircularBufferCorrected(int capacity) {        this.size = capacity;        this.buffer = new byte[capacity];    }    public void add(byte b) throws InterruptedException {        synchronized (lock) { // 锁定同一个对象            while (availableObjects == size) { // 使用 while 循环                lock.wait();            }            buffer[tail] = b;            tail = (tail + 1) % size;            availableObjects++;            lock.notifyAll(); // 唤醒所有等待的线程        }    }    public byte remove() throws InterruptedException {        byte element;        synchronized (lock) { // 锁定同一个对象            while (availableObjects == 0) { // 使用 while 循环                lock.wait();            }            element = buffer[head];            head = (head + 1) % size;            availableObjects--;            lock.notifyAll(); // 唤醒所有等待的线程            return element;        }    }}

在这个改进版本中,add 和 remove 方法都同步在同一个 lock 对象上。这确保了对 buffer、head、tail 和 availableObjects 的所有访问都是互斥的,并且保证了内存可见性。availableObjects 也不再需要是 AtomicInteger,因为其操作在 synchronized 块内已受保护。

4. wait() 条件检查:while 循环的重要性

在调用 wait() 方法时,必须将其放在 while 循环中检查条件,而不是 if 语句

以上就是Java并发:synchronized机制与wait/notify的深度解析的详细内容,更多请关注创想鸟其它相关文章!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 chuangxiangniao@163.com 举报,一经查实,本站将立刻删除。
发布者:程序猿,转转请注明出处:https://www.chuangxiangniao.com/p/967116.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2025年12月1日 19:22:41
下一篇 2025年12月1日 19:23:02

相关推荐

发表回复

登录后才能评论
关注微信