IllegalMonitorStateException 异常 与 Java中的"对象监视器Monitor"和"对象锁"详解

异常解析

在线程中调用wait方法的时候要用synchronized锁住对象,确保代码段不会被多个线程调用。

如果没有synchronized加锁,那么当前的线程不是此对象监视器的所有者, 就会抛出 IllegalMonitorStateException 异常信息。

当前线程要锁定该对象之后,才能用锁定的对象执行这些方法,这里需要用到synchronized关键字,锁定哪个对象就用哪个对象来执行 notify(), notifyAll(),wait(), wait(long), wait(long, int) 操作,否则就会报IllegalMonitorStateException异常。

在JVM中,每个对象和类在逻辑上都是和一个监视器相关联的。为了实现监视器的排他性监视能力,JVM为每一个对象和类都关联一个锁。锁住了一个对象,就是获得对象相关联的监视器。

监视器好比一做建筑,它有一个很特别的房间,房间里有一些数据,而且在同一时间只能被一个线程占据,进入这个建筑叫做"进入监视器",进入建筑中的那个特别的房间叫做"获得监视器",占据房间叫做"持有监视器",离开房间叫做"释放监视器",离开建筑叫做"退出监视器"。

而一个锁就像一种任何时候只允许一个线程拥有的特权。一个线程可以允许多次对同一对象上锁.对于每一个对象来说,java虚拟机维护一个计数器,记录对象被加了多少次锁,没被锁的对象的计数器是0,线程每加锁一次,计数器就加1,每释放一次,计数器就减1.当计数器跳到0的时候,锁就被完全释放了。

Java虚拟机中的一个线程在它到达监视区域开始处的时候请求一个锁.JAVA程序中每一个监视区域都和一个对象引用相关联. 在java中,synchronized是唯一实现同步的东西。

Java对象的组成与锁的状态

HotSpot虚拟机中,对象在内存中存储的布局可以分为三块区域:

  • 对象头(Header)
  • 实例数据(Instance Data)和
  • 对齐填充(Padding)

HotSpot虚拟机的对象头(Object Header)包括两部分信息,第一部分用于存储对象自身的运行时数据, 如哈希码(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标记、可偏向)下对象的存储内容如下表所示。

锁的状态总共有四种:无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争,锁可以从偏向锁升级到轻量级锁,再升级的重量级锁(但是锁的升级是单向的,也就是说只能从低到高升级,不会出现锁的降级)。JDK 1.6中默认是开启偏向锁和轻量级锁的,我们也可以通过-XX:-UseBiasedLocking来禁用偏向锁。

Mark Word

Mark Word记录了对象和锁有关的信息,当这个对象被synchronized关键字当成同步锁时,围绕这个锁的一系列操作都和Mark Word有关。

Mark Word在32位JVM中的长度是32bit,在64位JVM中长度是64bit。

Mark Word在不同的锁状态下存储的内容不同,在32位JVM中是这么存的:

其中无锁和偏向锁的锁标志位都是01,只是在前面的1bit区分了这是无锁状态还是偏向锁状态。

JDK1.6以后的版本在处理同步锁时存在锁升级的概念,JVM对于同步锁的处理是从偏向锁开始的,随着竞争越来越激烈,处理方式从偏向锁升级到轻量级锁,最终升级到重量级锁。

JVM一般是这样使用锁和Mark Word的:

1,当没有被当成锁时,这就是一个普通的对象,Mark Word记录对象的HashCode,锁标志位是01,是否偏向锁那一位是0。

2,当对象被当做同步锁并有一个线程A抢到了锁时,锁标志位还是01,但是否偏向锁那一位改成1,前23bit记录抢到锁的线程id,表示进入偏向锁状态。

3,当线程A再次试图来获得锁时,JVM发现同步锁对象的标志位是01,是否偏向锁是1,也就是偏向状态,Mark Word中记录的线程id就是线程A自己的id,表示线程A已经获得了这个偏向锁,可以执行同步锁的代码。

4,当线程B试图获得这个锁时,JVM发现同步锁处于偏向状态,但是Mark Word中的线程id记录的不是B,那么线程B会先用CAS操作试图获得锁,这里的获得锁操作是有可能成功的,因为线程A一般不会自动释放偏向锁。如果抢锁成功,就把Mark Word里的线程id改为线程B的id,代表线程B获得了这个偏向锁,可以执行同步锁代码。如果抢锁失败,则继续执行步骤5。

5,偏向锁状态抢锁失败,代表当前锁有一定的竞争,偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间,里面保存指向对象锁Mark Word的指针,同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操作都是CAS操作,如果保存成功,代表线程抢到了同步锁,就把Mark Word中的锁标志位改成00,可以执行同步锁代码。如果保存失败,表示抢锁失败,竞争太激烈,继续执行步骤6。

