Java Monitor对象与Synchronized原理

1. Java对象头介绍

Java的世界里,万物皆对象,对象是类的实例,类是抽象的,对象是具体的…这些都是Java对象的一些常见介绍。
今天我们要学习的是Java对象的底层结构对象头的部分,它是Java对象的一部分,看一张HotSpot虚拟机中 Java对象的结构图:

在32位虚拟机中
普通Java对象头,占8个字节:

KlassWord (32bits):指的是该对象的类型,占4个字节
MarkWord (32bits):存放Monitor 对象的指针的引用地址,待介绍。

数组对象头,占16个字节:

与普通Java对象头不同的是数组对象头多出了数组长度字段,占4个字节

Mark Word结构:

一个通常的Java对象的Mark Word结构State处于Normal状态,即无锁状态。
状态为Biased表示该对象被加上了偏向锁,状态LightweightLocked表示该对象被加上了轻量级锁,HeavyweightLocked表示重量级锁,当对象被加上了synchronized 此时就被上了重量级锁,Mark Word的结构也将发生变化。MarkedforGC 表示被GC标记,等待回收。

64位虚拟机的Mark Word结构

2. synchronized 与 Monitor对象

Monitor被翻译成监视器或管程。每一个Java对象都可以关联一个Monitor 对象,如果使用synchronized给对象上锁(重量级锁),Mark Word位置就会指向Monitor对象的引用地址。

当我们线程2执行如下代码时:

synchronized(this){ 
//处理相关业务
}

  1. Thread2线程执行上述代码时,当前对象this会被上一把锁,这是一把重量级锁,this对象头的Mark Word字段指向了操作系统创建的Monitor对象引用地址
  2. Monitor对象只能有一个owner,此时如果有其它线程如Thread-3或Thread-4等线程要获取这把锁就要进入Monitor对象的堵塞队列EntryList中等待Thread2释放锁。
  3. 等待锁资源被释放后,Thread-3或Thread-4会互相竞争锁资源,并不能保证谁获取到锁,最终还是有CPU来决定。
  4. Monitor对象的WaitSet存放的是,获取到锁的线程,但是由于其它一些原因导致线程进入Waiting状态,又释放了锁资源,待介绍。

注意:

  1. 上述过程只发生在synchronized 锁住同一个对象时,不同对象会关联不同的Monitor对象
  2. 不加synchronized 的对象不会关联监视器Monitor,也就不会发生上述过程

3. synchronized 原理总结

static final Object lock = new Object();

static int counter = 0;

public static void main(String[] args) { 
    synchronized (lock) { 
        counter++;
    }
}

3.1 字节码角度理解synchronized原理

从字节码角度理解上诉代码:

