Week-1-Java-多线程-锁优化轻量级锁偏向锁原理及锁的状态流转

前言学习情况记录 时间:week 1SMART子目标 :Java 多线程记录在学习Java 多线程中 锁优化的有关知识点。 为了进一步改进高效并发,HotSpot虚拟机开发团队在JDK1.6版本上花费了大量精力实现各种锁优化。如适应性自旋、锁消除、锁粗化、轻量级锁和偏向锁等。(主要指的是synchronized的优化)。 适应性自旋 (自旋锁)为了让线程等待,我们只需要让线程执行一个忙循环(自旋),这项技术就是所谓的自旋锁。引入自旋锁的原因是互斥同步对性能最大的影响是阻塞的实现,管钱线程和恢复线程的操作都需要转入内核态中完成,给并发带来很大压力。自旋锁让物理机器有一个以上的处理器的时候,能让两个或以上的线程同时并行执行。我们就可以让后面请求锁的那个线程“稍等一下”,但不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁。为了让线程等待,我们只需让线程执行一个忙循环(自旋),这项技术就是所谓的自旋锁。 自旋锁虽然能避免进入阻塞状态从而减少开销,但是它需要进行忙循环操作占用 CPU 时间,它只适用于共享数据的锁定状态很短的场景。 在 JDK 1.6之前,自旋次数默认是10次,用户可以使用参数-XX:PreBlockSpin来更改。 JDK1.6引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。(这个应该属于试探性的算法)。 锁消除锁消除是指虚拟机即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行清除。锁清除的主要判定依据来源于逃逸分析的数据支持,如果判断在一段代码中,堆上的所有数据都不会逃逸出去从而被其他线程访问到,那就可以把它们当做栈上数据对待,认为它们是线程私有的,同步枷锁自然就无需进行。 简单来说,Java 中使用同步 来保证数据的安全性,但是对于一些明显不会产生竞争的情况下,Jvm会根据现实执行情况对代码进行锁消除以提高执行效率。 举例说明对于一些看起来没有加锁的代码,其实隐式的加了很多锁,这些也是锁消除优化的对象。例如下面的字符串拼接代码就隐式加了锁: String 是一个不可变的类,编译器会对 String 的拼接自动优化。在 JDK 1.5 之前,会转化为 StringBuffer 对象的连续 append() 操作: 每个 append() 方法中都有一个同步块。虚拟机观察变量 sb,很快就会发现它的动态作用域被限制在 concatString() 方法内部。也就是说,sb 的所有引用永远不会逃逸到 concatString() 方法之外,其他线程无法访问到它,因此可以进行消除。 锁粗化如果一系列的连续操作都对同一个对象反复加锁和解锁,频繁的加锁操作就会导致性能损耗。当多个彼此靠近的同步块可以合并到一起,形成一个同步块的时候,就会进行锁粗化。该方法还有一种变体,可以把多个同步方法合并为一个方法。如果所有方法都用一个锁对象,就可以尝试这种方法。轻量级锁 (@重点知识点)JDK 1.6 引入了偏向锁和轻量级锁,从而让锁拥有了四个状态:无锁状态(unlocked)、偏向锁状态(biasble)、轻量级锁状态(lightweight locked)和重量级锁状态(inflated)。 重量级排序 :重量级锁 > 轻量级锁 > 偏向锁 > 无锁 先介绍一下HotSpot 虚拟机对象头的内存布局: 上面这些数据被称为Mark Word - 标记关键词。 其中 tag bits 对应了五个状态,这些状态的含义在右侧的 state 表格中给出。除了 marked for gc 状态(gc标记状态),其它四个状态已经在前面介绍过了。 ...

July 8, 2019 · 1 min · jiezi

Week-1-Java-多线程-CAS

