并发编程之第三篇(synchronized)

2020-02-10 16:08:17来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

并发编程之第三篇(synchronized)

并发编程之第三篇(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<Message> 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 = value;
    }

    public int getId() {
        return id;
    }

    public Object getValue() {
        return value;
    }

    @Override
    public String toString() {
        return "Message{" +
                "id=" + id +
                ", value=" + value +
                '}';
    }
}

4.9 Park & Unpark

基本使用
它们是LockSupport类中的方法
在这里插入图片描述
先看park再unpark
在这里插入图片描述
输出
在这里插入图片描述
特点
与Object的wait&notify相比

  • 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仅会补充一份备用干粮
        在这里插入图片描述
  1. 当前线程调用Unsafe.park()方法

  2. 检查_counter,本情况为0,这时,获得_mutex互斥锁

  3. 线程进入_cond条件变量阻塞

  4. 设置_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

  • t线程用synchronized(obj)获取对象锁时如果竞争失败,从RUNNABLE --> BLOCKED
  • 持有obj锁线程的同步代码块执行完毕,会唤醒该对象上所有BLOCKED的线程重新竞争,如果其他t线程竞争成功,从BLOCKED --> RUNNABLE,其它失败的线程仍然BLOCKED

情况10 RUNNABLE < – > TERMINATED
当前线程所有代码运行完毕,进入TERMINATED


原文链接:https://www.cnblogs.com/haizai/p/12290276.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:解决Spring Security自定义filter重复执行问题

下一篇:tomcat8配置了tomcat-users.xml,报403 Access Denied