Java 线程管理中的锁

发布时间:2023年12月21日

Monitor 概念

Java 对象头

image-20231215103905400

Mark Word:

image-20231215103926373

Monitor (锁)

Monitor 被翻译为监视器或管程

每个 Java 对象都可以关联一个 Monitor 对象,如果使用 synchronized 给对象上锁(重量级)之后,该对象头的Mark Word 中就被设置指向 Monitor 对象的指针

Monitor 结构:

image-20231215104209600

  • 刚开始 Monitor 中 Owner 为 null
  • 当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2,Monitor中只能有一个 Owner
  • 在 Thread-2 上锁的过程中,如果 Thread-3,Thread-4,Thread-5 也来执行 synchronized(obj),就会进入 EntryList BLOCKED
  • Thread-2 执行完同步代码块的内容,然后唤醒 EntryList 中等待的线程来竞争锁,竞争的时是非公平的
  • 图中 WaitSet 中的 Thread-0,Thread-1 是之前获得过锁,但条件不满足进入 WAITING 状态的线程(与wait-notify有关)

注意:

  • synchronized 必须是进入同一个对象的 monitor 才有上述的效果
  • 不加 synchronized 的对象不会关联监视器,不遵从以上规则

一个锁对象中的 MarkWord 会指向一个 Monitor 对象,不同的锁对象关联不同的 Monitor

image-20231215104847684

synchronized 原理

1. 轻量级锁

对象中轻量级锁的 MarkWord 结构:

image-20231215111040387

轻量级锁的使用场景:如果一个对象虽然有多线程要加锁,但加锁的时间是错开的(也就是没有竞争),那么可以使用轻量级锁来优化。

轻量级锁对使用者是透明的,即语法仍然是 synchronized

假设有两个方法同步块,利用同一个对象加锁:

static final Object obj = new Object();
public static void method1() {
    synchronized( obj ) {
		// 同步块 A
        method2();
    }
}
public static void method2() {
    synchronized( obj ) {
		// 同步块 B
    }
}

轻量级锁的加锁解锁流程:

  1. 创建锁记录(Lock Record,LR)对象,每个线程都的栈帧都会包含一个锁记录的结构,内部可以存储锁定对象的 Mark Word
image-20231215111405654

01 表示没有锁(或者偏向锁),从上面MarkWord结构可知

  1. 让锁记录中 Object reference 指向锁对象,并尝试用 cas 替换 Object 的 Mark Word,将 Mark Word 的值存入锁记录

    cas :取出 MarkWord值,然后尝试修改该值,写回时比较当前MarkWord值是否和当初取出的值相同,如果相同则将修改的值写入

image-20231215111653457
  1. 如果 cas 替换成功,对象头中存储了锁记录地址和状态 00 ,表示由该线程给对象加锁,这时图示如下
image-20231215111729648
  1. 如果 cas 失败,有两种情况
    • 如果是其它线程已经持有了该 Object 的轻量级锁,这时表明有竞争,进入锁膨胀过程
    • 如果是自己执行了 synchronized 锁重入,那么再添加一条 Lock Record 作为重入的计数
image-20231215111755058
  1. 当退出 synchronized 代码块(解锁时)如果有取值为 null 的锁记录,表示有重入,这时重置锁记录,表示重入计数减一
image-20231215111823128
  1. 当退出 synchronized 代码块(解锁时)锁记录的值不为 null,这时使用 cas 将 Mark Word 的值恢复给对象头
    • 成功,则解锁成功
    • 失败,说明轻量级锁进行了锁膨胀或已经升级为重量级锁,进入重量级锁解锁流程

2. 锁膨胀——轻量级锁膨胀为重量级锁

如果在尝试加轻量级锁的过程中,CAS 操作无法成功,这时一种情况就是有其它线程为此对象加上了轻量级锁(有竞争),这时需要进行锁膨胀,将轻量级锁变为重量级锁。

  • 当 Thread-1 进行轻量级加锁时,Thread-0 已经对该对象加了轻量级锁:
image-20231215112213291
  • 这时 Thread-1 加轻量级锁失败,进入锁膨胀流程

    • 即为 Object 对象申请 Monitor 锁,创建一个Monitor对象管理多线程,让 Object 指向重量级锁(Monitor对象)地址

    • 然后 Thread-1 自己进入 Monitor 的 EntryList BLOCKED

