共享模型之管程

共享模型之管程

1. 共享带来的问题

两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？

static int counter = static int counter = 0;

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                counter++;
            }
        }, "t1");

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                counter--;
            }
        }, "t2");

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        log.debug("{}", counter);

    }

问题分析

以上的结果可能是正数、负数、零。为什么呢？因为 Java 中对静态变量的自增，自减并不是原子操作，要彻底理 解，必须从字节码来进行分析 

getstatic   i   getstatic   i   // 获取静态变量i的值   
iconst_1				// 准备常量1
iadd					  // 自增
putstatic   i   // 将修改后的值存入静态变量i

例如对于 i++ 而言（i 为静态变量），实际会产生如下的 JVM 字节码指令：

getstatic 从类中获取静态字段

putstatic 设置类中静态字段的值

iconst_m1 将1个常量加载到操作数栈

iadd 加法指令

而对应 i-- 也是类似：

getstatic   i   getstatic   i   // 获取静态变量i的值   
iconst_1				// 准备常量1
isub					  // 自减
putstatic   i   // 将修改后的值存入静态变量i

而Java 的内存模型如下，完成静态变量的自增，自减需要在主存和工作内存中进行数据交换：

如果是单线程以上 8 行代码是顺序执行（不会交错）没有问题：

但多线程下这 8 行代码可能交错运行,进而会出现正数和负数的情况.

临界区 Critical Section

  • 一个程序运行多个线程本身是没有问题的 问题出在多个线程访问共享资源

    • 多个线程读共享资源其实也没有问题
    • 在多个线程对共享资源读写操作时发生指令交错，就会出现问题

  • 一段代码块内如果存在对共享资源的多线程读写操作，称这段代码块为临界区

    例如，下面代码中的临界区 

static int counter = static int counter = 0;

static void increment() 
// 临界区 
{ 
	counter++; 
}

static void decrement() 
// 临界区 
{ 
	counter--; 
}

竞态条件 Race Condition

多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件

2. synchronized 解决方案

为了避免临界区的竞态条件发生，有多种手段可以达到目的。

  • 阻塞式的解决方案：synchronized，Lock
  • 非阻塞式的解决方案：原子变量

synchronized，俗称【对象锁】，它采用互斥的方式让同一 时刻至多只有一个线程能持有【对象锁】，其它线程再想获取这个【对象锁】时就会阻塞住。这样就能保证拥有锁 的线程可以安全的执行临界区内的代码，不用担心线程上下文切换

注意
虽然 java 中互斥和同步都可以采用 synchronized 关键字来完成，但它们还是有区别的：

  • 互斥是保证同一时刻只能有一个线程执行临界区代码
  • 同步是由于线程执行的先后、顺序不同、需要一个线程等待其它线程运行到某个点

语法 

synchronized(对象) synchronized(对象) // 线程1， 线程2(blocked) 
{ 
	临界区 
}

解决 

static int counter = static int counter = 0;
   static final Object room = new Object();

   public static void main(String[] args) throws InterruptedException {
       Thread t1 = new Thread(() -> {
           for (int i = 0; i < 5000; i++) {
               synchronized (room) {
                   counter++;
               }

           }

       }, "t1");

       Thread t2 = new Thread(() -> {
           for (int i = 0; i < 5000; i++) {
               synchronized (room) {
                   counter--;
               }
           }
       }, "t2");

       t1.start();
       t2.start();
       t1.join();
       t2.join();
       log.debug("{}", counter);

   }

你可以做这样的类比：

  • synchronized(对象) 中的对象，可以想象为一个房间（room），有唯一入口（门）房间只能一次进入一人 进行计算，线程 t1，t2 想象成两个人
  • 当线程 t1 执行到 synchronized(room) 时就好比 t1 进入了这个房间，并锁住了门拿走了钥匙，在门内执行 count++ 代码
  • 这时候如果 t2 也运行到了 synchronized(room) 时，它发现门被锁住了，只能在门外等待，发生了上下文切 换，阻塞住了
  • 这中间即使 t1 的 cpu 时间片不幸用完，被踢出了门外（不要错误理解为锁住了对象就能一直执行下去哦）， 这时门还是锁住的，t1 仍拿着钥匙，t2 线程还在阻塞状态进不来，只有下次轮到 t1 自己再次获得时间片时才 能开门进入
  • 当 t1 执行完 synchronized{} 块内的代码，这时候才会从 obj 房间出来并解开门上的锁，唤醒 t2 线程把钥 匙给他。t2 线程这时才可以进入 obj 房间，锁住了门拿上钥匙，执行它的 count-- 代码