6,轻量级锁抢锁失败,JVM会使用自旋锁,自旋锁不是一个锁状态,只是代表不断的重试,尝试抢锁。从JDK1.7开始,自旋锁默认启用,自旋次数由JVM决定。如果抢锁成功则执行同步锁代码,如果失败则继续执行步骤7。

7,自旋锁重试之后如果抢锁依然失败,同步锁会升级至重量级锁,锁标志位改为10。在这个状态下,未抢到锁的线程都会被阻塞。

指向类的指针

该指针在32位JVM中的长度是32bit,在64位JVM中长度是64bit。

Java对象的类数据保存在方法区。

数组长度

只有数组对象保存了这部分数据。

该数据在32位和64位JVM中长度都是32bit。

实例数据

对象的实例数据就是在java代码中能看到的属性和他们的值。

对齐填充字节

因为JVM要求java的对象占的内存大小应该是8bit的倍数,所以后面有几个字节用于把对象的大小补齐至8bit的倍数,没有特别的功能。

Java对象的Monitor机制

Monitor的机制分析

Java虚拟机给每个对象和class字节码都设置了一个监听器Monitor,用于检测并发代码的重入,同时在Object类中还提供了notify和wait方法来对线程进行控制。

在java.lang.Object类中有如下代码:

public class Object {
    ...
    private transient int shadow$_monitor_;
    public final native void notify();
    public final native void notifyAll();
    public final native void wait() throws InterruptedException;
    public final void wait(long millis) throws InterruptedException {
        wait(millis, 0);
    }
    public final native void wait(long millis, int nanos) throws InterruptedException;
    ...
}

Monitor的机制如下图:

结合上图来分析Object的Monitor机制。

Monitor可以类比为一个特殊的房间,这个房间中有一些被保护的数据,Monitor保证每次只能有一个线程能进入这个房间进行访问被保护的数据,进入房间即为持有Monitor,退出房间即为释放Monitor。

当一个线程需要访问受保护的数据(即需要获取对象的Monitor)时,它会首先在entry-set入口队列中排队(这里并不是真正的按照排队顺序),如果没有其他线程正在持有对象的Monitor,那么它会和entry-set队列和wait-set队列中的被唤醒的其他线程进行竞争(即通过CPU调度),选出一个线程来获取对象的Monitor,执行受保护的代码段,执行完毕后释放Monitor,如果已经有线程持有对象的Monitor,那么需要等待其释放Monitor后再进行竞争。

再说一下wait-set队列。当一个线程拥有Monitor后,经过某些条件的判断(比如用户取钱发现账户没钱),这个时候需要调用Object的wait方法,线程就释放了Monitor,进入wait-set队列,等待Object的notify方法(比如用户向账户里面存钱)。当该对象调用了notify方法或者notifyAll方法后,wait-set中的线程就会被唤醒,然后在wait-set队列中被唤醒的线程和entry-set队列中的线程一起通过CPU调度来竞争对象的Monitor,最终只有一个线程能获取对象的Monitor。

需要注意的是:

当一个线程在wait-set中被唤醒后,并不一定会立刻获取Monitor,它需要和其他线程去竞争;
如果一个线程是从wait-set队列中唤醒后,获取到的Monitor,它会去读取它自己保存的PC计数器中的地址,从它调用wait方法的地方开始执行。

Monitor机制在Java中是如何实现的呢?

即通过synchronized关键字实现线程同步来获取对象的Monitor。synchronized同步分为以下两种方式:

同步代码块:

synchronized(Obejct obj) {
    //同步代码块
    ...
}

上述代码表示在进入同步代码块之前,先要去获取obj的Monitor,如果已经被其他线程获取了,那么当前线程必须等待直至其他线程释放obj的Monitor

这里的obj可以是类.class,表示需要去获取该类的字节码的Monitor,获取后,其他线程无法再去获取到class字节码的Monitor了,即无法访问属于类的同步的静态方法了,但是对于对象的实例方法的访问不受影响

同步方法:

public class Test {

    public static Test instance;
    public int val;

    public synchronized void set(int val) {
        this.val = val;
    }

    public static synchronized void set(Test instance) {
        Test.instance = instance;
    }

}

上述使用了synchronized分别修饰了非静态方法和静态方法。

  • 非静态方法可以理解为,需要获取当前对象this的Monitor,获取后,其他需要获取该对象的Monitor的线程会被堵塞。

  • 静态方法可以理解为,需要获取该类字节码的Monitor(因为static方法不属于任何对象,而是属于类的方法),获取后,其他需要获取字节码的Monitor的线程会被堵塞。

Object的notify方法和wait方法详解

上面在讲述Monitor机制的时候已经分析了notify和wait的用法,这里具体分析下。

wait方法

wait有三个重载方法,分别如下:

public final void wait() throws InterruptedException;
public final native void wait(long timeout) throws InterruptedException;
public final void wait(long timeout, int nanos) throws InterruptedException;

后面两个传入了时间参数(nanos表示纳秒),表示如果指定时间过去还没有其他线程调用notify或者notifyAll方法来将其唤醒,那么该线程会自动被唤醒。

