【Java 并发编程】(二) 从对象内存布局开始聊 synchronized

对象的内存布局

首先抛出一个经典面试题: 一个 Object 对象占多大?
在这里插入图片描述

这里我用工具打印了出来, 发现是 “16bytes”, 也就是 16B; 为什么? 请继续往下看;

在这里插入图片描述

普通对象(除了数组), 由markword, 类型指针, 实例数据(就是对象里的成员), 对齐填充(整个对象大小要能被8B整数, 方便64bit总线)构成;

markword 中保存了监视器锁的信息, GC 的信息, 还可能保存默认的 hashCode 方法计算出的哈希值;
类型指针指向这个对象所属的类的类对象;
java命令默认带两个压缩指针的参数, UseCompressedClassPointers和UseCompressedOops(Ordinary Object Pointers), 在64位环境下, 一个指针应当占8字节; 第一个指令会将对象头中的类型指针压缩位4B, 第二个参数会将成员指针压缩为4B;
一个java应用所占的内存大小, 几乎不会大到需要用 64 位的寻址空间, 32 位完全够了, 这是为什么可以开启指针压缩;
对于Object类, markword 8B, 类型指针4B, Object类型没有实例数据0B, 对齐填充4B, 总共 16B

对象头

在这里插入图片描述

markword中记录了锁信息, GC信息(例如当前熬过了几次垃圾回收, 注意这个字段只有4bit最大值15)
如果使用了默认的hashcode方法, 那么计算出来的 hash 值会被放到markword里保存; 而这个保存的地方, 和偏向锁是有冲突的, 如果调用过默认的 hashCode 方法, 偏向锁就不能用了;
使用了偏向锁, 再调用默认的 hashCode, 会触发锁升级;

监视器锁

特点

对象级别的锁： 监视器锁是与对象关联的，每个对象都有一个内置的监视器锁。当一个线程获取了对象的监视器锁后，其他线程就无法同时获取该对象的监视器锁，直到锁被释放。
排他性访问： 监视器锁实现了排他性访问，即同一时刻只有一个线程能够持有对象的监视器锁，其他线程需要等待。
基于进入和退出监视器锁的规则： 线程可以进入同步代码块或同步方法，获取对象的监视器锁；当线程退出同步代码块或同步方法时，会释放对象的监视器锁。
可重入性： 监视器锁支持线程的可重入性，即同一个线程在持有锁的情况下可以重复地继续获取锁，而不会发生死锁。但是要注意获取多少次锁就需要释放多少次锁
等待和唤醒机制： 一个线程持有监视器锁时, 其它线程尝试获取锁时将被阻塞, 放到该锁的阻塞队列中; 持有锁的线程释放锁后, 如果有其他线程正在等待获取同一个对象的监视器锁，那么其中的一个线程会被唤醒;

Synchronized

synchronized代码块

synchronized(对象){
    ...
}

使用同步代码块的线程执行时如果出现异常, 会自动释放锁;
小括号内的对象又称互斥条件, 是同步代码块锁住的对象; 可以使用this, 某个特定类的对象, 某个类的类对象;
当线程进入 synchronized 代码块时，它会尝试获取对象的监视器锁。如果对象的监视器锁已经被其他线程持有，则当前线程会被阻塞，直到获取到锁为止。获取到锁后，线程就可以执行 synchronized 代码块中的代码，直到代码块执行完毕或者抛出异常，然后释放锁。
具有可重入的特点;

synchronized方法

synchronized关键字加在静态方法上, 则进入方法时会尝试获取该静态方法所属的类的类对象的监视器锁;
synchronized加在成员方法上, 进入方法时会尝试获取调用该方法的对象的的监视器锁;
退出方法时释放锁;

synchronized实现原理

源码中, synchronized关键字
编译后变为对监视器锁的操作, monitor enter 和 monitor exit, 实际就是对对象头中markword的修改
在JVM执行过程中, 会自动进行锁升级
最终依靠汇编指令, lock_cmpxchg指令实现

非公平

synchronized是非公平锁, 当一个线程尝试获取锁时, 不会优先让阻塞队列中的线程获取锁; 而是一上来自己就尝试获取锁;
通常是唤醒队头元素, 通常也就是等待时间最久的元素

wait / notify