思考

synchronized 实际是用对象锁保证了临界区内代码的原子性，临界区内的代码对外是不可分割的，不会被线程切 换所打断。 为了加深理解，请思考下面的问题

  • 如果把 synchronized(obj) 放在 for 循环的外面，如何理解？– 原子性
  • 如果 t1 synchronized(obj1) 而 t2 synchronized(obj2) 会怎样运作？– 锁对象
  • 如果 t1 synchronized(obj) 而 t2 没有加会怎么样？如何理解？– 锁对象

方法上的 synchronized

class class Test {
    public synchronized void test() {

    }

} 等价于

class Test {

    public void test() {
        synchronized (this) {

        }

    }
}
class class Test {
    public synchronized static void test() {

    }

} 等价于

class Test {

    public void test() {
        synchronized (Test.class) {

        }

    }
}

不加 synchronized 的方法

不加 synchronzied 的方法就好比不遵守规则的人，不去老实排队（好比翻窗户进去的）

3. 变量的线程安全分析

成员变量和静态变量是否线程安全？

  • 如果它们没有共享，则线程安全

  • 如果它们被共享了，根据它们的状态是否能够改变，又分两种情况

    • 如果只有读操作，则线程安全

    • 如果有读写操作，则这段代码是临界区，需要考虑线程安全

局部变量是否线程安全？

  • 局部变量是线程安全的

  • 但局部变量引用的对象则未必

    • 如果该对象没有逃离方法的作用范围，它是线程安全的
    • 如果该对象逃离方法的作用范围，需要考虑线程安全(public非final方法可能会子类重写，局部变量可能会被多线程访问，进而引发线程安全问题)

常见线程安全类

  • String
  • Integer
  • StringBuffer
  • Random
  • Vector
  • Hashtable
  • java.util.concurrent 包下的类

这里说它们是线程安全的是指，多个线程调用它们同一个实例的某个方法时，是线程安全的。也可以理解为

  • 它们的每个方法是原子的
  • 但注意它们多个方法的组合不是原子的

不可变类线程安全性

String、Integer 等都是不可变类，因为其内部的状态不可以改变，因此它们的方法都是线程安全的 有人或许有疑问，String 有 replace，substring 等方法【可以】改变值啊，那么这些方法又是如何保证线程安 全的呢？

  • 通过创建新的对象并返回,原有的不变

4. Monitor 概念

Java 对象头

以 32 位虚拟机为例

普通对象

|--------------------------------------------------------------| 
| 									Object Header (64 bits)										 | 
|------------------------------------|-------------------------| 
| 					Mark Word (32 bits) 		 |	 	Klass Word (32 bits) | 
|------------------------------------|-------------------------|

数组对象

|---------------------------------------------------------------------------------| 
| 													Object Header (96 bits) 															| 
|--------------------------------|-----------------------|------------------------| 
| 						Mark Word(32bits)	 | Klass Word(32bits) 	 | array length(32bits) 	| 
|--------------------------------|-----------------------|------------------------|

其中 Mark Word 结构为

|-------------------------------------------------------|--------------------| 
|												 Mark Word (32 bits) 						| 			State				 | 
|-------------------------------------------------------|--------------------| 
| 		hashcode:25 		 	|	 age:4 	| biased_lock:0 | 01  | 			Normal 			 | 
|-------------------------------------------------------|--------------------| 
| 	thread:23 | epoch:2 |  age:4  | biased_lock:1 | 01  | 			Biased			 | 
|-------------------------------------------------------|--------------------| 
| 												  ptr_to_lock_record:30 | 00  | Lightweight Locked | 
|-------------------------------------------------------|--------------------| 
| 									ptr_to_heavyweight_monitor:30 | 10  | Heavyweight Locked | 
|-------------------------------------------------------|--------------------| 
| 																								| 11  | 		Marked for GC  | 
|-------------------------------------------------------|--------------------|

64 位虚拟机 Mark Word

