并发编程之第三篇（synchronized）并发编程之第三篇（synchroniz

并发编程之第三篇（synchronized）

3. 自旋优化
4. 偏向锁
撤销-其它线程使用对象
撤销-调用wait/notify
批量重偏向
批量撤销
5. 锁消除
4.7 wait/notify
API介绍
4.8 wait notify的正确姿势
同步模式之保护性暂停
异步模式之生产者/消费者
4.9 Park & Unpark
原理之park & unpark
4.10 重新理解线程状态转换

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

文章图片
在这里插入图片描述自旋重试失败的情况

文章图片
在这里插入图片描述

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

4. 偏向锁轻量级锁在没有竞争时（就自己这个线程），每次重入任然需要执行CAS操作。
Java6中引入了偏向锁来做进一步优化：只有第一次使用CAS将线程ID设置到对象的Mark Word头，之后发现这个线程ID是自己的就表示没有竞争，不用重新CAS。以后只要不发生竞争，这个对象就归该线程所有
例如：

文章图片
在这里插入图片描述

文章图片
在这里插入图片描述偏向状态
回忆一下对象头格式

文章图片
在这里插入图片描述
一个对象创建时：

如果开启了偏向锁（默认开启），那么对象创建后，markword值为0x05即最后3位为101，这时它的thread、epoch、age都为0
偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加VM参数 -XX:BiasedLockingStartupDelay=0来禁用延迟
如果没有开启偏向锁，那么对象创建后，markwork值为0x01即最后3位为001，这时它的hashcode、age都为0，第一次用到hashcode时才会赋值
1）测试延迟特性
2）测试偏向锁
class Dog{}
利用jol第三方工具来查看对象头信息（注意这里我扩展了jol让它输出更为简洁）

文章图片
在这里插入图片描述输出

文章图片
在这里插入图片描述注意
处于偏向锁的对象解锁后，线程id任存储于对象头中
3）测试禁用
在上面测试代码运行时在添加VM参数 -xx: -UseBiasedLocking禁用偏向锁
输出

文章图片
在这里插入图片描述
4）测试hashcode
调用hashcode以后，会禁用偏向锁，因为对象头中没有地方存储偏向锁的线程id了。（hashcode为31位，thread为54位）
调用了对象的hashCode，但偏向锁的对象MarkWord中存储的是线程id，如果调用hashCode会导致偏向锁被撤销
轻量级锁会在锁记录中记录hashCode
重量级锁会在Monitor中记录hashCode
在调用hashCode后使用偏向锁，记得去掉 -xx: -UseBiasedLocking

文章图片
在这里插入图片描述输出

文章图片
在这里插入图片描述

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

文章图片
在这里插入图片描述

文章图片
在这里插入图片描述撤销-调用wait/notify 批量重偏向如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程T1的对象仍有机会重新偏向T2，重新偏向重置对象的Thread ID
当撤销偏向锁阈值超过20次后，jvm会这样觉得，我是不是偏向错了，于是会在给这些对象加锁时重新偏向至加锁线程

文章图片
在这里插入图片描述

文章图片
在这里插入图片描述批量撤销当撤销偏向锁阀值超过40次后，jvm会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的

文章图片
在这里插入图片描述

文章图片
在这里插入图片描述 5. 锁消除锁消除

文章图片
在这里插入图片描述

文章图片
在这里插入图片描述 4.7 wait/notify

文章图片
在这里插入图片描述

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

API介绍

obj.wait()让进入object监视器的线程到waitSet等待
obj.notify()在object上正在waitSet等待的线程中挑一个唤醒
obj。notifyAll()让object上正在waitSet等待的线程全部唤醒
它们都是线程之间进行协作的手段，都属于Object对象的方法。必须获得此对象的锁，才能调用这几个方法

文章图片
在这里插入图片描述
文章图片
在这里插入图片描述

4.8 wait notify的正确姿势 sleep（long n）和wait（long n）的区别
1）sleep是Thread方法，而wait是Object的方法
2）sleep不需要强制和synchronized配合使用，但wait需要和synchronized一起用
3）sleep在睡眠的同时，不会释放对象锁的，但wait在等待的时候会释放对象锁
4）它们状态都是TIMED_WAITING