前言学习情况记录 时间:week 1SMART子目标 :Java 多线程记录在学习线程安全知识点中,关于CAS的有关知识点。 线程安全是指:多个线程不管以何种方式访问某个类,并且在主调代码中不需要进行同步,都能表现正确的行为。 常见的线程安全实现方法分为不可变对象、线程互斥同步、非阻塞同步、线程本地存储等方案,本文要讲的就是非阻塞同步中的核心CAS. 非阻塞同步从处理问题的方式上说,互斥同步属于一种悲观的并发策略。 随着硬件指令集的发展,我们可以采用基于冲突检查的乐观并发策略,通俗地说,就是先行操作,如果没有其他线程争用共享数据,那操作就成功了;如果共享数据有争用,产生了冲突,那就再采取其他的补偿措施(最常见的补偿措施就是不断地重试,直到成功为止),这种乐观的并发策略的许多实现偶读不需要把线程挂起,因此这种同步操作称为非阻塞同步。 CAS乐观锁需要操作和冲突检测这两个步骤具备原子性,这里就不能再使用互斥同步来保证了,只能靠硬件来完成。硬件支持的原子性操作最典型的是:比较并交换(Compare-and-Swap,CAS)。CAS 指令需要有 3 个操作数,分别是内存地址 V、旧的预期值 A 和新值 B。当执行操作时,只有当 V 的值等于 A,才将 V 的值更新为 B。 各种Atomic开头的原子类,内部都应用到了CAS。就拿AtomicInteger为例。 J.U.C 包里面的原子类 AtomicInteger 的方法调用了 Unsafe 类的 CAS 操作。 看看AtomicInteger对象一次自增,CAS起了什么作用,以下代码是 incrementAndGet() 的源码,可以看到内部调用了 Unsafe 对象的 getAndAddInt() 。 以下代码是 getAndAddInt()源码,var1 指示对象内存地址,var2指示该字段相对对象内存地址的偏移,var4 指示操作需要加的数值,这里为 1。通过 getIntVolatile(var1, var2) 得到旧的预期值,通过调用 compareAndSwapInt() 来进行 CAS 比较,如果该字段内存地址中的值等于 var5,那么就更新内存地址为 var1+var2 的变量为 var5+var4。 compareAndSwapInt(var1, var2, var5, var5 + var4 其实换成compareAndSwapInt(obj, offset, expect, update)比较清楚,意思就是如果obj内的value和expect相等,就证明没有其他线程改变过这个变量,那么就更新它为update,如果这一步的CAS没有成功,那就采用自旋的方式继续进行CAS操作,取出乍一看这也是两个步骤了啊,其实在JNI里是借助于一个CPU指令完成的。所以还是原子操作。 ...

July 8, 2019 · 1 min · jiezi

Week-1-Java-多线程-Java-内存模型

前言学习情况记录 时间:week 1SMART子目标 :Java 多线程学习Java多线程,要了解多线程可能出现的并发现象,了解Java内存模型的知识是必不可少的。 对学习到的重要知识点进行的记录。 注:这里提到的是Java内存模型,是和并发编程相关的,不是JVM内存结构(堆、方法栈这些概念),这两个不是一回事,别弄混了。 Java 内存模型Java内存模型(Java Memory Model ,JMM)就是一种符合内存模型规范的,屏蔽了各种硬件和操作系统的访问差异的,保证了Java程序在各种平台下对内存的访问都能得到一致效果的机制及规范。目的是解决由于多线程通过共享内存进行通信时,存在的原子性、可见性(缓存一致性)以及有序性问题。主内存与工作内存先看计算机硬件的缓存访问操作: 处理器上的寄存器的读写的速度比内存快几个数量级,为了解决这种速度矛盾,在它们之间加入了高速缓存。 加入高速缓存带来了一个新的问题:缓存一致性。如果多个缓存共享同一块主内存区域,那么多个缓存的数据可能会不一致,需要一些协议来解决这个问题。 Java的内存访问操作与上述的硬件缓存具有很高的可比性: Java内存模型中,规定了所有的变量都存储在主内存中,每个线程还有自己的工作内存,工作内存存储在高速缓存或者寄存器中,保存了该线程使用的变量的主内存副本拷贝。线程只能直接操作工作内存中的变量,不同线程之间的变量值传递需要通过主内存来完成。 内存间交互操作Java 内存模型定义了 8 个操作来完成主内存和工作内存的交互操作 read:把一个变量的值从主内存传输到线程的工作内存中load:在 read 之后执行,把 read 得到的值放入线程的工作内存的变量副本中use:把线程的工作内存中一个变量的值传递给执行引擎assign:把一个从执行引擎接收到的值赋给工作内存的变量store:把工作内存的一个变量的值传送到主内存中write:在 store 之后执行,把 store 得到的值放入主内存的变量中lock:作用于主内存的变量,把一个变量标识成一条线程独占的状态unlock: 作用于主内存的变量,把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定。内存模型三大特性原子性Java 内存模型保证了 read、load、use、assign、store、write、lock 和 unlock 操作具有原子性,例如对一个 int 类型的变量执行 assign 赋值操作,这个操作就是原子性的。但是 Java 内存模型允许虚拟机将没有被 volatile 修饰的 64 位数据(long,double)的读写操作划分为两次 32 位的操作来进行,也就是说基本数据类型的访问读写是原子性的,除了long和double是非原子性的,即 load、store、read 和 write 操作可以不具备原子性。书上提醒我们只需要知道有这么一回事,因为这个是几乎不可能存在的例外情况。 虽然上面说对基本数据类型的访问读写是原子性的,但是不代表在多线程环境中,如int类型的变量不会出现线程安全问题。详细的例子可以参考范例一。 想要保证原子性,可以尝试以下几种方式: 如果是基础类型的变量的话,使用Atomic类(例如AtomicInteger)其他情况下,可以使用synchronized互斥锁来保证 限定临界区 内操作的原子性。它对应的内存间交互操作为:lock 和 unlock,在虚拟机实现上对应的字节码指令为 monitorenter 和 monitorexit。可见性可见性指的是,当一个线程修改了共享变量中的值,其他线程能够立即得知这个修改。Java 内存模型是通过在变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量值来实现可见性的。 ...

July 7, 2019 · 2 min · jiezi

安全发布对像

发布对像定义: 是一个对象能够被当前范围之外的代码所使用对象溢出一种错误的发布。当一个对象该没有构造完成时,就使被其他线程所见。下面我们来看一下没有安全发布的对象 @Slf4jpublic class UnsafePublish { private String[] states = {"a", "b", "c"}; public String[] getStates() { return states; } public static void main(String[] args) { UnsafePublish unsafePublish = new UnsafePublish(); log.info("{}", Arrays.toString(unsafePublish.getStates())); unsafePublish.getStates()[0] = "d"; log.info("{}", Arrays.toString(unsafePublish.getStates())); }}我们看这段代码,我们创建了一个对象通过getStates方法我们可以获取这个对象的数组,此时我们将数组内容打印出来结果,如果此时我们将这个对象发布出去,然后其他线程(这里没有模拟其他线程对其修改)又对这个对象的states的值进行修改,此时在拿到这个对象的期望的是没有被修改的,事实上得到的对象是修改过后的。也就是说我们不能直接通过一个public的一个set方法就行return。 下面我们再看一段对象溢出的代码 public class ThisEscape { public ThisEscape(EventSource source) { source.registerListener(new EventListener() { public void onEvent(Event e) { doSomething(e); } }); } void doSomething(Event e) { } interface EventSource { void registerListener(EventListener e); } interface EventListener { void onEvent(Event e); } interface Event { }}这将导致this逸出,所谓逸出,就是在不该发布的时候发布了一个引用。在这个例子里面,当我们实例化ThisEscape对象时,会调用source的registerListener方法,这时便启动了一个线程,而且这个线程持有了ThisEscape对象(调用了对象的doSomething方法),但此时ThisEscape对象却没有实例化完成(还没有返回一个引用),所以我们说,此时造成了一个this引用逸出,即还没有完成的实例化ThisEscape对象的动作,却已经暴露了对象的引用。其他线程访问还没有构造好的对象,可能会造成意料不到的问题。 ...

May 9, 2019 · 1 min · jiezi

3分钟干货之详解线程池

线程池通过复用线程,避免线程频繁创建和销毁。Java的Executors工具类中,提供了5种类型线程池的创建方法,它们的特点和适用场景如下:第1种是:固定大小线程池,特点是线程数固定,使用无界队列,适用于任务数量不均匀的场景、对内存压力不敏感,但系统负载比较敏感的场景;第2种是:Cached线程池,特点是不限制线程数,适用于要求低延迟的短期任务场景;第3种是:单线程线程池,也就是一个线程的固定线程池,适用于需要异步执行但需要保证任务顺序的场景;第4种是:Scheduled线程池,适用于定期执行任务场景,支持按固定频率定期执行和按固定延时定期执行两种方式;第5种是:工作窃取线程池,使用的ForkJoinPool,是固定并行度的多任务队列,适合任务执行时长不均匀的场景。

April 16, 2019 · 1 min · jiezi