Java juc系列2 —— synchronized关键字

最新推荐文章于 2024-03-30 14:33:36 发布

see the future

最新推荐文章于 2024-03-30 14:33:36 发布

阅读量226

点赞数

分类专栏： java#java.util.concurrent

本文链接：https://blog.csdn.net/qq_26023163/article/details/107384104

版权

java#java.util.concurrent 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

Java JUC系列目录链接

Java juc系列2 —— synchronized关键字

JDK1.5后的synchronized

JDK1.5后的synchronized

Java多线程 synchronized关键字的用法

我们都知道synchronized时Java中的一种锁，他可以锁对象，锁方法，锁代码块。
下面是个简单的例子。

public class Test {

    public static void main(String[] args) {
        test1();
        test2();
        test3();
    }

    public synchronized static void test1() {
        doSomething();
    }

    public static void test2() {
        synchronized (Test.class) {
            doSomething();
        }
    }

    public static void test3() {
        synchronized (new A()) {
            doSomething();
        }
    }

    public static void doSomething() {}
    static class A {}
}

JAVA对象组成结构

在说synchronized关键字之前，我们先来说说一个对象在JVM中的简单构成。
首先介绍一个工具：
openjdk.jol
我们使用这个类可以看到一个Java对象的完整布局。
具体使用图下：

public class Test {

    public static class User {
        String Name;
        boolean sex;
    }
    public static void main(String[] args) {
        User user = new User();
        System.out.println("hashCode: "+Integer.toHexString(user.hashCode()));

        System.out.println(ClassLayout.parseInstance(user).toPrintable());
    }
}

我们定义了一个User对象，它有两个成员变量：String和boolean。
接下来直接运行：控制台的输出如下

hashCode: 15db9742
com.example.Test$User object internals:
 OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
      0     4                    (object header)                           01 42 97 db (00000001 01000010 10010111 11011011) (-610844159)
      4     4                    (object header)                           15 00 00 00 (00010101 00000000 00000000 00000000) (21)
      8     4                    (object header)                           43 c0 00 f8 (01000011 11000000 00000000 11111000) (-134168509)
     12     1            boolean User.sex                                  false
     13     3                    (alignment/padding gap)                  
     16     4   java.lang.String User.Name                                 null
     20     4                    (loss due to the next object alignment)
Instance size: 24 bytes
Space losses: 3 bytes internal + 4 bytes external = 7 bytes total

这里暂时我们只需要看前面两行的(object header).
有人会说，为什么这里我们User对象的对象头只有12个字节？

首先我们这里讨论的是win X64JVM，X86的结构不同是很正常的
win X64JVM默认开启了指针压缩，你可以使用JVM运行参数-XX:-UseCompressedOops来禁用指针压缩
如果你禁用了指针压缩，控制台的输出如下：

hashCode: 15db9742
com.example.Test$User object internals:
 OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
      0     4                    (object header)                           01 42 97 db (00000001 01000010 10010111 11011011) (-610844159)
      4     4                    (object header)                           15 00 00 00 (00010101 00000000 00000000 00000000) (21)
      8     4                    (object header)                           80 0a 39 1c (10000000 00001010 00111001 00011100) (473500288)
     12     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
     16     1            boolean User.sex                                  false
     17     7                    (alignment/padding gap)                  
     24     8   java.lang.String User.Name                                 null
Instance size: 32 bytes
Space losses: 7 bytes internal + 0 bytes external = 7 bytes total

这样就变成你熟悉的对象头16字节了。

为什么我们这里只讨论前面的两行（即前64位），我们掏出hotspot虚拟机源码：markOop.hpp来看，这里我们选取一部分代码：

// The markOop describes the header of an object.
//
// Note that the mark is not a real oop but just a word.
// It is placed in the oop hierarchy for historical reasons.
//
// Bit-format of an object header (most significant first, big endian layout below):
//
//  32 bits:
//  --------
//             hash:25 ------------>| age:4    biased_lock:1 lock:2 (normal object)
//             JavaThread*:23 epoch:2 age:4    biased_lock:1 lock:2 (biased object)
//             size:32 ------------------------------------------>| (CMS free block)
//             PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)
//
//  64 bits:
//  --------
//  unused:25 hash:31 -->| unused:1   age:4    biased_lock:1 lock:2 (normal object)
//  JavaThread*:54 epoch:2 unused:1   age:4    biased_lock:1 lock:2 (biased object)
//  PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object)
//  size:64 ----------------------------------------------------->| (CMS free block)
//
//  unused:25 hash:31 -->| cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && normal object)
//  JavaThread*:54 epoch:2 cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && biased object)
//  narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object)
//  unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)