public static void main(java.lang.String[]); 
	descriptor: ([Ljava/lang/String;)
	V flags: ACC_PUBLIC, ACC_STATIC
	Code: 
		stack=2, locals=3, args_size=1
		0: getstatic #2 // <- lock引用(synchronized开始)
		3: dup          //对象复制一份
		4: astore_1    // 复制完的对象存储一份 -> slot 1
		5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
		6: getstatic #3 // <- 取的i 6-11做自加操作
		9: iconst_1 // 准备常数 1 
		10: iadd // +1 
		11: putstatic #3 // -> i
		14: aload_1 // <- lock引用到刚刚复制的那一份锁对象的地址
		15: monitorexit // 将 lock对象 MarkWord 重置(释放锁), 唤醒 EntryList
		16: goto 24         //去执行24行
		19: astore_2 // e -> slot 2 (异常情况处理开始)
		20: aload_1 // <- lock引用 刚刚复制的那一份锁对象的地址
		21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
		22: aload_2 // <- slot 2 (e) 获取异常对象
		23: athrow // throw e 抛出
		24: return
	Exceptiontable:
		from to target type
		6 16 19 any
		19 22 19 any
	LineNumberTable:
		line 8: 0 
		line 9: 6 
		line 10: 14 
		line 11: 24
	LocalVariableTable:
		Start Length Slot Name Signature
		0 25 0 args [Ljava/lang/String;
	StackMapTable: number_of_entries=2
		frame_type=255/* full_frame */
			offset_delta=19
			locals= [ class"[Ljava/lang/String;", classjava/lang/Object ]
			stack= [ classjava/lang/Throwable ]
		frame_type=250/* chop */
			offset_delta=4
	

3.2 synchronized进阶原理

3.2.1 synchronized轻量级锁

轻量级锁也是synchronized 实现的,只不过适用的场景与重量级有所不同,通俗一点说,就是轻量级锁适用于重量级锁可以适当优化的地方,如:线程之间没有发生竞争,即上锁的对象,线程1解锁的时间和线程2上锁的时间是错开的,这个时候可以使用轻量级锁优化。

假设又两个方法的同步代码块。利用同一对象上锁:

static final Object obj=new Object();
public static void method1() 
{  
	synchronized( obj )
	 { 
	  // 同步块 
	  A method2(); 
	 }
}
public static void method2() 
{ 
	 synchronized( obj ) 
	 {  
	 // 同步块 B
	  }
 }
  1. 当代码要执行到method1()的synchronized( obj )
    此时的现象是

    操作系统为Thread-0开辟了一块栈内存,栈内存中又为synchronized( obj )开辟了一块栈帧,栈帧里面存储的是锁记录信息,它包括锁记录的地址和即将要锁对象的引用地址,这个说明它是属于哪一种锁,例如上图 00表示是一把轻量级锁。Object类则已经被new在堆中,Mark Word标识此时的状态是无锁状态 01.

  2. 执行完synchronized( obj )时后

    此时发生了两个重要变化,一是线程内部的锁记录地址和Object对象的Mark Word信息互换,二是锁记录对象的object 引用指向了Object对象的地址,这两个步骤执行后,也就完成了上锁的过程。
    其中要注意的是

    • 只有Object的Mark Word标识为无锁状态时,才可以上锁。
    • 第一步的信息交换被称为cas交换,是原子性的,要不成功要不失败。
  3. 代码继续执行,进入method2()的synchronized( obj )又会重复上面的步骤,但是此时cas就会交换失败!

    此时在栈内存中又会分配一个锁对象记录,Object 引用指向了Object对象,但此时的Object对象已经上了一把轻量级锁,于是不能再上锁了,cas交换失败,现在就处在竞争的状态,也称之锁膨胀状态(待介绍), 锁重入现象,新增增加的一条所记录做为重入的计数。

  4. 锁的释放
    解锁的时候,如果遇到锁记录的地址为null,则直接释放掉,删除锁记录。如果不为null,则需要将上锁时候的信息交换重置回来,恢复对象头的Mark Word信息。
    如果成功,则表示解锁成功。
    如果失败说明轻量级锁经过了锁膨胀变成重量级锁,则需要进行重量级锁的解锁过程。

3.2.2 synchronized锁膨胀

如果cas操作失败,并且有其它线程为该对象上锁了,那个其它线程上的如果是轻量级锁,此时就有竞争条件了,会发生锁膨胀,轻量级锁就加不上了,需要升级为重量级锁。

升级为重量级
当Thread -1上锁失败,就会为Object对象申请Monitor锁,让Object的Mark Word重新指向Monitor对象,Thread-1则会进入Monitor的Entry的队列中堵塞。

细节发生的变化有,Object 对象头的Mark Word指向了Monitor对象,指向之前会先得到Monitor对象,然后将其Owner改为Thread-0的锁记录拥有,因为此时Thread-0的锁还未释放。

解锁过程
Thread-0如果要解锁,如果走的轻量级的解锁流程会失败,则走的就是重量级锁的结果流程,即把Monitor对象的Owner置为null,并且去唤醒Entry List堵塞的线程去竞争。

3.2.3 synchronized自旋锁

重量级锁竞争锁资源的时候,还可以通过自旋来进行优化,场景发生在:当锁资源被占用的情况下,Monitor对象中的Entry List线程不用马上进入堵塞队列,而是进入自旋状态,简单可以理解为在做循环试探锁资源是否被释放了,目的是达到锁资源一释放就可以立马被下一个线程使用,不要再去进行唤醒操作。

但是要注意的是:

  • 自旋会占用CPU的资源,如果是单核CPU就会存在很大的浪费,所以自旋使用与多核的CPU.
  • Java 7之后就不能手动控制是否开启自旋功能了,而是由JVM自动执行,并且是自适应的,例如如果一次自旋成功,就会被认为自旋成功的可能性大,就会多自旋几次,反之,少自旋或者不自旋,设计的比较智能。

3.2.4 synchronized偏向锁(重难点)

偏向锁是对轻量级锁的再次优化,体现在减少cas的次数,因为我们在对轻量级上锁的过程中,会遇到前面我们谈论的一种情况:

第一次对Object对象上锁的过程中会有一次cas操作,如果要对Object对象第二次上锁,则会cas失败,此时锁记录指针会指向null,并且操作系统会创建一个新的栈帧存储这一个锁记录,依次类推,如果这个Object对象被重复n次,则会生成n个这样的记录,作为锁的可重入的计数。

这样就会存在一个问题
如果产生了n次这样的计数,则会进行n次的cas操作,这样是很耗CPU资源的,所以可以使用偏向锁进行优化:第一次进行cas操作的时候,将线程ID设置到Mark Word头部,此后检查发现这个线程ID是自己,接下来就都不用进行cas操作了,以后只要不竞争,这个对象就归改线程所拥有。

观察以下代码:

static final Object obj = new Object();
public static void m1() {  
	synchronized( obj ) {  
		// 同步块 A 
		m2(); 
	}
}
public static void m2() {  
	synchronized( obj ) {  
		// 同步块 B 
		m3(); 
	}
}
public static void m3() { 
	 synchronized( obj ) { 
	 // 同步块 C
	  }
}

对比轻量级锁,偏向锁

回忆一下对象头的格式:

一个对象创建时:

  1. 默认时开启偏向锁的,对象创建后,mark word的最后三位为101,其它的thread、epoch、age 都为 0。
  2. 偏向锁默认是延迟的,不会再程序运行时立即生效,如果想避免延迟,可以修改IDEA的启动配置,添加VM参数:XX:BiasedLockingStartupDelay=0来禁用延迟
  3. 如果对象没有开启偏向锁,那么对象创建后mark word的最后三位为001,这时它的hashcode,age…都等于0,这又用到这些字段的时候才会被赋值。

偏向锁测试
我们可以借助第三方jar报来测试偏向锁,创建对象对象头默认会加上偏向锁,引入jol依赖

</dependency>
<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.10</version>
</dependency>
  • 测试偏向锁的启动延迟性
public static void main(String[] args) { 
    Dog dog = new Dog();
    ClassLayout classLayout = ClassLayout.parseInstance(dog);
    System.out.println(classLayout.toPrintable());
}

输出:

当我们让主线程睡5秒,再测试

public static void main(String[] args) throws InterruptedException { 
    Thread.sleep(5000);
    Dog dog = new Dog();
    ClassLayout classLayout = ClassLayout.parseInstance(dog);
    System.out.println(classLayout.toPrintable());
}

输出:

可以观察到,后三位已经被加上偏向锁状态位。需要注意的是:Thread.sleep(5000);不能写在Dog dog = new Dog();后面,因为偏向锁的延迟性是体现在将要创建对象的时候。

  • 另外一种展示偏向锁的方法,禁用偏向锁延迟,这样就可以在主线程不用睡眠的情况下,给对象加上偏向锁,操作方法如下:

修改启动配置:给VM加上-XX:BiasedLockingStartupDelay=0

重新跑一下程序,输出:

观察synchronized与偏向锁的结合前后对象头的变化:

    public static void main(String[] args) { 

        Dog dog = new Dog();
        ClassLayout classLayout = ClassLayout.parseInstance(dog);
        new Thread(()->{ 
            log.debug("加锁前....");
            log.debug(classLayout.toPrintable());
            synchronized (dog){ 
                log.debug("加锁中....");
                log.debug(classLayout.toPrintable());
            }
            log.debug("解锁后....");
            log.debug(classLayout.toPrintable());
        },"t1").start();
    }

输出:

  • 禁用偏向锁,配置启动-XX:-UseBiasedLocking,启动测试

    该现象说明我们禁用掉偏向锁后,会优先启动轻量级锁,而不是重量级锁。

偏向锁被撤销情况

情况1:

  • 再测试一个有趣的现象,如果我们调用对象的hashcode,则会自动禁用掉偏向锁,首先我们开启偏向锁,使用-XX:BiasedLockingStartupDelay=0来禁用延迟
    public static void main(String[] args) throws InterruptedException { 

        Dog dog = new Dog();
        ClassLayout classLayout = ClassLayout.parseInstance(dog);
        log.debug(classLayout.toPrintable());
        log.debug("hashcode前....");
        System.out.println(dog.hashCode());
        log.debug("hashcode前....");

        new Thread(()->{ 
            log.debug("加锁前....");
            log.debug(classLayout.toPrintable());
            synchronized (dog){ 
                log.debug("加锁中....");
                log.debug(classLayout.toPrintable());
            }
            log.debug("解锁后....");
            log.debug(classLayout.toPrintable());
        },"t1").start();
// System.out.println(classLayout.toPrintable());
    }

猜想对象头的锁状态

1. 偏向锁(101)
2. 无锁(001)
3. 轻量级锁(000)
4. 无锁(001)

输出:

其中补充一点的是我们的对象hashcode值并不是在创建对象时生成的,而是在第一次调用hashcode()时生成的!

Dog dog = new Dog();
ClassLayout classLayout = ClassLayout.parseInstance(dog);
log.debug(classLayout.toPrintable());
System.out.println(dog.hashCode());
log.debug(classLayout.toPrintable());

输出:

情况2:演示线程1和线程2,对对象上锁解锁互不影响,没有竞争,此时的t2上锁后,就会把t1的偏向锁撤销掉,换成轻量级锁,原来的偏向锁的线程id也会被换成锁记录。

Dog dog = new Dog();
ClassLayout classLayout = ClassLayout.parseInstance(dog);
 new Thread(()->{ 
     synchronized (dog){ 
         log.debug("t1加锁中....");
         log.debug(classLayout.toPrintable());
     }
     //t1解锁后唤醒类锁,使得t2可以继续执行下去
     synchronized (Test.class){ 
         Test.class.notify();
     }
 },"t1").start();

 new Thread(()->{ 
     //等待t1释放锁
     synchronized (Test.class){ 
         try { 
             Test.class.wait();
         } catch (InterruptedException e) { 
             e.printStackTrace();
         }
     }
     log.debug("t2加锁前....");
     log.debug(classLayout.toPrintable());
     synchronized (dog){ 
         log.debug("t2加锁中....");
         log.debug(classLayout.toPrintable());
     }
     log.debug("t2解锁后....");
     log.debug(classLayout.toPrintable());
 },"t2").start();

输出:

15:51:26.521 c.TestBiased [t1] - t1加锁中....
15:51:26.525 c.TestBiased [t1] - com.liuzeyu.testsynchronized.Dog object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           0d 98 22 dc (00001101 10011000 00100010 11011100) (-601712627)
      4     4        (object header)                           df 01 00 00 (11011111 00000001 00000000 00000000) (479)
      8     4        (object header)                           7d 44 01 08 (01111101 01000100 00000001 00001000) (134300797)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

15:51:26.525 c.TestBiased [t2] - t2加锁前....
15:51:26.527 c.TestBiased [t2] - com.liuzeyu.testsynchronized.Dog object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           0d 98 22 dc (00001101 10011000 00100010 11011100) (-601712627)
      4     4        (object header)                           df 01 00 00 (11011111 00000001 00000000 00000000) (479)
      8     4        (object header)                           7d 44 01 08 (01111101 01000100 00000001 00001000) (134300797)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

15:51:26.527 c.TestBiased [t2] - t2加锁中....
15:51:26.528 c.TestBiased [t2] - com.liuzeyu.testsynchronized.Dog object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           60 f1 1f 31 (01100000 11110001 00011111 00110001) (824176992)
      4     4        (object header)                           9d 00 00 00 (10011101 00000000 00000000 00000000) (157)
      8     4        (object header)                           7d 44 01 08 (01111101 01000100 00000001 00001000) (134300797)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

15:51:26.528 c.TestBiased [t2] - t2解锁后....
15:51:26.530 c.TestBiased [t2] - com.liuzeyu.testsynchronized.Dog object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           09 00 00 00 (00001001 00000000 00000000 00000000) (9)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           7d 44 01 08 (01111101 01000100 00000001 00001000) (134300797)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

情况3:
我们调用对象wait()/notify()方法时,偏向锁也会升级为重量级锁,为什么不是轻量级锁呢,因为wait()/notify()属于Object对象的方法,所以调用该方法后,锁会升级为重量级锁。

在没有禁用偏向锁延迟的情况下

Dog d = new Dog();
new Thread(() -> { 
    log.debug("上锁前....");
    log.debug(ClassLayout.parseInstance(d).toPrintable());
    synchronized (d) { 
        log.debug("wait()前....");
        log.debug(ClassLayout.parseInstance(d).toPrintable());
        try { 
            d.wait();
        } catch (InterruptedException e) { 
            e.printStackTrace();
        }
        log.debug("wait()后....");
        log.debug(ClassLayout.parseInstance(d).toPrintable());
    }
}, "t1").start();

new Thread(() -> { 
    try { 
        Thread.sleep(6000);
    } catch (InterruptedException e) { 
        e.printStackTrace();
    }
    synchronized (d) { 
        log.debug("notify");
        d.notify();
    }
}, "t2").start();

输出:

另外一种情况:
我们前面演示了多线程情况下,对对象的加锁操作,没有发生竞争的前提下。当发生多次的偏向锁撤销时,JVM底层就会自己做处理,也就是不撤销,因为撤销进行锁升级也是很耗内存的。

例如下面例子:先把对象以偏向锁的状态放入集合中存储起来,然后再拿出来加锁,根据上面的规则,此时偏向锁会被撤销掉升级为轻量级锁,并且线程id也会被锁记录替换掉。
但是JVM会认为撤销的阈值达到20时,该对象就会重新偏向新的加锁线程,也就是偏向线程t2,这是一块比较细节的知识点。

 public static void main(String[] args) throws InterruptedException { 

        Vector<Dog> list=new Vector<>();
        new Thread(() -> { 
            for (int i = 0; i < 30; i++) { 
                Dog d = new Dog();
                list.add(d);
                synchronized (d) { 
                    log.debug("t1加锁中..");
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                }
            }
            synchronized (list) { 
                list.notify();
            }
        }, "t1").start();

        new Thread(() -> { 
            //等待
            synchronized (list) { 
                try { 
                    list.wait();
                } catch (InterruptedException e) { 
                    e.printStackTrace();
                }
            }
            for (int i = 0; i < 30; i++) { 
                Dog d = list.get(i);
                log.debug("t2加锁前..");
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                synchronized (d) { 
                    log.debug("t2加锁中..");
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                }
                log.debug("t2解锁后..");
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());

            }
        }, "t2").start();
    }

观察结果:

由于输出的内容比较多,这边只展示重点部分:

t1线程 0-29次输出:

t2线程 0-18次输出:

当t2线程达到阈值20次的时候,也就是19-29的输出就会变化:

最后一种特殊的情况:当撤销偏向锁的偏向的阈值达到40时,再创建新的对象,它都是不可偏向的,也就是无锁状态。

@Slf4j(topic = "c.TestBiased")
public class TestBiased { 

    static Thread t1,t2,t3;

    public static void main(String[] args) throws InterruptedException { 

        int loopNumber = 39;
        Vector<Dog> list=new Vector<>();
        t1 = new Thread(() -> { 
            for (int i = 0; i < loopNumber; i++) { 
                Dog d = new Dog();
                list.add(d);
                synchronized (d) { 
                    log.debug("t1加锁中..");
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                }
            }
            LockSupport.unpark(t2);
        }, "t1");
        t1.start();

        t2 = new Thread(() -> { 
            //等待
            LockSupport.park();
            for (int i = 0; i < loopNumber; i++) { 
                Dog d = list.get(i);
                log.debug("t2加锁前..");
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                synchronized (d) { 
                    log.debug("t2加锁中..");
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                }
                log.debug("t2解锁后..");
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
            }
            LockSupport.unpark(t3);

        }, "t2");
        t2.start();

        t3 = new Thread(() -> { 
            //等待
            LockSupport.park();
            for (int i = 0; i < loopNumber; i++) { 
                Dog d = list.get(i);
                log.debug("t3加锁前..");
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                synchronized (d) { 
                    log.debug("t3加锁中..");
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());
                }
                log.debug("t3解锁后..");
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintable());

            }
        }, "t3");
        t3.start();

        t3.join();
        log.debug(ClassLayout.parseInstance(new Dog()).toPrintable());
    }
}

