Java synchronized之类锁/对象锁

前言

    之前看到过一篇文章,写的就是Java关键字synchronized的类锁和对象锁,今天想重温一下无奈发现文章已经搜索不到,百度之大部分都是重复的那么几篇文章,甚至也仅仅讲了对象锁没有讲解类锁。于是重写一篇博客介绍 synchronized 类锁 对象锁。 

Java原生提供了 synchronized 关键字用于多线程编程,但往往入门使用者在发现使用情况与预期有差别,可阅读此文章。

Java的 synchronized 锁的是对象,也只锁对象: 对象锁是基于对堆内存内对象的头部加锁信息; 类锁是基于对类对应的 java.lang.Class对象加锁信息; 特别的, synchronized(this) 是对this所对应的对象加锁。

Java 提供 synchronized 关键字,在语言层面上做出支持。JDK实现上还有很多其它的实现,例如: ReentrantLock

synchronized的锁粒度介绍

synchronized 的用法举例

synchronized 的锁可作用于Java方法,或者是一个代码块。无论何种用法,所起到的作用仅限于 类锁/对象锁

类锁的场景举例

① 当synchronized 修饰一个使用了 static 关键字修饰的方法时:

public static synchronized void staticA();

② 当synchronized 修饰一个 class 的方法块时:

synchronized(Object.class) {
    // do something
}

对象锁的场景举例

① 当synchronized 修饰一个不使用了 static 关键字修饰的方法时:

public synchronized void noneStaticA();

② 当synchronized 修饰关键字 this 的方法块时:

synchronized(this) {
    // do something
}

③ 当synchronized 修饰一个对象 xxx 的方法块时:

synchronized(xxx) {
    // do something
}

类锁和对象锁在使用方法上的区别

当使用了对象锁之后,除了获得当前对象的对象锁的线程,其它线程对当前对象的所有使用对象锁的语句的访问受到阻塞,但是对非使用对象锁的语句的访问不受影响

当使用了类锁之后,除了当前线程外,其它线程对当前类的所有 类方法的访问受到阻塞,其它的静态方法(没有使用类锁的静态方法)的访问不受影响

特别的,可以使用 synchronized(xxx) 代码块 语法将一个无用的对象xxx作为一把锁。 这个时候的”对象锁”是针对于xxx对象的内部而言, 对于使用对象xxx作为锁的方法块来说,不管是使用的类锁还是对象锁都互不影响。

类锁和对象锁作用域不同,两者互不影响。

类锁和对象锁的Q&A

下述问题都是针对于此段伪代码片段进行:

class Sync {
    public synchronized void noneStaticA();
    public synchronized void noneStaticB();
    public void noneStaticC();

    public static synchronized void staticA();
    public static synchronized void staticB();
    public static void staticC();
}    

Q1: 如代码片段所示,多线程环境中对象 Sync x 和 对象 Sync y 哪些语句可以同时执行:
A. x.noneStaticA() 和 x.noneStaticA();
B. x.noneStaticA() 和 x.noneStaticB();
C. x.noneStaticA() 和 y.noneStaticA();
D. x.noneStaticA() 和 x.noneStaticC();

A1: C、D.
解析: 如上皆为对象锁,单个对象内所有对象锁互互斥。而对象锁的粒度为单个对象, x对象的对象锁不影响y对象的对象锁。对象锁仅针对使用了对象锁的语句生效。

Q2: 如代码片段所示,多线程环境中对象 Sync x类 Sync 哪些语句可以同时执行:
A. x.noneStaticA() 和 Sync.staticA();
B. x.noneStaticA() 和 Sync.staticC();
C. x.noneStaticC() 和 Sync.staticA();
D. Sync.staticA() 和 Sync.staticA();
E. Sync.staticA() 和 Sync.staticB();

A2: A、B、C
解析:类锁与对象锁作用粒度不一,互不影响。对象锁与类静态方法之间无锁冲突。类锁与对象方法也没有锁冲突。类锁的作用域为这个类所有的类锁。

Q3:对于对象 Sync x 和 对象 Sync y哪些语句可以同时执行?