文章图片
在这里插入图片描述 wait和notify正确使用姿势

文章图片
在这里插入图片描述同步模式之保护性暂停即Guarded Suspension，用在一个线程待得另一个线程的执行结果
要点

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

文章图片
在这里插入图片描述
文章图片
在这里插入图片描述

异步模式之生产者/消费者要点

与前面的保护性暂停中的GuardObject不同，不需要产生结果和消费结果的线程一一对应
消费队列可以用来平衡生产和消费的线程资源
生产者仅负责生产结果数据，不关心数据该如何处理，而消费者专心处理结果数据
消息队列是有容量限制的，满时不会再加入数据空时不会再消耗数据
JDK中各种阻塞队列，采用的就是这种模式

文章图片
在这里插入图片描述

package com.example.demo; import lombok.extern.slf4j.Slf4j; import java.util.LinkedList; @Slf4j() public class Test1 {public static void main(String[] args) { MessageQueue messageQueue = new MessageQueue(2); for (int i = 0; i < 3; i++) { int id = i; new Thread(() -> { messageQueue.put(new Message(id, "值" + id)); }, "生产者" + i).start(); }new Thread(() -> { while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } Message take = messageQueue.take(); } }, "消费者").start(); }}/** * 消息队列类，java线程之间通信 */ @Slf4j(topic = "cn.Message") class MessageQueue {/** * 消息的队列集合 */ private LinkedList linkedList = new LinkedList<>(); /** * 队列容量 */ private int capcity; public MessageQueue(int capcity) { this.capcity = capcity; }/** * 获取消息 */ public Message take() { // 检查对象是否为空 synchronized (linkedList) { while (linkedList.isEmpty()) { try { log.info("队列为空，消费者线程等待"); linkedList.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } // 从队列头部获取消息并返回 Message message = linkedList.removeFirst(); log.info("已消费消息： {}", message); linkedList.notifyAll(); return message; } }/** * 存入消息 */ public void put(Message message) { synchronized (linkedList) { // 检查对象是否已满 while (linkedList.size() == capcity) { try { log.info("队列已满，生产者线程等待"); linkedList.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } // 将消息添加到队列的尾部 linkedList.addLast(message); log.info("已生产消息： {}", message); linkedList.notifyAll(); } } }class Message { private int id; private Object value; public Message(int id, Object value) { this.id = id; this.value = https://www.it610.com/article/value; }public int getId() { return id; }public Object getValue() { return value; }@Override public String toString() { return"Message{" + "id=" + id + ", value="https://www.it610.com/article/+ value +'}'; } }

4.9 Park & Unpark 基本使用
它们是LockSupport类中的方法

文章图片
在这里插入图片描述先看park再unpark

文章图片
在这里插入图片描述输出

文章图片
在这里插入图片描述特点
与Object的wait¬ify相比

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

原理之park & unpark 每个线程都有自己的一个Parker对象，由三部分组成_counter,_cond和_mutex打个比喻

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

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

文章图片
在这里插入图片描述
1. 调用Unsafe.unpark（Thread_0）方法，设置_counter为1
2. 唤醒_cond条件变量中的Thread_0
3. Thread_0恢复运行
4. 设置_counter为0
  
  文章图片
  在这里插入图片描述 1.调用Unsafe.unpark(Thread_0)方法，设置_counter为1
  2.当前线程调用Unsafe.park()方法
  3.检查_counter，本情况为1，这时线程无需阻塞，继续运行
  4.设置_counter为0

4.10 重新理解线程状态转换

文章图片
在这里插入图片描述假设有线程Thread t
情况1 New --》RUNNABLE

当调用 t.start()方法时，由NEW --》RUNNABLE

情况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

情况5 RUNNABLE < – > TIMED_WAITING
t线程用synchronized（obj）获取了对象锁后

调用obj.wait(long n)方法时，t线程从RUNNABLE --> TIMED_WAITING
- 竞争锁成功，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 RUNABLE < – > 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

情况9 RUNNABLE <–>BLOCKED