观察结果:

线程t1:0-38次,将对象加上偏向锁并放入集合

线程t2:0-18次,将集合中的0-18个元素的偏向锁撤销为无状态锁,19-18次批量重偏向到t2线程

t3:0-18次,将集合中的0-18个元素的无状态锁重新撤销,然后上轻量级锁,之后解锁。19-38次,偏向t2的偏向锁再次撤销。


因此批量锁在t3线程被撤消了39次,所以我们等到t3线程执行完,再次去创建新的对象,此时达到阈值40,创建的对象都是无锁状态了!!

如果将loopNumber 改成38,此时没有达到阈值,创建出来的对象还是待偏向状态

<mark>偏向锁的知识点到此为止。</mark>

各种锁状态标识:

3.2.5 synchronized锁消除

分析以下代码:a(),b()方法哪个运行效率更高?

@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations=3)
@Measurement(iterations=5)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark { 
    static int x = 0;
    @Benchmark
    public void a() throws Exception { 
        x++;
    }
    @Benchmark
    // JIT 即时编译器
    public void b() throws Exception { 
        Object o = new Object();
        synchronized (o) { 
            x++;
        }
    }
}
D:\BaiduNetdiskDownload\\concurrent\jmh_eliminate_locks\target>java -jar benchmarks.jar
# VM invoker: C:\Program Files\Java\jre1.8.0_91\bin\java.exe
# VM options: <none>
# Warmup: 3 iterations, 1 s each
# Measurement: 5 iterations, 1 s each
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: com.itcast.MyBenchmark.a

