关于java:synchronized基本概念

设计同步器的意义
多线程编程中，有可能会呈现多个线程同时拜访同一个共享、可变资源的状况，这个资源咱们称之其为临界资源；这种资源可能是：
对象、变量、文件等。
共享：资源能够由多个线程同时拜访
可变：资源能够在其生命周期内被批改
引出的问题：
因为线程执行的过程是不可控的，所以须要采纳同步机制来协同对对象可变状态的拜访！
如何解决线程并发平安问题？
实际上，所有的并发模式在解决线程平安问题时，采纳的计划都是序列化拜访临界资源。即在同一时刻，只能有一个线程拜访临
界资源，也称作同步互斥拜访。
Java 中，提供了两种形式来实现同步互斥拜访：synchronized 和 Lock
同步器的实质就是加锁
加锁目标：序列化拜访临界资源，即同一时刻只能有一个线程拜访临界资源(同步互斥拜访)
不过有一点须要区别的是：当多个线程执行一个办法时，该办法外部的局部变量并不是临界资源，因为这些局部变量是在每个线程的
公有栈中，因而不具备共享性，不会导致线程平安问题。

synchronized原理详解
synchronized内置锁是一种对象锁(锁的是对象而非援用)，作用粒度是对象，能够用来实现对临界资源的同步互斥拜访，是可
重入的。
加锁的形式：
1、同步实例办法，锁是以后实例对象
2、同步类办法，锁是以后类对象
3、同步代码块，锁是括号外面的对象

synchronized底层原理
synchronized是基于JVM内置锁实现，通过外部对象Monitor(监视器锁)实现，基于进入与退出Monitor对象实现办法与代码
块同步，监视器锁的实现依赖底层操作系统的Mutex lock（互斥锁）实现，它是一个重量级锁性能较低。当然，JVM内置锁在1.5
之后版本做了重大的优化，如锁粗化（Lock Coarsening）、锁打消（Lock Elimination）、轻量级锁（Lightweight Locking）、偏差锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来缩小锁操作的开销，，内置锁的并发性能曾经根本与
Lock持平。
synchronized关键字被编译成字节码后会被翻译成monitorenter 和 monitorexit 两条指令别离在同步块逻辑代码的起始地位
与完结地位。

每个同步对象都有一个本人的Monitor(监视器锁)，加锁过程如下图所示：

Monitor监视器锁
任何一个对象都有一个Monitor与之关联，当且一个Monitor被持有后，它将处于锁定状态。Synchronized在JVM里的实现都是
基于进入和退出Monitor对象来实现办法同步和代码块同步，尽管具体实现细节不一样，然而都能够通过成对的MonitorEnter和
MonitorExit指令来实现。
monitorenter：每个对象都是一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行
monitorenter指令时尝试获取monitor的所有权，过程如下：
a. 如果monitor的进入数为0，则该线程进入monitor，而后将进入数设置为1，该线程即为monitor
的所有者；
b. 如果线程曾经占有该monitor，只是从新进入，则进入monitor的进入数加1；
c. 如果其余线程曾经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再从新尝
试获取monitor的所有权；
monitorexit：执行monitorexit的线程必须是objectref所对应的monitor的所有者。指令执行时，monitor的进入数减
1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其余被这个monitor阻塞的线程能够尝试去
获取这个 monitor 的所有权。
monitorexit，指令呈现了两次，第1次为同步失常退出开释锁；第2次为产生异步退出开释锁；
通过下面两段形容，咱们应该能很分明的看出Synchronized的实现原理，Synchronized的语义底层是通过一个monitor的对象来
实现，其实wait/notify等办法也依赖于monitor对象，这就是为什么只有在同步的块或者办法中能力调用wait/notify等办法，否则
会抛出java.lang.IllegalMonitorStateException的异样的起因。
看一个同步办法：

monitorexit，指令呈现了两次，第1次为同步失常退出开释锁；第2次为产生异步退出开释锁；
通过下面两段形容，咱们应该能很分明的看出Synchronized的实现原理，Synchronized的语义底层是通过一个monitor的对象来
实现，其实wait/notify等办法也依赖于monitor对象，这就是为什么只有在同步的块或者办法中能力调用wait/notify等办法，否则
会抛出java.lang.IllegalMonitorStateException的异样的起因。
看一个同步办法：