image-20231215112433566
  • 当 Thread-0 退出同步块解锁时,使用 cas 将 Mark Word 的值恢复给对象头,失败,因为现在MarkWord已经变为Monitor地址了。
    • 这时会进入重量级解锁流程,即按照 Monitor 地址找到 Monitor 对象,设置 Owner 为 null,唤醒 EntryList 中 BLOCKED 线程

3. 自旋优化

重量级锁竞争的时候,还可以使用自旋来进行优化,如果当前线程自旋成功(即这时候持锁线程已经退出了同步块,释放了锁),这时当前线程就可以避免阻塞。因为阻塞会发生上下文切换,避免阻塞,上下文切换也会避免,减少了上下文切换的次数,优化了性能

自旋重试成功的一种情况:(这里多核CPU下才有意义)

image-20231215114340941

自旋重试失败的一种情况:

image-20231215114608620

  • 自旋会占用 CPU 时间,单核 CPU 自旋就是浪费,多核 CPU 自旋才能发挥优势。
  • 在 Java 6 之后自旋锁是自适应的,比如对象刚刚的一次自旋操作成功过,那么认为这次自旋成功的可能性会高,就多自旋几次;反之,就少自旋甚至不自旋,总之,比较智能。
  • Java 7 之后不能控制是否开启自旋功能

4. 偏向锁

自JDK15起,偏向锁已被废弃,JDK20被移除,可以在JDK8中将其关闭以提高性能

偏向状态

轻量级锁在没有竞争时(就自己这个线程),每次重入仍然需要执行 CAS 操作。

Java 6 中引入了偏向锁来做进一步优化:只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头,之后发现这个线程 ID 是自己的就表示没有竞争,不用重新 CAS。以后只要不发生竞争,这个对象就归该线程所有

image-20231215142334025 image-20231215142351442

对象头格式:(延迟几秒后,MarkWord 最后三位是101)

image-20231215141305761

一个对象创建时:

  • 如果开启了偏向锁(默认开启),那么对象创建后,markword 值为 0x05 即最后 3 位为 101,这时它的 thread、epoch、age 都为 0
  • 偏向锁是默认是延迟的,不会在程序启动时立即生效,如果想避免延迟,可以加 VM 参数 -XX:BiasedLockingStartupDelay=0 来禁用延迟
  • 如果没有开启偏向锁,那么对象创建后,markword 值为 0x01 即最后 3 位为 001,这时它的 hashcode、age 都为 0,第一次用到 hashcode 时才会赋值

hashCode:正常状态对象一开始是没有 hashCode 的,第一次调用才生成;生成 hasCode 后,偏向锁就被禁止使用了,因为偏向锁无法存下 hashCode ,偏向锁被撤销了

偏向锁撤销的情况
  1. 撤销 - 调用对象 hashCode

    • 调用了对象的 hashCode,但偏向锁的对象 MarkWord 中存储的是线程 id,如果调用 hashCode 会导致偏向锁被撤销

    • 轻量级锁会在锁记录中记录 hashCode

    • 重量级锁会在 Monitor 中记录 hashCode

  2. 撤销 - 其它线程使用对象

    当有其它线程使用偏向锁对象时,会将偏向锁升级为轻量级锁

    image-20231215143758505
  3. 调用 wait/notify:只有重量级锁才有 wait/notify操作,会被升级为重量级锁

批量重偏向

如果对象虽然被多个线程访问,但没有竞争(线程交替访问锁对象),这时有一个原本偏向 T1 的偏向锁,T2 在访问T1的偏向锁时会将偏向锁撤销,升级为轻量级锁。随后轻量级锁被释放,再访问锁对象时,又会产生一个偏向 T1 的偏向锁,反复多次这种流程会耗费性能

所以希望在偏向了线程 T1 的对象仍有机会重新偏向 T2,重偏向会重置对象的 Thread ID

当撤销偏向锁(加锁,解锁次数)阈值超过 20 次后,jvm 会这样觉得,我是不是偏向错了呢,于是会在给这些对象加锁时重新偏向至加锁线程

批量撤销

当撤销偏向锁阈值超过 40 次后,jvm 会这样觉得,自己确实偏向错了,根本就不该偏向。于是整个类的所有对象都会变为不可偏向的,新建的对象也是不可偏向的

5. 锁消除

JIT 即时编译器,会优化代码,把不会被共享的锁对象的同步代码块中的加锁操作消除