# Run progress: 0.00% complete, ETA 00:00:16
# Fork: 1 of 1
# Warmup Iteration   1: 2.623 ns/op
# Warmup Iteration   2: 3.099 ns/op
# Warmup Iteration   3: 2.528 ns/op
Iteration   1: 2.989 ns/op
Iteration   2: 3.323 ns/op
Iteration   3: 3.105 ns/op
Iteration   4: 4.456 ns/op
Iteration   5: 4.371 ns/op


Result: 3.649 ±(99.9%) 2.730 ns/op [Average]
  Statistics: (min, avg, max) = (2.989, 3.649, 4.456), stdev = 0.709
  Confidence interval (99.9%): [0.919, 6.378]


# VM invoker: C:\Program Files\Java\jre1.8.0_91\bin\java.exe
# VM options: <none>
# Warmup: 3 iterations, 1 s each
# Measurement: 5 iterations, 1 s each
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: com.itcast.MyBenchmark.b

# Run progress: 50.00% complete, ETA 00:00:10
# Fork: 1 of 1
# Warmup Iteration   1: 4.137 ns/op
# Warmup Iteration   2: 5.132 ns/op
# Warmup Iteration   3: 5.046 ns/op
Iteration   1: 5.145 ns/op
Iteration   2: 4.631 ns/op
Iteration   3: 4.458 ns/op
Iteration   4: 5.114 ns/op
Iteration   5: 4.205 ns/op


Result: 4.711 ±(99.9%) 1.585 ns/op [Average]
  Statistics: (min, avg, max) = (4.205, 4.711, 5.145), stdev = 0.412
  Confidence interval (99.9%): [3.126, 6.295]


# Run complete. Total time: 00:00:20

Benchmark            Mode  Samples  Score  Score error  Units
c.i.MyBenchmark.a    avgt        5  3.649        2.730  ns/op
c.i.MyBenchmark.b    avgt        5  4.711        1.585  ns/op

从最终得分可以看出来a()方法还是要更高效一点,因为b()方法加上了synchronized关键字,过程会存在一定的内存损耗,但是由于JVM默认是开启JIT即时编译器的,而且b()可以看出,局部变量o 的作用域只是在方法内部,也就是说处于线程安全状态下,这边JIT内部会做synchronized锁的清除操作,目的也就是提高代码执行的效率。
我们也可以手动关掉JIT,再次查看执行情况:

可以没有优化之前加上synchronized锁的效率是很慢的。

学习资料:https://www.bilibili.com/video/BV16J411h7Rd

 3 total views,  1 views today

页面下部广告