需要在synchronized代码块内部或者synchronized方法内部, 已经获取了某个对象的监视器锁的前提下, 才能用这个对象去调用wait/notify方法
wait:
- 调用之前必须先获取到该对象的监视器锁
- 某个对象调用wait方法后, 当前线程会释放这个对象的监视器锁, 并进入 WAITING 状态, 加入到该监视器锁的waiting队列中, 等待其他线程调用相同对象的notify/ notifyAll方法唤醒;
notify:
- 调用之前必须先获取到该对象的监视器锁
- 调用notify方法后会在该监视器锁的waiting队列中唤醒一个线程;
- 被唤醒的线程会重新尝试获取该对象的监视器锁; 获取到以后才能继续执行; 获取失败就blocked
notifyAll:
- 与notify的区别是会唤醒监视器锁waiting队列中的所有线程

为什么要在获取监视器锁以后才能 wait 和 notify ? 主要是为了防止一次 notify 调用导致多个 WAITING 状态的线程被唤醒; 在 synchronized 代码块内部, 唤醒时需要重新获取监视器锁, 避免多个线程能同时往下执行;

锁升级

synchronized 获取对象的锁时, 获取方式会根据线程竞争情况进行升级; 因为重量级锁是要向操作系统申请的, 时间消耗比较大;
在Java中，锁的状态包括偏向锁、轻量级锁和重量级锁。
偏向锁: 当一个线程第一次进入同步块时，会尝试获取对象的偏向锁, 本质就是通过 CAS(下文会有详细介绍) 的方式, 将指向本线程的指针, 写到对象头里; 以后相同线程再尝试获取相同对象的监视器锁时, 会直接获取成功;
轻量级锁: 当有不同线程尝试获取锁时, 锁状态升级为轻量级锁, 轻量级锁使用CAS操作来尝试获取锁。和获取偏向锁类似, 用CAS操作尝试将自己的 LockRecord 指针写入对象头来实现获取锁; 每个线程有自己的方法栈, 方法栈里有LockRecord; 如果获取失败，线程就会进行自旋操作继续尝试, 自旋达到一定次数后(由JVM动态计算此阈值)，轻量级锁会升级为重量级锁;

为什么变成用 LockRecord了? 接着用线程指针不行吗? 应该需要保存一些额外的信息了; 比如说自旋次数;
重量级锁: 将获取锁失败的线程阻塞;

重量级锁是向操作系统申请获取的, 重量级锁的操作都是由操作系统负责的;

当某个线程获取重量级锁失败时, 会进入该锁对应的阻塞队列中;

当临界区大, 并发级别高时, 适合使用重量级锁, 避免cpu资源的消耗;临界区小, 并发级别低时, 适合使用轻量级锁
补充两个概念, 知道就行
锁粗化

JVM检测到一连串的操作都是对同一个对象进行加锁的话, 会将锁的范围粗化到一系列操作的外部, 只进行一次加锁;

StringBuffer是线程安全的, append方法需要加锁;
```
while(i < 100){
i++;
sb.append("hello");
}
```
锁消除

当确定某个锁不必要的时候, 例如一个方法中有StringBuffer类型的局部变量, 其它线程不可能访问到这个局部变量, 那么会自动消除StringBuffer内的加锁操作

在Java中，监视器锁（也称为内置锁或对象锁）在实现上通常包含两种队列：

等待队列（Wait Set）：等待队列用于存放那些因为调用了 Object.wait()、Thread.join() 或者 LockSupport.park() 等方法而进入等待状态的线程。当线程被唤醒时，它会从等待队列中移出，重新进入锁的竞争中。
阻塞队列（Blocked Set）：阻塞队列用于存放那些尝试获取锁但由于锁被其他线程持有而进入阻塞状态的线程。这些线程会被放入锁的阻塞队列中等待锁的释放。

CAS

CAS（Compare and Swap）是一种原子性操作，能够在无锁的情况下实现安全的值更新操作;
也可以宽泛一点就说成是自旋
它的基本思想是，要修改某个值时, 先读取当前值, 记为e, 计算出要修改为的值v, 写回之前再次读取当前值n, 如果n和e不相同, 说明修改失败, 放弃修改, 重新执行此过程
多核环境下, 底层是由 lock_cmpxchg 汇编指令实现的, cmpxchg这条指令并没有原子性, 必须是lock_cmpxchg指令, 前面的lock指令保证了原子性;
例如由CAS + 自旋机制实现轻量级锁机制
1. 线程尝试获取锁时，首先会通过CAS操作尝试获取轻量级锁
2. 如果获取锁失败, 通过自旋操作不断尝试获取锁
```
while(!cas){
count++;
if(cnt > threshold)
升级重量级锁;
}
```
ABA问题

当我写回之前再次读取当前值n, 即使仍然等于e, 我也不知道到底是没被人改过, 还是改过只不过最后还是改成了e;

解决: 给值添加版本号, 读取值的时候连同版本号一起读取, 如果值相同但是版本号不同, 说明已经被修改过;