调用obj.wait方法需要注意的是,当前线程必须获取到了obj的Monitor(The current thread must own this object's monitor),才能去调用其wait方法,即wait必须放在同步方法或同步代码块中。

调用的是obj.wait(),而不是Thread.currentThread.wait()。

notify() 方法

    /**
     * Wakes up a single thread that is waiting on this object's
     * monitor. If any threads are waiting on this object, one of them
     * is chosen to be awakened. 
     * ...
     * Only one thread at a time can own an object's monitor.
     *
     * @throws  IllegalMonitorStateException  if the current thread is not
     *               the owner of this object's monitor.
     * @see        java.lang.Object#notifyAll()
     * @see        java.lang.Object#wait()
     */
    public final native void notify();

notify有两个方法notify和notifyAll,前者只能唤醒一个正在等待这个对象的monitor的线程,具体由JVM决定,后者则会唤醒所有正在等待这个对象的monitor的线程

需要关注的点:

调用notify方法,并不意味着释放了Monitor,必须要等同步代码块结束后才会释放Monitor。

在调用notify方法时,必须保证其他线程处于wait状态,否则调用notify没有任何效果,导致之后其他线程永远处于堵塞状态。


notify()

Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.

唤醒正在此对象监视器上等待的单个线程。如果有任何线程正在等待这个对象,那么将选择唤醒其中的一个线程。这个选择是任意的,由实现决定。线程通过调用其中一个等待方法来等待对象的监视器。

The awakened thread will not be able to proceed until the current thread relinquishes(释放) the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.

被唤醒的线程将无法继续前进,直到当前线程释放该对象上的锁。被唤醒的线程将以通常的方式与其他线程竞争,这些线程可能正在积极地对这个对象进行同步; 例如,在成为下一个锁定此对象的线程时,被唤醒的线程没有任何特权或不利条件。

This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:

  • By executing a synchronized instance method of that object.
  • By executing the body of a synchronized statement that synchronizes on the object.

此方法只能由此对象监视器的所有者的线程调用。线程通过以下三种方式之一成为对象监视器的所有者:

  • 通过执行该对象的同步实例方法。
  • 通过执行同步语句的主体对对象进行同步。

For objects of type Class, by executing a synchronized static method of that class.
Only one thread at a time can own an object's monitor.

对于Class类型的对象,通过执行该类的同步静态方法。
每次只有一个线程可以拥有一个对象的监视器。

Throws:

IllegalMonitorStateException – if the current thread is not the owner of this object's monitor.

See Also:

notifyAll(), wait()

小结

java中每个对象都有唯一的一个monitor,想拥有一个对象的monitor的话有以下三种方式:

1.执行该对象的同步方法

public synchronize a () {
}

2.执行该对象的同步块

synchronize(obj) {
}

3.执行某个类的静态同步方法

public static synchronize b(){
}

Tips:拥有monitor的是线程。

1.同时只能有一个线程可以获取某个对象的monitor

2.一个线程通过调用某个对象的wait()方法释放该对象的monitor并进入休眠状态,直到其他线程获取了被该线程释放的monitor并调用该对象的notify()或者notifyAll()后再次竞争获取该对象的monitor

3.只有拥有该对象monitor的线程才可以调用该对象的notify()和notifyAll()方法

如果没有该对象monitor的线程调用了该对象的notify()或者notifyAll()方法将会抛出java.lang.IllegalMonitorStateException。

参考资料

https://blog.csdn.net/lkforce/article/details/81128115
https://blog.csdn.net/boyeleven/article/details/81390738
https://blog.csdn.net/hqq2023623/article/details/51000153


Kotlin开发者社区

专注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函数式编程、编程思想、"高可用,高性能,高实时"大型分布式系统架构设计主题。

High availability, high performance, high real-time large-scale distributed system architecture design

分布式框架:Zookeeper、分布式中间件框架等
分布式存储:GridFS、FastDFS、TFS、MemCache、redis等
分布式数据库:Cobar、tddl、Amoeba、Mycat
云计算、大数据、AI算法
虚拟化、云原生技术
分布式计算框架:MapReduce、Hadoop、Storm、Flink等
分布式通信机制:Dubbo、RPC调用、共享远程数据、消息队列等
消息队列MQ:Kafka、MetaQ,RocketMQ
怎样打造高可用系统:基于硬件、软件中间件、系统架构等一些典型方案的实现:HAProxy、基于Corosync+Pacemaker的高可用集群套件中间件系统
Mycat架构分布式演进
大数据Join背后的难题:数据、网络、内存和计算能力的矛盾和调和
Java分布式系统中的高性能难题:AIO,NIO,Netty还是自己开发框架?
高性能事件派发机制:线程池模型、Disruptor模型等等。。。

合抱之木,生于毫末;九层之台,起于垒土;千里之行,始于足下。不积跬步,无以至千里;不积小流,无以成江河。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章