|----------------------------------------------------------|--------------------| 
| 															Mark Word (64 bits) 			 | 				State       | 
|----------------------------------------------------------|--------------------| 
| unused:25|hashcode:31|unused:1|age:4| biased_lock:0   |01| 				Normal      | 
|----------------------------------------------------------|--------------------| 
| thread:54|epoch:2|unused:1| age:4 | biased_lock:1 		|01| 				Biased 			| 
|----------------------------------------------------------|--------------------| 
| ptr_to_lock_record:62 														  	|00| Lightweight Locked | 
|----------------------------------------------------------|--------------------| 
| ptr_to_heavyweight_monitor:62												  |10| Heavyweight Locked | 
|----------------------------------------------------------|--------------------| 
| 																											|11| 		Marked for GC	  | 
|----------------------------------------------------------|--------------------|

参考资料

https://stackoverflow.com/questions/26357186/what-is-in-java-object-header

  • 原理之 Monitor(锁)

  • 原理之 synchronized

小故事

故事角色

  • 老王 - JVM
  • 小南 - 线程
  • 小女 - 线程
  • 房间 - 对象
  • 房间门上 - 防盗锁 - Monitor
  • 房间门上 - 小南书包 - 轻量级锁
  • 房间门上 - 刻上小南大名 - 偏向锁
  • 批量重刻名 - 一个类的偏向锁撤销到达 20 阈值
  • 不能刻名字 - 批量撤销该类对象的偏向锁，设置该类不可偏向

小南要使用房间保证计算不被其它人干扰（原子性），最初，他用的是防盗锁，当上下文切换时，锁住门。这样， 即使他离开了，别人也进不了门，他的工作就是安全的。

但是，很多情况下没人跟他来竞争房间的使用权。小女是要用房间，但使用的时间上是错开的，小南白天用，小女 晚上用。每次上锁太麻烦了，有没有更简单的办法呢？

小南和小女商量了一下，约定不锁门了，而是谁用房间，谁把自己的书包挂在门口，但他们的书包样式都一样，因 此每次进门前得翻翻书包，看课本是谁的，如果是自己的，那么就可以进门，这样省的上锁解锁了。万一书包不是 自己的，那么就在门外等，并通知对方下次用锁门的方式。

后来，小女回老家了，很长一段时间都不会用这个房间。小南每次还是挂书包，翻书包，虽然比锁门省事了，但仍 然觉得麻烦。

于是，小南干脆在门上刻上了自己的名字：【小南专属房间，其它人勿用】，下次来用房间时，只要名字还在，那 么说明没人打扰，还是可以安全地使用房间。如果这期间有其它人要用这个房间，那么由使用者将小南刻的名字擦 掉，升级为挂书包的方式。

同学们都放假回老家了，小南就膨胀了，在 20 个房间刻上了自己的名字，想进哪个进哪个。后来他自己放假回老 家了，这时小女回来了（她也要用这些房间），结果就是得一个个地擦掉小南刻的名字，升级为挂书包的方式。老 王觉得这成本有点高，提出了一种批量重刻名的方法，他让小女不用挂书包了，可以直接在门上刻上自己的名字

后来，刻名的现象越来越频繁，老王受不了了：算了，这些房间都不能刻名了，只能挂书包

  • 原理之 synchronized 进阶

5. wait/notify

小故事 - 为什么需要 wait

  • 由于条件不满足，小南不能继续进行计算
  • 但小南如果一直占用着锁，其它人就得一直阻塞，效率太低
  • 于是老王单开了一间休息室（调用 wait 方法），让小南到休息室（WaitSet）等着去了，但这时锁释放开， 其它人可以由老王随机安排进屋
  • 直到小M将烟送来，大叫一声 [ 你的烟到了 ] （调用 notify 方法）
  • 小南于是可以离开休息室，重新进入竞争锁的队列

*原理之 wait / notify

API 介绍

  • obj.wait() 让进入 object 监视器的线程（获得锁的线程）到 waitSet 等待
  • obj.wait(long 毫秒值)让进入 object 监视器的线程（获得锁的线程）到 waitSet 等待一定时间，时间到了后，自动被notify() ，或者时间到之前被其他线程唤醒
  • obj.notify() 在 object 上正在 waitSet 等待的线程中挑一个唤醒
  • obj.notifyAll() 让 object 上正在 waitSet 等待的线程全部唤醒

它们都是线程之间进行协作的手段，都属于 Object 对象的方法。必须获得此对象的锁，才能调用这几个方法

wait() 方法会释放对象的锁，进入 WaitSet 等待区，从而让其他线程就机会获取对象的锁。无限制等待，直到 notify 为止

6 wait notify 的正确姿势

先看看

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

