type
status
date
Aug 31, 2024 02:25 PM
slug
summary
category
tags
password
icon
共享带来的问题场景案例问题分析临界区Critical Section解决方案synchronized语法思考面向对象改进的synchronized方法上的 synchronized锁对象：this / class线程八锁练习题变量的线程安全 分析成员变量和静态变量是否线程安全？局部变量是否线程安全？局部变量线程安全分析常见线程安全类线程安全类方法的组合不可变类线程安全性实例分析习题练习卖票练习具体分析转账练习具体分析Monitor 概念Java 对象头Monitor（锁）原理synchronized 原理synchronized 原理进阶轻量级锁锁膨胀自旋优化偏向锁偏向状态
共享带来的问题
场景案例
两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？
问题分析
以上的结果可能是正数、负数、零。为什么呢？因为 Java 中对静态变量的自增，自减并不是原子操作，要彻底理解，必须从字节码来进行分析。
例如对于
i++ 而言（i为静态变量），实际会产生如下的 JVM 字节码指令：而对应
i-- 也是类似：而 Java 的内存模型如下，完成静态变量的自增，自减需要在主存和工作内存中进行数据交换：
如果是单线程以上 8 行代码是顺序执行（不会交错）没有问题：
但多线程下这 8 行代码可能交错运行：
- 出现负数的情况：
- 出现正数的情况：
临界区Critical Section
- 一个程序运行多个线程本身是没有问题的
- 问题出在多个线程访问共享资源
- 多个线程读共享资源其实也没有问题
- 在多个线程对共享资源读写操作时发生指令交错，就会出现问题
- 一段代码块内如果存在对共享资源的多线程读写操作，称这段代码块为临界区
- 例如，下面代码中的临界区
解决方案
竞态条件 Race Condition多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件
为了避免临界区的竞态条件发生，有多种手段可以达到目的。
- 阻塞式的解决方案：synchronized，Lock
- 非阻塞式的解决方案：原子变量
本次先使用阻塞式的解决方案：synchronized，来解决上述问题，即俗称的【对象锁】，它采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】，其它线程再想获取这个【对象锁】时就会阻塞住。这样就能保证拥有锁的线程可以安全的执行临界区内的代码，不用担心线程上下文切换。
注意：虽然 java 中互斥和同步都可以采用 synchronized 关键字来完成，但它们还是有区别的：
- 互斥是保证临界区的竞态条件发生，同一时刻只能有一个线程执行临界区代码；
- 同步是由于线程执行的先后、顺序不同、需要一个线程等待其它线程运行到某个点
synchronized语法
- 利用
synchronized解决办法如下：
你可以做这样的类比：
synchronized(对象)中的对象，可以想象为一个房间（room），有唯一入口（门）房间只能一次进入一人进行计算，线程 t1，t2 想象成两个人
- 当线程 t1 执行到
synchronized(room)时就好比 t1 进入了这个房间，并锁住了门拿走了钥匙，在门内执行count++代码
- 这时候如果 t2 也运行到了
synchronized(room)时，它发现门被锁住了，只能在门外等待，发生了上下文切换，阻塞住了
- 这中间即使 t1 的 cpu 时间片不幸用完，被踢出了门外（不要错误理解为锁住了对象就能一直执行下去【还存在cpu时间片用完的情况】），这时门还是锁住的，t1 仍拿着钥匙，t2 线程还在阻塞状态进不来，只有下次轮到 t1 自己再次获得时间片时才能开门进入
- 当 t1 执行完
synchronized{}块内的代码，这时候才会从 obj 房间出来并解开门上的锁，唤醒 t2 线程把钥匙给他。t2 线程这时才可以进入 obj 房间，锁住了门拿上钥匙，执行它的count--代码
思考
结论：
synchronized 实际是用对象锁保证了临界区内代码的原子性，临界区内的代码对外是不可分割的，不会被线程切换所打断。为了加深理解，请思考下面的问题
- 如果把 synchronized(obj) 放在 for 循环的外面，如何理解？
本质上锁住的是5000*4=20000个原子操作【原子性】
- 如果 t1 synchronized(obj1) 而 t2 synchronized(obj2) 会怎样运作？
不行，t1和t2锁住的不是同一个对象【锁对象】【相当于进了两个不同的room】，synchronized需要锁住同一个公共资源。
- 如果 t1 synchronized(obj) 而 t2 没有加会怎么样？如何理解？
不行，只要是公共资源，每个线程访问的时候都需要加锁【锁对象】
面向对象改进的synchronized
把需要保护的共享变量放入一个类
方法上的 synchronized
锁对象：this / class
- 在成员方法加
synchronized等价于锁住的是this对象
- 在静态方法上加
synchronized等价于锁住的是类对象（class）
线程八锁练习题
- 情况1：12或者21
- 锁住的是同一个对象
this，存在互斥，具体谁先被打印出来，要看操作系统的任务调度器。
- 情况2：1s后12，或 2 1s后 1
- 情况3：3 1s 12 或 23 1s 1 或 32 1s 1
- 情况4：2 1s 后 1
- n1和n2使用的是不同的锁，不存在互斥，并行执行，由于
b()没有sleep，所以先打印。
- 情况5：2 1s 后 1
- 锁住的是不同对象，
a()是Number.class，b()是this对象，不存在互斥，并行执行，由于b()没有sleep，所以先打印。
- 情况6：1s 后12， 或 2 1s后 1
- 锁住的是同一个对象
- 情况7：2 1s 后 1
- 情况8：1s 后12， 或 2 1s后 1
- 锁住的是同一个对象【
Number.class在堆中只有一个】
变量的线程安全 分析
成员变量和静态变量是否线程安全？
- 如果它们没有共享，则线程安全
- 如果它们被共享了，根据它们的状态是否能够改变，又分两种情况
- 如果只有读操作，则线程安全
- 如果有读写操作，则这段代码是临界区，需要考虑线程安全局部变量是否线程安全。
局部变量是否线程安全？
- 局部变量是线程安全的
- 但局部变量引用的对象则未必
- 如果该对象没有逃离方法的作用访问，它是线程安全的
- 如果该对象逃离方法的作用范围，需要考虑线程安全
局部变量线程安全分析
- 局部变量的线程安全分析
每个线程调用
test1() 方法时局部变量 i，会在每个线程的栈帧内存中被创建多份，因此不存在共享。
- 局部变量的引用的线程安全分析
- 分析：
- 无论哪个线程中的 method2 引用的都是同一个对象中的 list 成员变量
- method3 与 method2 分析相同
- 解决办法：将
list修改为局部变量
- 分析：
list是局部变量，每个线程调用时会创建其不同实例，没有共享- 而
method2的参数是从method1中传递过来的，与method1中引用同一个对象 method3的参数分析与method2相同
- 方法访问修饰符带来的思考，如果把 method2 和 method3 的方法修改为 public 会不会代理线程安全问题？
- 有其它线程调用 method2 和 method3
- 在 情况1 的基础上，为 ThreadSafe 类添加子类，子类覆盖 method2 或 method3 方法，即
从这个例子可以看出private或final提供【安全（这里指的就是线程安全）】的意义所在，请体会开闭原则中的【闭
常见线程安全类
- String
- Integer
- StringBuffer
- Random
- Vector
- Hashtable
- java.util.concurrent 包下的类
注意：这里说它们是线程安全的是指，多个线程调用它们同一个实例的某个方法时，是线程安全的。
例如，
HashTable的put方法和get方法的源码如下。我们new了一个Hashtable，当调用table.put("key", "value1")或者table.get("key")是线程安全的，但是将这些方法组合在一起使用时，就不是线程安全的了。即同一个实例的每个方法是原子的，但多个方法的组合不是原子的。线程安全类方法的组合
分析下面代码是否线程安全？
不安全，可能会造成覆盖
不可变类线程安全性
String、Integer 等都是不可变类，因为其内部的状态不可以改变，因此它们的方法都是线程安全的【内部状态不能改→线程安全】
有同学或许有疑问，
String 有 replace，substring 等方法【可以】改变值啊，那么这些方法又是如何保证线程安全的呢？下面是
String类的substring方法，可以看到，当((beginIndex == 0) && (endIndex == value.length))成立的时候，返回this，否则返回new String，并没有修改value的值，在new String中是拷贝赋值，因此也是线程安全的。实例分析
- 例1：
- 例2：
- 例3：
- 例4：
- 例5：
- 例6：
- 例7：
其中 foo 的行为是不确定的，可能导致不安全的发生，被称之为外星方法
- 例8：
习题练习
卖票练习
具体分析
由此可见，我们所写的代码是存在线程不安全的问题，具体就是临界区的代码：即对公共资源存在读写操作的代码块。
这段代码对
count 有读操作（this.count >= amount），也有写操作（this.count -= amount），需要加锁，将public int sell(int amount) {}修改为public synchronized int sell(int amount) {}。为什么将synchronized加在方法上public synchronized int sell(int amount)，而不是加在类上synchronized (TicketWindow.class)？因为window.sell(random(5))只有一个需要保护的共享变量（this.count），加在方法上即可。
下面的代码线程安全吗？安全。因为
Vector 类的 add 方法源码已经加锁了。假设将
public int sell(int amount) {}已经修改为public synchronized int sell(int amount) {}，将下面的代码组合起来安全吗？安全。因为window和amountList是两个不同的实例，不存在共享资源的情况。注意，和同一个实例（其中，这个实例的方法是原子的，但是组合起来线程不一定安全）相区别。
下面的代码线程安全吗？安全，虽然
ArrayList 类中的 add 方法的源码没有加synchronized ，但是threadList.add(thread);是在主线程中，不存在争抢公共资源。因此，只需要在
TicketWindow 类中的sell方法上加上synchronized即可，即：public synchronized int sell(int amount) {}转账练习
测试下面代码是否存在线程安全问题，并尝试改正
具体分析
这段代码既有读操作（
this.getMoney()），又有写操作（this.setMoney），属于临界区。- 这段代码有两个需要保护的共享变量（
this.getMoney()，target.getMoney()），不能加在方法上，需要加在类上。
- 同时
a.transfer(b, randomAmount())和b.transfer(a, randomAmount())执行的时候操作的是a和b的余额，不单单只是a或者b的余额，因此不能加在方法上，需要加在类上。
Monitor 概念
Java 对象头
以 32 位虚拟机为例
- 普通对象
- 数组对象
其中32 位虚拟机的 Mark Word 结构为64 位虚拟机 Mark Word结构为参考资料：‣
Monitor（锁）原理
Monitor 被翻译为监视器【从JVM的角度】或管程【从操作系统的角度】
每个 Java 对象都可以关联一个 Monitor 对象，如果使用
synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针。Monitor 结构如下：
- 刚开始 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 中等待的线程来竞争锁，竞争的时是非公平的【具体由JVM底层决定】
- 图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程。
注意：
synchronized必须是进入同一个对象的monitor才有上述的效果
- 不加
synchronized的对象不会关联监视器，不遵从以上规则
synchronized 原理
对应的字节码为：
注意：方法级别的synchronized不会在字节码指令中有所体现。
synchronized 原理进阶
老王 - JVM 小南 - 线程 小女 - 线程 房间 - 对象 房间门上 - 防盗锁 - Monitor 房间门上 - 小南书包 - 轻量级锁 房间门上 - 刻上小南大名 - 偏向锁 批量重刻名 - 一个类的偏向锁撤销到达 20 阈值 不能刻名字 - 批量撤销该类对象的偏向锁，设置该类不可偏向
轻量级锁
轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。
轻量级锁对使用者是透明的，即语法仍然是
synchronized假设有两个方法同步块，利用同一个对象加锁
- 加锁1：创建锁记录（Lock Record）对象，每个线程都的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的Mark Word
- 加锁2：让锁记录中
Object reference指向锁对象，并尝试用 cas 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录
Object 的Mark Word 的01表示无锁状态，Thread-0的Lock Record的00表示轻量级锁。
- 加锁3.1：如果 cas 替换成功，对象头中存储了锁记录地址和状态 00 ，表示由该线程给对象加锁成功，这时图示如下：
- 加锁3.2：如果 cas 失败，有两种情况：
- 如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程
- 如果是自己执行了
synchronized锁重入，那么再添加一条 Lock Record 作为重入的计数【Thread-0中有几个Lock Record，表示加了几次锁（简单理解为有两次synchronized）】
- 解锁1：当退出
synchronized代码块（解锁时）如果有取值为null的锁记录，表示有重入，这时重置锁记录，表示重入计数减一。
- 解锁2：当退出
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 线程
自旋优化
重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。
- 自旋重试成功的情况
- 自旋重试失败的情况
注意：
- 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
- 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
- Java 7 之后不能控制是否开启自旋功能。
偏向锁
轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。
Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有。
偏向状态
回忆一下对象头格式（64 位虚拟机 Mark Word结构）
一个对象创建时：
- 如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的thread、epoch、age 都为 0
- 偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数
-XX:BiasedLockingStartupDelay=0来禁用延迟
- 如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、age 都为 0，第一次用到 hashcode 时才会赋值
- 作者:Frank
- 链接:https://blog.franksteven.me//article/thread_safe
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。