在这里我们可以直接看到hotspot虚拟机在64位和32位系统上对象头的区别。
其中64bits (normal object，普通对象)写的很明白：

低2位表示lock(锁标志位)
低3位表示biased_lock（偏向锁标志位）
低4位到低7位表示age（分代年龄）
低8位unused（未使用）
低9位以上的31位，即到39位表示hash（存放hashcode）
剩余25位unused（未使用）
这里我们联系上面的代码来验证一下：
我们控制台的输出的前两行如下：

  
00000001——>01000010——>10010111——>11011011——> 
00010101——>00000000——>00000000——>00000000
这里我们注意一下二进制的低位顺序是按箭头方向

对比上面的注释再看：

低2位(00)表示锁状态
低3位(0)表示偏向锁标志位
低4位到低7位(0000)表示分代年龄
低8位(0)未使用
低9位以上的31位(01000010 10010111 11011011 0010101注意最后8位的高位0不是)表示hashcode，我们把它转化成16进制再看：（42 97 db 15）,我们把它从高位到地位写:15db9742,这个不就是我们的user对象的hashCode的十六进制嘛。

如果我们对象加锁，那么它的这64bit代表的含义就会发生变化。继续看64bits (biased object,偏向对象)

低2位表示lock(锁标志位)
低3位表示biased_lock（偏向锁标志位）
低4位到低7位表示age（分代年龄）
低8位unused（未使用）
低9位到低10位表示epoch
剩余54位表示JavaThread*(指向Java线程帧栈的指针)
这个我们下面会详细说。

对象的多种锁状态

好了又来了，又有三种锁要记了。。
别慌，听我把整个过程详细讲解一遍你就都懂了。
其实我们说的这么多锁准确来是不说不同的锁，而是对象为了获取锁而产生的不同状态。
这里就涉及到了锁的升级：

对象想要获取锁会依次尝试偏向锁，轻量级锁，自旋锁最后采用重量级锁。这个过程我们在下面详细阐述。

所以，锁的升级过程：

无锁—>偏向锁—>轻量级锁 —>自旋锁—>重量级锁

为什么要采用锁的升级？

JVM会尝试为对象采用最低代价的锁，以此来增加性能（仅适用于JDK1.5之后）

锁的升级过程

这里我们总结一下markOop.hpp里面的注释，为了下面更好的理解，这里我们选择图表
markword含义

无锁—>偏向锁

1.当一个线程开始使用对象时，如果这个对象是无锁状态，即图表中锁状态位为“01”，偏向锁标志位为“0”时，JVM首先会尝试在此对象上加上偏向锁
2.JVM会将对象的偏向锁标志位设置为1，在线程的栈中新建一块锁记录（Lock Record）的空间，将原对象头中的数据(hashcode,31bit)复制一份副本到锁记录空间中，将JavaThread指针指向占有该对象的线程。值得一提的是，这个过程JVM是采用CAS（有点像你们熟悉的乐观锁机制）实现的，所以还剩下的epoch当然就是时间戳（也可能是version，明白就好）啦。
3.如果CAS更新JavaThread指针失败，代表该锁已经被其他线程抢占，此时会触发偏向锁升级。

一些扩展的点：

对于某个只可能被同一个线程使用的锁，加偏向锁性能消耗是所有锁中最小的(因为只需要判断锁当前处于偏向锁状态且Thread指针指向当前线程就行了)。当同一个线程再次访问对象时，如果已经占有这个锁，那什么都不需要做就能直接使用了。
默认JDK1.6之后开启此锁，并且是延时开启（好像是8秒？记不太清了）。至于原因我想你们应该知道了：偏向锁加锁采用CAS，JVM刚启动线程较多，可能会产生CAS多次失败的情况，反而降低了性能。

这样，该对象就已经被线程占有了。值得一提的是，由于JVM的偏向锁加锁是采用CAS机制，所以在单线程访问该对象时性能较高（自己抢到的锁后面直接用呀）。

偏向锁—>轻量级锁

1.当多个线程访问有偏向锁的对象时（同理判断锁状态位和偏向锁标志位），此时就会发生偏向锁的升级(需要占用锁的线程将锁markword中的JavaThread指针修改为当前占有锁的线程帧栈指针，以此来区分该锁已经升级为轻量级锁)。
2.每个试图抢占轻量级锁的线程会在线程的栈中新建一块锁记录（Lock Record）的空间，将原对象头中的数据(61bit)复制一份副本到锁记录空间中，用来备份对象即将被覆盖的数据,因为一会儿要把对象头中原来存放hashCode和分代年龄的位置挪出来放别的地方啦。
3.此时再次使用CAS来更新线程帧栈指针,使其指向线程栈的锁记录空间。如果更新成功了，那么此时的对象就是轻量级锁状态。如果更新失败则表明这个对象已经被其他线程抢占了，此时就会继续发生锁升级(因为频繁的CAS降低了性能)。