-XX:-EliminateLocks :vm option 指令,禁止锁消除优化

锁粗化:对相同对象多次加锁,导致线程发生多次重入,可以使用锁粗化方式来优化,这不同于之前讲的细分锁的粒度。

wait notify 原理

image-20231215150745022

  • Owner 线程发现条件不满足,调用 wait 方法,即可进入 WaitSet 变为 WAITING 状态
  • BLOCKED 和 WAITING 的线程都处于阻塞状态,不占用 CPU 时间片
  • BLOCKED 线程会在 Owner 线程释放锁时唤醒
  • WAITING 线程会在 Owner 线程调用 notify 或 notifyAll 时唤醒,但唤醒后并不意味者立刻获得锁,仍需进入EntryList 重新竞争

waiting 状态的线程是获得锁后又放弃锁进入的状态,而 blocked 状态是还没获得锁的,他俩都是阻塞状态

API 介绍

  • obj.wait() 让进入 object 监视器的线程到 waitSet 等待
  • obj.notify() 在 object 上正在 waitSet 等待的线程中挑一个唤醒
  • obj.notifyAll() 让 object 上正在 waitSet 等待的线程全部唤醒

以上方法的调用必须是先获得锁(成为 Owner以后);测试:

@Slf4j(topic = "c.d4_wait_notify")
public class d4_wait_notify {
    final static Object obj = new Object();
    public static void main(String[] args) throws InterruptedException {
        new Thread(() -> {
            synchronized (obj) {
                log.debug("执行....");
                try {
                    obj.wait(); // 让线程在obj上一直等待下去
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                log.debug("其它代码....");
            }
        }, "t1").start();
        new Thread(() -> {
            synchronized (obj) {
                log.debug("执行....");
                try {
                    obj.wait(); // 让线程在obj上一直等待下去
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                log.debug("其它代码....");
            }
        }, "t2").start();
        // 主线程两秒后执行
        Thread.sleep(2000);
        log.debug("唤醒 obj 上其它线程");
        synchronized (obj) {
            obj.notify(); // 唤醒obj上一个线程
            // obj.notifyAll(); // 唤醒obj上所有等待线程
        }
    }
}	

结果:

15:18:02 [t1] c.d4_wait_notify - 执行....
15:18:02 [t2] c.d4_wait_notify - 执行....
15:18:04 [main] c.d4_wait_notify - 唤醒 obj 上其它线程
15:18:04 [t1] c.d4_wait_notify - 其它代码....

wait() 方法会释放对象的锁,进入 WaitSet 等待区,从而让其他线程就机会获取对象的锁。无限制等待,直到 notify 为止
wait(long n) 有时限的等待, 到 n 毫秒后结束等待,或是被 notify

wait notify 的正确使用方式

sleep(long n)wait(long n) 的区别

  1. sleep 是 Thread 方法,而 wait 是 Object 的方法
  2. sleep 不需要强制和 synchronized 配合使用,但 wait 需要和 synchronized 一起用
  3. sleep 在睡眠的同时,不会释放对象锁的,其他线程想用锁只能在EntryList里阻塞等待;但 wait 在等待的时候会释放对象锁,当前线程会进入 WaitList 等待,其他 EntryList里等待的线程会被唤醒一个获得释放的锁
  4. 它们状态都是 TIMED_WAITING

当有多个线程进入 waitList ,我们要选择其中一个唤醒,可以为每个线程设置一个标志 flag,然后唤醒所有线程;唤醒后,每个线程检查自己的 flag条件,如果 flag 不满足,则一直 wait 等待:

synchronized(lock) {
    while(条件不成立) {
    	lock.wait();
    }
	// 干活
}

//另一个线程
synchronized(lock) {
	lock.notifyAll();
}

同步模式之保护性暂停

1. 定义

即 Guarded Suspension,用在一个线程等待另一个线程的执行结果

要点:

  • 有一个结果需要从一个线程传递到另一个线程,让他们关联同一个 GuardedObject
  • 如果有结果不断从一个线程到另一个线程那么可以使用消息队列(见生产者/消费者)
  • JDK 中,join 的实现、Future 的实现,采用的就是此模式
  • 因为要等待另一方的结果,因此归类到同步模式
image-20231215154553879

2. 实现:

@Slf4j(topic = "c.d6_GuardedObject")
public class d6_GuardedObject {
    private Object response;
    private final Object lock = new Object();
    public Object get() {
        synchronized (lock) {
            // 条件不满足则等待
            while (response == null) {
                log.debug("等待 response ");
                try {
                    lock.wait();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            return response;
        }
    }
    public void complete(Object response) {
        synchronized (lock) {
            // 条件满足,通知等待线程
            this.response = response;
            lock.notifyAll();
        }
    }

    public static void main(String[] args) {
        d6_GuardedObject guardedObject = new d6_GuardedObject();
        new Thread(()->{
            Object myResponse = guardedObject.get();
            log.debug("myResponse: {}", myResponse);
        }, "t1").start();

        new Thread(()->{
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            guardedObject.complete("等待结束...");
        }, "t2").start();
    }
}
15:55:48 [t1] c.d6_GuardedObject - 等待 response 
15:55:49 [t1] c.d6_GuardedObject - myResponse: 等待结束...

3. 带有时间限制的实现:

@Slf4j(topic = "c.d7_CuardedObjectV2")
public class d7_CuardedObjectV2 {
    private Object response;
    private final Object lock = new Object();

    public Object get(long millis) {
        synchronized (lock) {
            // 1) 记录最初时间
            long begin = System.currentTimeMillis();
            // 2) 已经经历的时间
            long timePassed = 0;
            while (response == null) {
                // 4) 假设 millis 是 1000,结果在 400 时唤醒了,那么还有 600 要等
                long waitTime = millis - timePassed;
                log.debug("waitTime: {}", waitTime);
                if (waitTime <= 0) {
                    log.debug("break...");
                    break;
                }
                try {
                    lock.wait(waitTime);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                // 3) 如果提前被唤醒,这时已经经历的时间假设为 400
                timePassed = System.currentTimeMillis() - begin;
                log.debug("timePassed: {}, object is null {}",
                        timePassed, response == null);
            }
            return response;
        }
    }
    public void complete(Object response) {
        synchronized (lock) {
            // 条件满足,通知等待线程
            this.response = response;
            log.debug("notify...");
            lock.notifyAll();
        }
    }

    public static void main(String[] args) {
        d7_CuardedObjectV2 v2 = new d7_CuardedObjectV2();
        new Thread(() -> {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            v2.complete(null);
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            v2.complete(Arrays.asList("a", "b", "c"));
        }).start();

        Object response = v2.get(2500);
        if (response != null) {
            log.debug("get response: [{}] lines", ((List<String>) response).size());
        } else {
            log.debug("can't get response");
        }
    }
}
16:45:02 [main] c.d7_CuardedObjectV2 - waitTime: 2500
16:45:03 [Thread-0] c.d7_CuardedObjectV2 - notify...
16:45:03 [main] c.d7_CuardedObjectV2 - timePassed: 1012, object is null true
16:45:03 [main] c.d7_CuardedObjectV2 - waitTime: 1488
16:45:04 [Thread-0] c.d7_CuardedObjectV2 - notify...
16:45:04 [main] c.d7_CuardedObjectV2 - timePassed: 2014, object is null false
16:45:04 [main] c.d7_CuardedObjectV2 - get response: [3] lines

Join 原理

是调用者轮询检查线程 alive 状态

t1.join();
// 等价于下面的代码
synchronized (t1) {
    // 调用者线程进入 t1 的 waitSet 等待, 直到 t1 运行结束
    while (t1.isAlive()) {
        t1.wait(0);
    }
}

join 源码:其实也是用wait实现的带有时间限制的保护性暂停

public final void join(long millis) throws InterruptedException {
    // ... millis 非法异常判断
    synchronized (this) {
        if (millis > 0) {
            if (isAlive()) {
                final long startTime = System.nanoTime(); // 记录最初时间
                long delay = millis;
                do {
                    wait(delay);
                } while (isAlive() && (delay = millis -
                         NANOSECONDS.toMillis(System.nanoTime() - startTime)) > 0);
                // passTime = System.nanoTime() - startTime : 获取已经经历过的时间
                // delay = millis - passTime :更新剩余该等待的时间
            }
        } else {
            while (isAlive()) {
                wait(0);
            }
        }
    }
}

Park & Unpark

它们是 LockSupport 类中的方法

// 暂停当前线程
LockSupport.park();
// 恢复某个线程的运行
LockSupport.unpark(暂停线程对象)

特点

与 Object 的 wait & notify 相比

  • wait,notify 和 notifyAll 必须配合 Object Monitor 一起使用,而 park,unpark 不必
  • park & unpark 是以指定线程为单位来【阻塞】和【唤醒】线程,而 notify 只能随机唤醒一个等待线程,notifyAll是唤醒所有等待线程,就不那么【精确】
  • park & unpark 可以先 unpark,而 wait & notify 不能先 notify

原理

每个线程都有自己的一个 Parker 对象,由三部分组成 _counter , _cond 和 _mutex 打个比喻

  • 线程就像一个旅人,Parker 就像他随身携带的背包,条件变量就好比背包中的帐篷。_counter 就好比背包中的备用干粮(0 为耗尽,1 为充足)

  • 调用 park 就是要看需不需要停下来歇息

    • 如果备用干粮耗尽,那么钻进帐篷歇息

    • 如果备用干粮充足,那么不需停留,继续前进

  • 调用 unpark,就好比令干粮充足

    • 如果这时线程还在帐篷,就唤醒让他继续前进
    • 如果这时线程还在运行,那么下次他调用 park 时,仅是消耗掉备用干粮,不需停留继续前进
      • 因为背包空间有限,多次调用 unpark 仅会补充一份备用干粮

调用 park

  1. 当前线程调用 Unsafe.park() 方法
  2. 检查 _counter ,本情况为 0,这时,获得 _mutex 互斥锁
  3. 线程进入 _cond 条件变量阻塞
  4. 设置 _counter = 0
image-20231215171913892

调用 unpark:

  1. 调用 Unsafe.unpark(Thread_0) 方法,设置 _counter 为 1
  2. 唤醒 _cond 条件变量中的 Thread_0
  3. Thread_0 恢复运行
  4. 设置 _counter 为 0
image-20231215172124724

先调用 unpark 再调用 park:

  1. 调用 Unsafe.unpark(Thread_0) 方法,设置 _counter 为 1
  2. 唤醒 _cond 条件变量中的 Thread_0
  3. Thread_0 恢复运行
  4. 设置 _counter 为 0
image-20231215172420879

线程状态转换

image-20231215172745564

假设有线程 Thread t

NEW --> RUNNABLE

情况 1 NEW --> RUNNABLE

当调用 t.start() 方法时,由 NEW --> RUNNABLE

RUNNABLE <–> WAITING:-> wait(), join(), park()

情况 2 RUNNABLE <–> WAITING

t 线程用 synchronized(obj) 获取了对象锁后

  • 调用 obj.wait() 方法时,t 线程从 RUNNABLE --> WAITING

  • 调用 obj.notify() , obj.notifyAll() , t.interrupt() 时

    • 竞争锁成功,t 线程从 WAITING --> RUNNABLE

    • 竞争锁失败,t 线程从 WAITING --> BLOCKED

情况 3 RUNNABLE <–> WAITING

  • 当前线程调用 t.join() 方法时,当前线程从 RUNNABLE --> WAITING
    • 注意是当前线程在t 线程对象的监视器上等待
  • t 线程运行结束,或调用了当前线程的 interrupt() 时,当前线程从 WAITING --> RUNNABLE

情况 4 RUNNABLE <–> WAITING

  • 当前线程调用 LockSupport.park() 方法会让当前线程从 RUNNABLE --> WAITING
  • 调用 LockSupport.unpark(目标线程) 或调用了线程 的 interrupt() ,会让目标线程从 WAITING -->RUNNABLE

RUNNABLE <–> TIMED_WAITING:-> wait(n), join(n), sleep(n)

情况 5 RUNNABLE <–> TIMED_WAITING

t 线程用 synchronized(obj) 获取了对象锁后

  • 调用 obj.wait(long n) 方法时,t 线程从 RUNNABLE --> TIMED_WAITING
  • t 线程等待时间超过了 n 毫秒,或调用 obj.notify() , obj.notifyAll() , t.interrupt() 时
    • 竞争锁成功,t 线程从 TIMED_WAITING --> RUNNABLE
    • 竞争锁失败,t 线程从 TIMED_WAITING --> BLOCKED

情况 6 RUNNABLE <–> TIMED_WAITING

  • 当前线程调用 t.join(long n) 方法时,当前线程从 RUNNABLE --> TIMED_WAITING
    • 注意是当前线程在t 线程对象的监视器上等待
  • 当前线程等待时间超过了 n 毫秒,或t 线程运行结束,或调用了当前线程的 interrupt() 时,当前线程从 TIMED_WAITING --> RUNNABLE

情况 7 RUNNABLE <–> TIMED_WAITING

  • 当前线程调用 Thread.sleep(long n) ,当前线程从 RUNNABLE --> TIMED_WAITING
  • 当前线程等待时间超过了 n 毫秒,当前线程从 TIMED_WAITING --> RUNNABLE

情况 8 RUNNABLE <–> TIMED_WAITING

  • 当前线程调用 LockSupport.parkNanos(long nanos) 或 LockSupport.parkUntil(long millis) 时,当前线程从 RUNNABLE --> TIMED_WAITING
  • 调用 LockSupport.unpark(目标线程) 或调用了线程 的 interrupt() ,或是等待超时,会让目标线程从TIMED_WAITING–> RUNNABLE

RUNNABLE <–> BLOCKED

情况 9 RUNNABLE <–> BLOCKED

t 线程用 synchronized(obj) 获取了对象锁时如果竞争失败,从 RUNNABLE --> BLOCKED

  • 持 obj 锁线程的同步代码块执行完毕,会唤醒该对象上所有 BLOCKED 的线程重新竞争,如果其中 t 线程竞争成功,从 BLOCKED --> RUNNABLE ,其它失败的线程仍然 BLOCKED

RUNNABLE <–> TERMINATED

情况 10 RUNNABLE <–> TERMINATED

当前线程所有代码运行完毕,进入TERMINATED

活跃性

死锁

有这样的情况:一个线程需要同时获取多把锁,这时就容易发生死锁
t1 线程 获得 A对象 锁,接下来想获取 B对象的锁 t2 线程 获得 B对象 锁

定位死锁

检测死锁可以使用 jconsole工具,或者使用 jps 定位进程 id,再用 jstack 定位死锁:

image-20231215190751265

jstack定位死锁:

t1 等待的锁对象被 t2 锁住了;t1锁住的对象被 t2等待

image-20231215191259272

stack也会提示找到的死锁:

image-20231215191420513

  • 避免死锁要注意加锁顺序
  • 另外如果由于某个线程进入了死循环,导致其它线程一直等待,对于这种情况 linux 下可以通过 top 先定位到 CPU 占用高的 Java 进程,再利用 top -Hp 进程id 来定位是哪个线程,最后再用 jstack 排查

活锁

活锁出现在两个线程互相改变对方的结束条件,最后谁也无法结束,例如:

死锁是无法继续运行下去,活锁是一直运行下去

import lombok.extern.slf4j.Slf4j;

@Slf4j(topic = "c.d9_TestLiveLock")
public class d9_TestLiveLock {
    static volatile int count = 10;
    static final Object lock = new Object();
    public static void main(String[] args) {
        new Thread(() -> {
            // 期望减到 0 退出循环
            while (count > 0) {
                try {
                    Thread.sleep(200);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                count--;
                log.debug("count: {}", count);
            }
        }, "t1").start();
        new Thread(() -> {
            // 期望超过 20 退出循环
            while (count < 20) {
                try {
                    Thread.sleep(200);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                count++;
                log.debug("count: {}", count);
            }
        }, "t2").start();
    }
}

饥饿

很多教程中把饥饿定义为,一个线程由于优先级太低,始终得不到 CPU 调度执行,也不能够结束,饥饿的情况不易演示,讲读写锁时会涉及饥饿问题

的一个线程饥饿的例子,可以使用顺序加锁的方式解决之前的死锁问题

线程1锁住了A,线程2锁住了B,死锁发生:

image-20231215192940761

顺序加锁来避免死锁的解决方案:

必须先获得锁对象A才能获得锁对象B,这样就不会出现,线程2在获取A的时候就会阻塞而一直等待线程1释放

image-20231215193057445

ReentrantLock(可重入锁)

相对于 synchronized 它具备如下特点

  • 可中断
  • 可以设置超时时间
  • 可以设置为公平锁(避免饥饿)
  • 支持多个条件变量

与 synchronized 一样,都支持可重入

基本语法

// 获取锁
reentrantLock.lock();
try {
	// 临界区
} finally {
	// 释放锁
	reentrantLock.unlock();
}

可重入

可重入是指同一个线程如果首次获得了这把锁,那么因为它是这把锁的拥有者,因此有权利再次获取这把锁

如果是不可重入锁,那么第二次获得锁时,自己也会被锁挡住

对一个锁对象反复加锁的示例:

@Slf4j(topic = "c.d10_ReentrantLock")
public class d10_ReentrantLock {
    private static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) {
        lock.lock();
        try {
            log.debug("enter main");
            method1();
        }finally {
            lock.unlock();
        }
    }

    public static void method1(){
        lock.lock();
        try {
            log.debug("enter method1");
            method2();
        }finally {
            lock.unlock();
        }
    }
    public static void method2(){
        lock.lock();
        try {
            log.debug("enter method2");
        }finally {
            lock.unlock();
        }
    }
}

输出:

19:45:30 [main] c.d10_ReentrantLock - enter main
19:45:30 [main] c.d10_ReentrantLock - enter method1
19:45:30 [main] c.d10_ReentrantLock - enter method2

可打断

可以用让其他线程调用 interrupt 方法打断当前的锁

需要使用 lockInterruptibly 方法进行加锁才可被打断:

@Slf4j(topic = "c.d11_TestLockInterrupt")
public class d11_TestLockInterrupt {
    private static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(()->{
            try {
                log.debug("尝试获得锁");
                // lockInterruptibly:
                //  如果没有竞争,此方法会获取lock对象的锁
                //  如果有竞争,则进去阻塞队列,可以被其他线程用interrupt方法打断
                lock.lockInterruptibly();
            }catch (InterruptedException e){
                e.printStackTrace();
                log.debug("没有获得锁,返回");
                return;
            }

            try {
                log.debug("获取到锁");
            }finally {
                lock.unlock();
            }
        }, "t1");

        lock.lock(); // 主线程先获取锁,t1等待
        t1.start();

        Thread.sleep(1000);
        log.debug("打断 t1");
        t1.interrupt();
    }
}
19:53:49 [t1] c.d11_TestLockInterrupt - 尝试获得锁
19:53:50 [main] c.d11_TestLockInterrupt - 打断 t1
19:53:50 [t1] c.d11_TestLockInterrupt - 没有获得锁,返回
java.lang.InterruptedException at ... ...

锁超时

可打断是被动的,等待其他线程打断。锁超时是主动的打断,避免无限时的等待下去

使用 tryLock 方法实现 没获得到锁就立刻失败:

ReentrantLock lock = new ReentrantLock();
Thread t1 = new Thread(() -> {
    log.debug("启动...");
    if (!lock.tryLock()) { // trylock尝试获取锁
        log.debug("获取立刻失败,返回");
        return;
    }
    try {
        log.debug("获得了锁");
    } finally {
        lock.unlock();
    }
}, "t1");
lock.lock();
log.debug("获得了锁");
t1.start();
try {
    Thread.sleep(2000);
} finally {
    lock.unlock();
}

超时失败实现:

lock.tryLock(1, TimeUnit.SECONDS)

公平锁

ReentrantLock 默认是不公平的。根据构造参数可以设置为公平锁:

ReentrantLock lock = new ReentrantLock(true);

条件变量

synchronized 中也有条件变量,就是我们讲原理时那个 waitSet 休息室,当条件不满足时进入 waitSet 等待

ReentrantLock 的条件变量比 synchronized 强大之处在于,它是支持多个条件变量的,不同在于:

  • synchronized 是那些不满足条件的线程都在一间休息室等消息
  • 而 ReentrantLock 支持多间休息室,有专门等烟的休息室、专门等早餐的休息室、唤醒时也是按休息室来唤醒

使用要点:

  • await 前需要获得锁
  • await 执行后,会释放锁,进入 conditionObject 等待
  • await 的线程被唤醒(或打断、或超时)取重新竞争 lock 锁
    竞争 lock 锁成功后,从 await 后继续执行

使用方式:

通过 lock.newCondtition() 的方法创建一个新的条件变量对象:

@Slf4j(topic = "c.d12_TestConditionLock")
public class d12_TestConditionLock {
    static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) throws InterruptedException {
        Condition condition1 = lock.newCondition();
        Condition condition2 = lock.newCondition();

        lock.lock();
        // 进入条件1(休息室1)等待
        condition1.await();

        // 叫醒休息室1中的线程:
        condition1.signal();
        condition1.signalAll();
    }
}
文章来源:https://blog.csdn.net/qq_45364953/article/details/135141483
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。