package it.yg.juc.sync;
public class SynchronizedMethod {
 public synchronized void method() {
   System.out.println("Hello World!");
 }
}

反编译后果

从编译的后果来看，办法的同步并没有通过指令 monitorenter 和 monitorexit 来实现（实践上其实也能够通过这两条指令来
实现），不过绝对于一般办法，其常量池中多了 ACC_SYNCHRONIZED 标示符。JVM就是依据该标示符来实现办法的同步的：
当办法调用时，调用指令将会查看办法的 ACC_SYNCHRONIZED 拜访标记是否被设置，如果设置了，执行线程将先获取
monitor，获取胜利之后能力执行办法体，办法执行完后再开释monitor。在办法执行期间，其余任何线程都无奈再取得同一个
monitor对象。
两种同步形式实质上没有区别，只是办法的同步是一种隐式的形式来实现，无需通过字节码来实现。两个指令的执行是JVM通
过调用操作系统的互斥原语mutex来实现，被阻塞的线程会被挂起、期待从新调度，会导致“用户态和内核态”两个态之间来回切
换，对性能有较大影响。
什么是monitor？
能够把它了解为一个同步工具，也能够形容为一种同步机制，它通常被形容为一个对象。与所有皆对象一样，所有的Java对象
是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中，每一个Java对象自打娘胎里进去就带了一把
看不见的锁，它叫做外部锁或者Monitor锁。也就是通常说Synchronized的对象锁，MarkWord锁标识位为10，其中指针指向的
是Monitor对象的起始地址。在Java虚拟机（HotSpot）中，Monitor是由ObjectMonitor实现的，其次要数据结构如下（位于
HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）：

ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保留ObjectWaiter对象列表（每个期待锁的线程都会被封装成
ObjectWaiter对象），_owner指向持有ObjectMonitor对象的线程，当多个线程同时拜访一段同步代码时：

首先会进入 _EntryList 汇合，当线程获取到对象的monitor后，进入 _Owner区域并把monitor中的owner变量设置为当
火线程，同时monitor中的计数器count加1；
若线程调用 wait() 办法，将开释以后持有的monitor，owner变量复原为null，count自减1，同时该线程进入 WaitSet
汇合中期待被唤醒；
若以后线程执行结束，也将开释monitor（锁）并复位count的值，以便其余线程进入获取monitor(锁)；
同时，Monitor对象存在于每个Java对象的对象头Mark Word中（存储的指针的指向），Synchronized锁便是通过这种形式
获取锁的，也是为什么Java中任意对象能够作为锁的起因，同时notify/notifyAll/wait等办法会应用到Monitor锁对象，所以必须在同步代码块中应用。监视器Monitor有两种同步形式：互斥与合作。多线程环境下线程之间如果须要共享数据，须要解决互斥拜访
数据的问题，监视器能够确保监视器上的数据在同一时刻只会有一个线程在拜访。
那么有个问题来了，咱们晓得synchronized加锁加在对象上，对象是如何记录锁状态的呢？答案是锁状态是被记录在每个对象
的对象头（Mark Word）中，上面咱们一起认识一下对象的内存布局

对象的内存布局
HotSpot虚拟机中，对象在内存中存储的布局能够分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充
（Padding）。
对象头：比方 hash码，对象所属的年代，对象锁，锁状态标记，偏差锁（线程）ID，偏差工夫，数组长度（数组对象）
等。Java对象头个别占有2个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit，在64位虚拟机中，1个机器码
是8个字节，也就是64bit），然而如果对象是数组类型，则须要3个机器码，因为JVM虚拟机能够通过Java对象的元数据信
息确定Java对象的大小，然而无奈从数组的元数据来确认数组的大小，所以用一块来记录数组长度。
实例数据：寄存类的属性数据信息，包含父类的属性信息；
对齐填充：因为虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐；

