Java多线程与并发编程(2)_Synchronized

最新推荐文章于 2024-07-28 14:23:21 发布

JunSIr_#

最新推荐文章于 2024-07-28 14:23:21 发布

阅读量1.1w

点赞数 1

分类专栏： Java并发包文章标签： java 多线程 jvm synchronized

本文链接：https://blog.csdn.net/JunSIrhl/article/details/106426723

版权

Java并发包专栏收录该内容

15 篇文章 1 订阅

订阅专栏

文章目录

使用

修饰实例方法: 锁实例对象，

class T {
    private int count=10;
    public void m(){
        synchronized (this){
            count--;
            System.out.println(Thread.currentThread().getName()+" count = "+count);
        }
    }
}

修饰静态方法: 锁类对象

class T {
    private static int count=10;

    public synchronized static void m(){    //这里等同于synchronized(yxxy.c_001.T.class)
        count--;
        System.out.println(Thread.currentThread().getName()+" count = "+count);
    }

    public static void mm(){
        synchronized (T.class){ //这里写synchronized(this)是否可以?
            count--;
        }
    }
}

修饰代码块: 锁参数中传入的自定义加锁对象

class T {
    private int count =10;
    private Object o=new Object();

    public void m(){
        synchronized (o){   //任何线程要执行下面的代码，必须先拿到o的锁
            count--;
            System.out.println(Thread.currentThread().getName()+" count = "+count);
        }
    }
}

什么样的代码放入synchronized中？

1.代码被多个线程访问
2.代码中有共享的数据
3.共享数据被多条语句操作

Monitor

Monitor 被翻译为监视器或管程，是操作系统层次的数据结构

每个 Java 对象都可以关联一个 Monitor 对象

如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针

模拟多线程竞争Synchronized锁对象的流程

刚开始 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 是之前获得过锁，但条件不满足Runable进入 WAITING 状态的线程，需要被其他线程唤醒

Java对象头

被synchronized的对象，对象头的MarkWord中的某个字段会指向Monitor地址，具体来看下对象头是什么结构

以 32 位虚拟机为例

普通对象：

数组对象：

其中 Mark Word 结构为：

hashcode：对象哈希值、用于HashMap等结构中定位
age：jvm分代年龄，大于某个值后进入老年代
thread：线程id
ptr_to_lockrecode:轻量级锁模式下指向线程栈中锁记录
ptr_to_heavyweight_monitor:重量级级锁模式下指向monitor

Mark Word记录了对象和锁有关的信息，当这个对象被synchronized关键字当成同步锁时，围绕这个锁的一系列操作都和Mark Word有关

Mark Word在32位JVM中的长度是32bit，在64位JVM中长度是64bit

64 位虚拟机 Mark Word：

轻量级锁

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

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

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

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

创建锁记录（Lock Record）对象，每个线程的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的Mark Word
让锁记录中 Object reference 指向锁对象，并尝试用 cas （交换并设置）替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录

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

成功，则解锁成功

失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

锁膨胀

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

如有以下流程：

当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁
这时 Thread-1 加轻量级锁失败，进入锁膨胀流程，为 Object 对象申请 Monitor 锁（重量级锁），让 Object 指向重量级锁地址，然后自己进入 Monitor 的 EntryList BLOCKED阻塞队列

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

自旋CAS

重量级锁竞争的时候，还可以使用自旋来进行优化，避免阻塞带来的上下文切换，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞

自旋重试成功的情况：

自旋重试失败的情况：

注意：

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

偏向锁

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

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头hashcode字段中，之后发现这个线程 ID 是自己的（锁对象ptr_to_lockrecode同时指向线程栈帧中的锁记录）就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有

class TestSyn{
    static final Object obj = new Object() ;

    public static void method1(){
        synchronized (obj){
            //同步块A
            method2();
        }
    }
    
    public static void method2(){
        synchronized (obj){
            //同步块B
            method3();
        }
    }
    public static void method3(){
        synchronized (obj){
            //同步块C

        }
    }
}

轻量级锁下，主线程每次申请锁都需要CAS

偏向锁下。无需CAS

偏向锁撤销的情况

hashCode()导致偏向锁被动撤销

调用了对象的 hashCode，但偏向锁的对象 MarkWord 中存储的是线程 id，如果调用 hashCode 会导致偏向锁被撤销并重新生成锁对象hashcode

轻量级锁会在锁记录中记录锁对象的 hashCode
重量级锁会在 Monitor 中记录 hashCode

故轻量级重量级锁调用hashCode是没有问题的

在调用 hashCode 后使用偏向锁，记得去掉 -XX:-UseBiasedLocking

线程争抢导致偏向锁被动撤销

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

调用 wait/notify导致偏向锁撤销

锁对象一旦调用wait/notify会导致该锁上的线程状态改变

wait/notify

接synchronized，当一个线程暂时不满足条件，应该进去等待队列，等着另一个线程执行完毕，线程满足条件，由另一个线程唤醒之

注意，wait/notify需要在synchroniezd代码块中才能使用

API 介绍

obj.wait() 让进入 object 监视器的线程到 waitSet 等待
obj.notify() 在 object 上正在 waitSet 等待的线程中挑一个唤醒
obj.notifyAll() 让 object 上正在 waitSet 等待的线程全部唤醒
唤醒后的线程进入Runable状态，等待CPU时间片

Park/UnPark

这套组合与wait/notify是一样的效果，但这套组合要优于wait/notify，它们是 LockSupport 类中的方法

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

先 park 再 unpark

与 Object 的 wait & notify 相比

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

Park/UnPark原理

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

打个比喻

线程就像一个旅人，Parker 就像他随身携带的背包，条件变量cond就好比背包中的帐篷。_counter 就好比背包中的备用干粮（0 为耗尽，1 为充足）
调用 park 就是要看需不需要停下来歇息
- 如果备用干粮耗尽，那么钻进帐篷歇息
- 如果备用干粮充足，那么不需停留，继续前进
调用 unpark，就好比令干粮充足
- 如果这时线程还在帐篷，就唤醒让他继续前进
- 如果这时线程还在运行，那么下次他调用 park 时，仅是消耗掉备用干粮，不需停留继续前进
- 因为背包空间有限，多次调用 unpark 仅会补充一份备用干粮