// 在类 Sync 里面增加如下代码:
public void foo1() {
    synchronized(this) {
        // ...
    }
}

// 另一个类 SyncExecute 的如此写法:
public void foo2() {
    // ...
    synchronized(x) {
         // ...
    }
    // ...
}

public void foo3() {
    // ...
    synchronized(Sync.class) {
         // ...
    }
    // ...
}

A3: 上述是一个复杂环境, 已知对象锁与类锁之间互不影响, 因此单独分析对象锁和类锁即可。

x.noneStaticA() 与 x.noneStaticB() 与 x.foo1() 三者使用的都是对象锁, 对同一对象 x而言是互斥的,而在SyncExecute 中的 foo2() 中也使用了对对象x的对象锁,因此 foo2() 与x里面的三个使用了对象锁的方法都是互斥的。(但是当使用的Sync的对象不是x而是其它的例如y/z的时候,他们之间完全是可以正常运行的)。

Sync.staticA() 与 Sync.staticB() 与 SyncExecute 中的 foo3() 都是使用的类锁,因此无论 new 了多少个 Sync对象他们都是互斥的,会竞争类锁。

synchronized对于类锁和对象锁的解析

对象锁互斥原理

可优先阅读该篇文章田守枝:2.1 对象的内存布局

一个被JVM创建的对象存在于JVM中,不仅仅包含了对象的实例数据,还包含对象头(Header)对齐填充(Padding)。 其中对象头(Header)里面就包含了当前对象是否有锁的信息。

如果对磁盘文件系统了解的同学就会知道,磁盘上储存的文件数据依赖于文件系统,不同的文件系统对于文件的存储数据结构可能不一样,但是大都包含如下特点:文件数据块单独储存,其它内容(如文件名、所有权信息、创建时间等)储存位置是与数据块逻辑隔离的。

因此,不管是 synchronized修饰的实例方法,还是synchronized代码块修饰的this关键字, 还是synchronized修饰的一个具体的对象,语言层面访问该对象时都会检查头部的锁信息,发现有锁了之后就会开始互斥逻辑。

同时,这也解释了为什么不同对象的对象锁之间为何互不影响: 因为对象锁的原理是基于单个对象的头部的锁信息。

synchronized 在锁的实现上相对复杂,存在着不同锁类型的切换升级。如有有兴趣可以阅读这篇文章:http://www.jianshu.com/p/5dbb07c8d5d5 。(至于synchronized在锁的抢占上目前暂未发现一篇详细介绍的文章。例如 ReentrantLock是基于Java关键字volatile和CPU的CAS机制来实现的,若有知晓可在留言区告知一二

类锁原理及为何类锁完全互斥

可优先阅读该篇文章图解Java类加载机制

想获得一个Java的对象,则需要先获得Java的一个类,这便是Java的类加载。类加载完毕之后的类代码储存在JVM的一块单独区域。一个类可能被加载或者卸载多次,但是任意一个时刻JVM里面只存在一个类的数据区域。阅读谈谈Java虚拟机——Class文件结构知晓这篇数据区域的数据结构

同时,JVM在装载完毕一个类的时候,还会给该类生成一个 java.lang.Class 的对象,由 类数据区里面的该类的this_class字段指向这个Class对象。 从而,类锁的实现原理可以转化为对象锁的原理 — 在对应的Class对象上加对象锁即可

synchronized 的内存可见性

需要特别注意的事是, 根据JMM的规范, synchronized 块里面的对象, 具有内存可见性。即:

  1. A线程在释放synchronized锁之前,会将线程内存中的共享变量回写回主存。
  2. B线程在获取synchronized锁之后,会清空线程内部涉及到的共享变量, 再由主存中读取。

参考文章: https://www.ibm.com/developerworks/library/j-jtp03304/index.html
When a thread exits a synchronized block as part of releasing the associated monitor, the JMM requires that the local processor cache be flushed to main memory.

    原文作者:java锁
    原文地址: https://blog.csdn.net/qyp199312/article/details/78438273
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