对象头
HotSpot虚拟机的对象头包含两局部信息，第一局部是“Mark Word”，用于存储对象本身的运行时数据，如哈希码
（HashCode）、GC分代年龄、锁状态标记、线程持有的锁、偏差线程ID、偏差工夫戳等等，它是实现轻量级锁和偏差锁的关
键。，这部分数据的长度在32位和64位的虚拟机（暂不思考开启压缩指针的场景）中别离为32个和64个Bits，官网称它为“Mark
Word”。对象须要存储的运行时数据很多，其实曾经超出了32、64位Bitmap构造所能记录的限度，然而对象头信息是与对象本身
定义的数据无关的额外存储老本，思考到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储
尽量多的信息，它会依据对象的状态复用本人的存储空间。例如在32位的HotSpot虚拟机中对象未被锁定的状态下，Mark Word的
32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标记位，1Bit固定为
0，在其余状态（轻量级锁定、重量级锁定、GC标记、可偏差）下对象的存储内容如下表所示。
然而如果对象是数组类型，则须要三个机器码，因为JVM虚拟机能够通过Java对象的元数据信息确定Java对象的大小，然而无
法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。
对象头信息是与对象本身定义的数据无关的额定存储老本，然而思考到虚拟机的空间效率，Mark Word被设计成一个非固定的
数据结构以便在极小的空间内存存储尽量多的数据，它会依据对象的状态复用本人的存储空间，也就是说，Mark Word会随着程序
的运行发生变化。
变动状态如下：
32位虚拟机

64位虚拟机

当初咱们虚拟机根本是64位的，而64位的对象头有点节约空间,JVM默认会开启指针压缩，所以基本上也是按32位的模式记录对象头
的。

手动设置‐XX:+UseCompressedOops

哪些信息会被压缩？
1.对象的全局动态变量(即类属性)
2.对象头信息：64位平台下，原生对象头大小为16字节，压缩后为12字节
3.对象的援用类型：64位平台下，援用类型自身大小为8字节，压缩后为4字节
4.对象数组类型：64位平台下，数组类型自身大小为24字节，压缩后16字节
在Scott oaks写的《java性能权威指南》第八章8.22节提到了当heap size堆内存大于32GB是用不了压缩指针的，对象援用会额
外占用20%左右的堆空间，也就意味着要38GB的内存才相当于开启了指针压缩的32GB堆空间。
这是为什么呢？看上面援用中的红字（来自openjdk wiki：
https://wiki.openjdk.java.net…）。32bit最大寻址空间是4GB，开启了压缩指针之后呢，一
个地址寻址不再是1byte，而是8byte，因为不论是32bit的机器还是64bit的机器，java对象都是8byte对齐的，而类是java中的根本
单位，对应的堆内存中都是一个一个的对象。

对象头剖析工具
运行时对象头锁状态剖析工具JOL，他是OpenJDK开源工具包，引入下方maven依赖

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.10</version>
</dependency>

打印markword

System.out.println(ClassLayout.parseInstance(object).toPrintable());

object为咱们的锁对象

锁的收缩降级过程
锁的状态总共有四种，无锁状态、偏差锁、轻量级锁和重量级锁。随着锁的竞争，锁能够从偏差锁降级到轻量级锁，再降级的重
量级锁，然而锁的降级是单向的，也就是说只能从低到高降级，不会呈现锁的降级。从JDK 1.6 中默认是开启偏差锁和轻量级锁
的，能够通过-XX:-UseBiasedLocking来禁用偏差锁。下图为锁的降级全过程：

偏差锁
偏差锁是Java 6之后退出的新锁，它是一种针对加锁操作的优化伎俩，通过钻研发现，在大多数状况下，锁不仅不存在多线程竞
争，而且总是由同一线程屡次取得，因而为了缩小同一线程获取锁(会波及到一些CAS操作,耗时)的代价而引入偏差锁。偏差锁的外围
思维是，如果一个线程取得了锁，那么锁就进入偏差模式，此时Mark Word 的构造也变为偏差锁构造，当这个线程再次申请锁时，
无需再做任何同步操作，即获取锁的过程，这样就省去了大量无关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争
的场合，偏差锁有很好的优化成果，毕竟极有可能间断屡次是同一个线程申请雷同的锁。然而对于锁竞争比拟强烈的场合，偏差锁就
生效了，因为这样场合极有可能每次申请锁的线程都是不雷同的，因而这种场合下不应该应用偏差锁，否则会得失相当，须要留神的
是，偏差锁失败后，并不会立刻收缩为重量级锁，而是先降级为轻量级锁。上面咱们接着理解轻量级锁。
默认开启偏差锁

开启偏差锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
敞开偏差锁：-XX:-UseBiasedLocking

