深入理解Java虚拟机----第十三章:线程安全与锁优化

目录

第一章:走进Java
第二章:Java内存区域与内存溢出异常
第三章:垃圾收集器与内存分配策略
第四章:虚拟机性能监控与故障处理
第五章:调优案例分析与实战
第六章:类文件结构
第七章:虚拟机类加载机制
第八章:虚拟机字节码执行引
第九章:类加载及其执行子系统的案例与实战
第十章:早期(编译器)优化
第十一章:晚期(运行期)优化
第十二章:Java内存模型与线程
第十三章:线程安全与锁优化

第十三章:线程安全与锁优化

13.1概述

13.2线程安全

当多个线程访问一个对象的时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方法进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象就是线程安全的

13.2.1Java语言中的线程安全

  1. 不可变

在Java语言里(特指JDK1.5以后),不可变(Immutable)的对象一定是线程安全的

不可变带来的线程安全是最简单和最纯粹的

如果共享数据是基本类型,只要定义时final修饰就可以保证不可变;

如果共享数据是一个对象,那就需要保证对象的行为不会对其状态产生任何影响才行

把对象带有状态的变量都声明为final

符合不可变数据类型:String,枚举类型,java.lang.Number的部分子类(Long和Double数值的包装类型,BigInteger和Bigmal等大数据类型)

  1. 绝对线程安全
  2. 相对线程安全

通常意义上将的线程安全,需要保证对这个对象的单独操作是线程安全的,我们在调用的时候不需要做额外的保障措施;

扫描二维码关注公众号,回复: 2733519 查看本文章

对于一些特定顺序的连续调用,就可能需要调用端使用额外的同步手段来保证调用的正确性

大多数线程安全的类属于这种类型,例如Vector、hashTable、Collections的synchronizedCollection()包装的集合等

  1. 线程兼容

对象本身并不是线程安全,但是可以通过调用端正确的使用同步手段来保证在并发环境中可以安全使用

  1. 线程对立

无论调用端是否采用同步手段,都无法再多线程环境中使用的代码

Thread类的suspend和resume方法

System.setIn()、System.setOut、System.runFinalizersOnExit

13.2.2线程安全的实现方式

  1. 互斥同步(阻塞同步)

常见的一种并发正确性的保障手段

同步指多个线程并发访问共享数据时,保证贡献数据在同一时刻只能被一个(或者是一些,使用信号量的时候)线程使用

互斥是实现同步的一种手段,临界区(Critical Section)、互斥量(Mutex)和信号量(Semaphore)都是互斥的实现方式

互斥是因,同步是果;互斥是方法,同步是目的

synchronized关键字

最基本的互斥同步手段就是synchronized关键字

synchronized关键字在编译后会生成monitorenter和monitorexit两条字节码指令,两条指令都需要一个reference类型的参数作为锁定和解锁的对象。如果明确指定了对象参数,那就是这个对象的reference;如果没有明确指定,那就是根据修饰的是实例方法还是类方法,去取对应的对象实例或者Class对象作为锁对象

synchronized对同一个线程来说是可重入的;同步块在已进入的线程执行完之前,会阻塞后面的线程

java.util.concurrent包中的ReentrantLock

  • 等待可中断:当持有锁的线程长期不释放锁的时候,等待的线程可以放弃等待,改为处理其他事情
  • 公平锁:多个线程等待同一个锁,必须按照申请锁的时间来依次获得锁,默认是非公共锁,可以通过参数使用
  • 锁绑定多个条件:可以同时绑定多个Condition对象

进行线程阻塞和唤醒带来性能问题;一种悲观的并发策略;

  1. 非阻塞同步

阻塞同步:互斥同步主要问题是进行线程阻塞和唤醒所带来的性能问题,这种同步称为阻塞同步。是一种悲观的并发策略,无论共享数据是否真的会出现竞争,都要加锁

非阻塞同步:基于冲突检测的乐观并发策略,先进行操作,如果没有其他线程争用共享数据,那操作就成功了;如果共享数据有争用,产生了冲突,那就再采取其他的补偿措施,这种同步称为非阻塞同步

操作和冲突检测这两个步骤要具备原子性

通过处理器指令来完成

  • 测试并设置(Test-and-Set)
  • 获取并增加(Fetch-and-Increment)
  • 交换(Swap)
  • 比较并交换(Compare-and-Swap,CAS)
  • 加载链接/条件存储(Load-Link/Store Conditional,LL/SC)

    1. 无同步方案

天生线程安全的

可重入代码(Reentrant Code)

如果一个方法,它的返回值是可以预测的,输入相同数据就能返回相同结果

线程本地存储(Thread Local Storage)

大部分使用消费队列的架构模式都会将产品的消费过程尽量在一个线程中完成

应用实例:经典的web交互模型(一个请求对应一个服务器线程)

Java.lang.ThreadLocal

13.3锁优化

为了在线程间更高效的共享数据,以及解决竞争问题,从而提高程序的执行效率

13.3.1自旋锁和自适应自旋

自旋锁:让后面请求锁的那个线程“稍等一下”,但不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁。为了让线程等待,让线程执行一个忙循环(自旋),这项技术就是所谓的自旋锁。

锁占用时间少,效果非常好;反之,白白的消耗处理器资源,反而带来性能浪费。

因此,给自旋限定次数,超过次数没有成功获得锁就挂起线程,默认10次,可通过

参数-XX:PreBlockSpin来更改

自适应的自旋锁:自旋时间不固定,由前一次在同一个锁上的自旋时间及锁的拥有者状态决定。

13.3.2锁消除

即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行消除

有许多同步措施并不是程序员自己加入

13.3.3锁粗化

问题:一般尽量把同步块的作用范围限制的尽量小,只在共享数据的实际作用域中才进行同步,这样是为了等待锁的线程也能尽快拿到锁。

但如果一系列的连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体中,那即使没有线程竞争,频繁进行同步操作会导致不必要的性能损耗

锁粗化:如果虚拟机探测到一串零碎的操作都对同一个对象加锁,将会把加锁同步的范围扩展(粗化)到整个操作序列的外部。

如StringBuffer的append()方法反复使用,就会扩展到第一个append()操作之前到最后一个append()操作之后,这样只需加一次锁就好了。

13.3.4轻量级锁

传统的锁机制称为“重量级”锁

目的:本意是在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗

13.3.5偏向锁

目的:消除数据在无竞争情况下的同步原语,进一步提高程序的运行性能。

如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量,那偏向锁就是在无竞争的情况下把整个同步都消除掉,连CAS操作都不做了。
第十三章

猜你喜欢

转载自blog.csdn.net/qq_36969257/article/details/81502162
今日推荐