轻量级锁 —>自旋锁(某种意义上这只是一种自旋的状态，并不叫锁)

如果轻量级锁占有失败，此时会进入自旋锁(有些文献中不把这个定义为新的锁类型，只是说处于自旋状态)

什么是自旋状态？看下面这个伪代码，这就是经典的自旋。所谓自旋就是循环等待，直到抢占锁为止


public void waitLock(){
        while(true){
            if(flag){
                //抢占到锁
                break;
            }else{
                //继续等待
            }
        }
    }

那有人就要问了，你这总是循环，岂不是白白浪费了CPU资源？
这里我们就需要引入线程内核态和用户态的切换了。

-- 当线程运行时是处于用户态的，而线程因为某些原因阻塞（常见的IO）会转而进入内核态。
-- 这两个状态之间的转换其实就是线程从运行到阻塞之间的切换，而这种转换过程其实是是非消耗性能的。
-- 如果线程抢占轻量级锁失败，并且等待时间可能不是很长的情况下，此时直接进入重量级锁会导致所有
    等待的线程进入阻塞状态，即用户态转换到内核态，在抢占到锁之后又会从内核态转换到用户态，整个
    过程是比较消耗性能的。

现在你明白为什么需要有自旋状态了把。
但是自旋状态也是有缺点的：

1.如果处于自旋状态时间过长，即处于近似死循环状态，对CPU的压力会比较大，持续消耗CPU资源。因此如果自旋时间超时，就会进入下一个升级阶段，升级至重量级锁。
2.抢占自旋锁是非公平(原因：内核态用户态切换代价大，公平抢占可能会唤醒已经park的线程导致性能降低，而非公平则不会有这种情况)的，也就是会导致线程饥饿：有线程迟迟抢占不到锁。

自旋锁—>重量级锁

重量级锁就是所有锁里面锁代价最高的，他是依靠系统内核的提供的锁来实现的，即使用系统调用，当然性能不会高到哪里去。就好比之前的锁都是你自己解决问题，现在不行了，还需要别人帮助解决，解决了之后还得教会你才行。
这种情况下monitor互斥量指针中会存放指向c++互斥量的指针。
JDK1.5之前的synchronized之所以性能低，就是因为他的底层其实就是这个锁。
说是底层内核实现，要研究我们当然就得看c/c++代码了：
这个类叫objectMontor.cpp,这里我们摘选这个类的构造函数看一下：

ObjectMonitor() {
    _header       = NULL;
    _count        = 0;
    _waiters      = 0,
    _recursions   = 0;   // 递归次数/重入次数
    _object       = NULL;  // 存储Monitor关联对象
    _owner        = NULL; // 记录当前持有锁的线程ID
    _WaitSet      = NULL;  // 存放处于等待状态的线程 如Java中lock.wait()使线程进入该集合
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ; // 当前monitor没有线程占有时，所有预抢占线程会到该集合中竞争
     FreeNext      = NULL ;
    _EntryList    = NULL ;  // 存放因为等待锁而阻塞的线程
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
    _previous_owner_tid = 0;
  }

  ~ObjectMonitor() {
   // TODO: Add asserts ...
   // _cxq == 0 _succ == NULL _owner == NULL _waiters == 0
   // _count == 0 _EntryList  == NULL etc
  }

这个其实跟AQS是有点类似的，简单看一下主要成员变量就行，深究就不用了。

synchronized和Lock

最后我们在讨论一下synchronized和Lock的区别。

synchronized是关键字，你除了直接用啥都做不了。Lock是个类，你可以用它的很多方法。
synchronized都是底层帮我们实现了(什么时候获取锁，什么时候释放锁)。Lock需要你自己去做。
synchronized是非公平锁。Lock有公平锁实现类。

总的来说就是：Lock比synchronized功能丰富，什么对象你都可以设置，甚至你可以自定义一个锁。

see the future

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Java juc系列2 —— synchronized关键字

Java JUC系列目录链接Java juc系列2 —— synchronized关键字JDK1.5后的synchronizedJava多线程 synchronized关键字的用法JAVA对象组成结构对象的多种锁状态锁的升级过程无锁—>偏向锁偏向锁—>轻量级锁轻量级锁 —>自旋锁(某种意义上这只是一种自旋的状态，并不叫锁)自旋锁—>重量级锁synchronized和LockJDK1.5后的synchronizedJava多线程 synchronized关键字的用法我们都知道s
复制链接

扫一扫

专栏目录