1) sleep 是 Thread 方法，而 wait 是 Object 的方法

2) sleep 不需要强制和 synchronized 配合使用，但 wait 需要 和 synchronized 一起用

3) sleep 在睡眠的同时，不会释放对象锁的，但 wait 在等待的时候会释放对象锁

4) 它们 状态都是 TIMED_WAITING

  • sleep不释放锁，会阻塞其他线程，效率低，解决办法wait-notify
  • 虚假唤醒：wait只能随机叫醒一个线程，多个线程在等待时，无法叫醒指定线程
  • notifyAll叫醒了不该叫醒（或者称任然未满足条件的）的进程，也不好
  • obj.wait()区域用while包裹，另一个线程用obj,notifyAll(),如下

正确姿势 

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

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

Park和Unpark

基本使用

原理：

1个线程有1个Parker对象，由_cond，_counter，_mutex构成.

打个比喻：

  • 线程就像一个旅人，Parker相当于旅人的背包
  • _cond条件变量相当于背包中的帐篷
  • _counter相当于背包中的备用干粮(0为耗尽，1为充足)，背包容量有限
  • _mutext为互斥锁

调用unpark,就好比令干粮充足(_counter为1)

  • 如果线程还在帐篷，唤醒他继续前进
  • 如果线程在前进中，那下次调用park，仅是消耗掉备用干粮，线程不需休息继续前进
    • 因为背包容量，多次调用unpark也只能补充1份干粮(令_counter为1)

调用upark,会检查干粮

  • 如果备用干粮耗尽，则进入帐篷休息（获得_mutex互斥锁，进入_cond条件变量阻塞）
  • 如果备用干粮充足，则继续前进，并消耗掉干粮

多把锁

1个大房间有多个功能，睡觉和学习。

1把锁的话并发度低，设置(多个房间)多把锁，比如1个房间睡觉，1个房间自习 ，2把锁。

好处：增加并发度

坏处：1个线程要获取多把锁（资源），可能造成死锁

活跃性问题

死锁

1个线程持有了资源，又去申请资源， 申请资源的顺序不当可能导致死锁。

  • 定位死锁
  • 哲学家就餐

活锁

2个线程互相修改对方的结束条件，导致都无法结束。

饥饿

优先级低的任务总是得不到执行。

可重入锁ReentrantLock

特点

ReentrantLock lock = ReentrantLock lock = new ReentrantLock();

  1. 可重入：同一个线程多次调用(获取锁)reentrantLock.lock()，第一次调用获得锁后，后面的调用不会被阻塞住。

  2. 可打断：一个线程t1,在调用lock.lockInterruptibly()被阻塞住（获取锁失败）时，其他线程执行t1.interrupt()可以打断t1线程的等待，此时线程t1停止等待,抛出异常。

    注:如果是不可中断模式，那么即使使用了 interrupt 也不会让等待中断

  3. 锁超时：

    • tryLock()方法：尝试获取锁，如果获取失败，则立即返回false，不会阻塞

    • public boolean tryLock(long timeout, TimeUnit unit)throws InterruptedException

      尝试等待timeout时间获取锁，超时后立即返回

    应用：可用tryLock()解决哲学家就餐的死锁问题

  4. 公平锁：ReentrantLock默认是不公平的.

    1. 什么是公平与不公平？

      先启动的线程和后启动的线程在争抢锁时都是随机的，随CPU调度，先来的不能先获得锁/资源，这称之为不公平。反之则为公平，可以通过构造函数中传入参数设置为公平或者不公平

    2. 公平锁一般没有必要，会降低并发度

  5. 条件变量

    1. synchrnized中也有条件变量，就是那个waitSet休息室，条件不满足时进入waitSet等待

    2. ReentrantLock的强大在于支持多个条件变量，也就是有多个休息室,可以有专门等烟的，专门等早餐的

    3. 使用要点：

      static ReentrantLock lock = static ReentrantLock lock = new ReentrantLock(); 
static Condition waitCigaretteQueue = lock.newCondition(); 
static Condition waitbreakfastQueue = lock.newCondition();
...
waitCigaretteQueue.await();
...
...
waitCigaretteQueue.signal();
      • await前要获得锁,也就是调用lock.lock()
      • await执行后会释放锁，进入Conditionz对象中等待
      • await的线程被唤醒（被打断或超时）需重新竞争lock锁
      • 竞争lock锁成功后，从await后开始执行
并发编程
Java 并发编程

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！