轻量级锁
假使偏差锁失败，虚拟机并不会立刻降级为重量级锁，它还会尝试应用一种称为轻量级锁的优化伎俩(1.6之后退出的)，此时
Mark Word 的构造也变为轻量级锁的构造。轻量级锁可能晋升程序性能的根据是“对绝大部分的锁，在整个同步周期内都不存在竞
争”，留神这是教训数据。须要理解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间拜访同一锁的场
合，就会导致轻量级锁收缩为重量级锁。
自旋锁
轻量级锁失败后，虚拟机为了防止线程实在地在操作系统层面挂起，还会进行一项称为自旋锁的优化伎俩。这是基于在大多数情
况下，线程持有锁的工夫都不会太长，如果间接挂起操作系统层面的线程可能会得失相当，毕竟操作系统实现线程之间的切换时须要
从用户态转换到外围态，这个状态之间的转换须要绝对比拟长的工夫，工夫老本绝对较高，因而自旋锁会假如在不久未来，以后的线
程能够取得锁，因而虚构机会让以后想要获取锁的线程做几个空循环(这也是称为自旋的起因)，个别不会太久，可能是50个循环或
100循环，在通过若干次循环后，如果失去锁，就顺利进入临界区。如果还不能取得锁，那就会将线程在操作系统层面挂起，这就是
自旋锁的优化形式，这种形式的确也是能够晋升效率的。最初没方法也就只能降级为重量级锁了。
锁打消
打消锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编译时(能够简略了解为当某段代码行将第一次被执行时
进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种形式打消没有必要的锁，能够
节俭毫无意义的申请锁工夫，如下StringBuffer的append是一个同步办法，然而在add办法中的StringBuffer属于一个局部变量，并
且不会被其余线程所应用，因而StringBuffer不可能存在共享资源竞争的情景，JVM会主动将其锁打消。锁打消的根据是逃逸剖析的
数据反对。
锁打消，前提是java必须运行在server模式（server模式会比client模式作更多的优化），同时必须开启逃逸剖析
:-XX:+DoEscapeAnalysis 开启逃逸剖析
-XX:+EliminateLocks 示意开启锁打消。
逃逸剖析
应用逃逸剖析，编译器能够对代码做如下优化：
一、同步省略。如果一个对象被发现只能从一个线程被拜访到，那么对于这个对象的操作能够不思考同步。
二、将堆调配转化为栈调配。如果一个对象在子程序中被调配，要使指向该对象的指针永远不会逃逸，对象可能是栈调配的候选，而不是堆分
配。三、拆散对象或标量替换。有的对象可能不须要作为一个间断的内存构造存在也能够被拜访到，那么对象的局部（或全副）能够不存储在内存，
而是存储在CPU寄存器中。
是不是所有的对象和数组都会在堆内存调配空间？
不肯定
在Java代码运行时，通过JVM参数可指定是否开启逃逸剖析， -XX:+DoEscapeAnalysis ：示意开启逃逸剖析 -XX:-
DoEscapeAnalysis ：示意敞开逃逸剖析。从jdk 1.7开始曾经默认开启逃逸剖析，如需敞开，须要指定-XX:-DoEscapeAnalysis
对于逃逸剖析的案例论证见Git课程源码

package com.yg.edu;



public class T0_ObjectStackAlloc {


    /**
     * 进行两种测试
     * 敞开逃逸剖析，同时调大堆空间，防止堆内GC的产生，如果有GC信息将会被打印进去
     * VM运行参数：-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
     *
     * 开启逃逸剖析
     * VM运行参数：-Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
     *
     * 执行main办法后
     * jps 查看过程
     * jmap -histo 过程ID
     */
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 500000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        //查看执行工夫
        System.out.println("cost-time " + (end - start) + " ms");
        try {
            Thread.sleep(100000);
        } catch (InterruptedException e1) {
            e1.printStackTrace();
        }
    }


    private static TulingStudent alloc() {
        //Jit对编译时会对代码进行 逃逸剖析
        //并不是所有对象寄存在堆区，有的一部分存在线程栈空间
        TulingStudent student = new TulingStudent();
        return student;
    }


    static class TulingStudent {
        private String name;
        private int age;
    }
}

关于java:synchronized基本概念

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于java:synchronized基本概念

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复