Java锁的膨胀过程以及一致性哈希对锁膨胀的影响

1、锁优化

在JDK6之前，通过synchronized来实现同步效率是很低的，被synchronized包裹的代码块经过javac编译后，会在代码块前后加上monitorenter和monitorexit字节码指令，被synchronized修饰的方法则会被加上ACC_SYNCHRONIZED标识，不论是在字节码中如何表示，作用和功能都是一样的，线程要想执行同步代码块或同步方法，首先需要竞争锁。

synchronized保证了任意时刻最多只有一个线程可以竞争到锁，那么竞争不到锁的的线程该如何处理呢？

在JDK6之前，Java直接通过OS级别的互斥量(Mutex)来实现同步，获取不到锁的线程被阻塞挂起，直到持有锁的线程释放锁后再将其唤醒，这需要OS频繁的将线程从用户态切换到核心态，这个切换过程开销是很大的，OS需要暂停原线程并保存数据，唤醒新线程并恢复数据，因此synchronized也被称为“重量级锁”。

也正是由于性能原因，开发者慢慢摈弃了synchronized，投入ReentrantLock的怀抱。

官方意识到这个问题以后，便将“高效并发”作为JDK6的一个重要改进项目，经过开发团队的重重优化，如今synchronized的性能已经和ReentrantLock保持在一个数量级了，虽然还是慢一丢丢，但是官方表示未来synchronized仍然有优化的余地。

1.1、锁消除

设计一个类时，考虑到存在并发安全问题，往往会对代码块上锁。
但是有时候这个被设计为“线程安全”的类在使用时压根就不存在多线程竞争，那么还有什么理由加锁呢？

锁消除优化得益于逃逸分析技术的成熟，即时编译器在运行时会对代码进行扫描，会对不存在共享数据竞争的锁消除。
例如：在方法中(栈内存线程私有)实例化一个线程安全的类，该实例既没有传递给其他方法，又没有作为对象返回出去(没有发生逃逸)，那么JVM就会对进行锁消除。

如下代码，尽管StringBuffer的append()是被synchronized修饰的，但是不存在线程竞争，锁会消除。

public String method(){
	StringBuffer sb = new StringBuffer();
	sb.append("1");//append()是被synchronized修饰的
	sb.append("2");
	return sb.toString();
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

1.2、锁粗化

由于锁的竞争和释放开销比较大，如果代码中对锁进行了频繁的竞争和释放，那么JVM会进行优化，将锁的范围适当扩大。

如下代码，在循环内使用synchronized，JVM锁粗化后，会将锁范围扩大到循环外。

public void method(){
	for (int i= 0; i < 100; i++) {
		synchronized (this){
			...
		}
	}
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

1.3、自旋锁

当有多个线程在竞争同一把锁时，竞争失败的线程如何处理？

两种情况：

  • 将线程挂起，锁释放后再将其唤醒。
  • 线程不挂起，进行自旋，直到竞争成功。

如果锁竞争非常激烈，且短时间得不到释放，那么将线程挂起效率会更高，因为竞争失败的线程不断自旋会造成CPU空转，浪费性能。

如果锁竞争并不激烈，且锁会很快得到释放，那么自旋效率会更高。因为将线程挂起和唤醒是一个开销很大的操作。

自旋锁的优化是针对“锁竞争不激烈，且会很快释放”的场景，避免了OS频繁挂起和唤醒线程。

1.4、自适应自旋锁

当线程竞争锁失败时，自旋和挂起哪一种更高效？

当线程竞争锁失败时，会自旋10次，如果仍然竞争不到锁，说明锁竞争比较激烈，继续自旋会浪费性能，JVM就会将线程挂起。

在JDK6之前，自旋的次数通过JVM参数-XX:PreBlockSpin设置，但是开发者往往不知道该设置多少比较合适，于是在JDK6中，对其进行了优化，加入了“自适应自旋锁”。

自适应自旋锁的大致原理：线程如果自旋成功了，那么下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也很大概率会成功。
反之，如果很少会自旋成功，那么下次会减少自旋的次数甚至不自旋，避免CPU空转。

1.5、锁膨胀

除了上述几种优化外，JDK6加入了新型的锁机制，不直接采用OS级的“重量级锁”，锁类型分为：偏向锁、轻量级锁、重量级锁。随着锁竞争的激烈程度不断膨胀，大大提升了竞争不太激烈的同步性能。

“synchronized锁的是对象，而非代码！”

每一个Java对象，在JVM中是存在对象头(Object Header)的，对象头中又分Mark Word和Klass Pointer，其中Mark Word就保存了对象的锁状态信息，其结构如下图所示：
在这里插入图片描述

无锁：初始状态
一个对象被实例化后，如果还没有被任何线程竞争锁，那么它就为无锁状态(01)。

偏向锁：单线程竞争
当线程A第一次竞争到锁时，通过CAS操作修改Mark Word中的偏向线程ID、偏向模式。如果不存在其他线程竞争，那么持有偏向锁的线程将永远不需要进行同步。

轻量级锁：多线程竞争，但是任意时刻最多只有一个线程竞争
如果线程B再去竞争锁，发现偏向线程ID不是自己，那么偏向模式就会立刻不可用。即使两个线程不存在竞争关系(线程A已经释放，线程B再去获取)，也会升级为轻量级锁(00)。

重量级锁：同一时刻多线程竞争
一旦轻量级锁CAS修改失败，说明存在多线程同时竞争锁，轻量级锁就不适用了，必须膨胀为重量级锁(10)。此时Mark Word存储的就是指向重量级锁(互斥量)的指针，后面等待锁的线程必须进入阻塞状态。

2、锁膨胀实战

说了这么多，理论终归是理论，不如实战一把来的直接。

通过编写一些多线程竞争代码，以及打印对象的头信息，来分析哪些情况下锁会膨胀，以及膨胀成哪种类型的锁。

2.1、jol工具

openjdk提供了jol工具，可以打印对象的内存布局信息，依赖如下：

<dependency>
    <groupId>org.openjdk.jolgroupId>
    <artifactId>jol-coreartifactId>
    <version>0.9version>
dependency>

  • 1
  • 2
  • 3
  • 4
  • 5

2.2、锁膨胀测试代码

程序启动时先sleep5秒是为了等待偏向锁系统启动。

编写一段锁逐步膨胀的测试代码，如下所示：

public class LockTest {

	static class Lock{}

	public static void main(String[] args) {
		sleep(5000);
		Lock lock = new Lock();

		System.err.println("无锁");
		print(lock);

		synchronized (lock) {
			//main线程首次竞争锁，可偏向
			System.err.println("偏向锁");
			print(lock);
		}

		new Thread(()->{
			synchronized (lock){
				//线程A来竞争，偏向线程ID不是自己，升级为：轻量级锁
				System.err.println("轻量级锁");
				print(lock);
			}
		},"Thread-A").start();

		sleep(2000);

		new Thread(()->{
			synchronized (lock){
				sleep(1000);
			}
		},"Thread-B").start();

		//确保线程B启动并获得锁，sleep 100毫秒
		sleep(100);

		synchronized (lock){
			//main线程竞争时，线程B还未释放，多线程同时竞争，升级为：重量级锁
			System.err.println("重量级锁");
			print(lock);
		}
	}

	static void print(Object o){
		System.err.println("==========对象信息开始...==========");
		System.out.println(ClassLayout.parseInstance(o).toPrintable());
		//jol异步输出，防止打印重叠，sleep1秒
		sleep(1000);
		System.err.println("==========对象信息结束...==========");
	}

	static void sleep(long l){
		try {
			Thread.sleep(l);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59

2.3、输出分析

运行后分析一下控制台输出信息，这里贴上截图并写上注释：

无锁
在这里插入图片描述

偏向锁
在这里插入图片描述

轻量级锁
在这里插入图片描述

重量级锁
在这里插入图片描述

以上，就是JVM中锁逐步膨胀的过程，另外：锁不支持回退撤销。

2.4、锁释放

偏向锁是不会主动释放的，只要没有其他线程竞争，会永远偏向持有锁的线程，这样在以后的执行中，都不用再进行同步处理了，节省了同步开销。

public static void main(String[] args) {
	sleep(5000);
	Lock lock = new Lock();

	synchronized (lock){
		System.err.println("Main线程首次竞争锁");
		print(lock);
	}

	System.out.println();
	sleep(1000);
	System.err.println("同步代码块退出以后");
	print(lock);
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

在这里插入图片描述

轻量级和重量级锁均会主动释放，这里只贴出轻量级锁。

public static void main(String[] args) {
	sleep(5000);
	Lock lock = new Lock();

	synchronized (lock){
		//偏向锁
	}
	
	new Thread(()->{
		synchronized (lock){
			System.err.println("轻量级锁");
			print(lock);
		}
	},"Thread-A").start();

	sleep(5000);
	System.err.println("\n线程A释放锁后");
	print(lock);
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19

在这里插入图片描述

重量级锁类似，这里就不贴测试结果了。

3、一致性哈希对锁膨胀的影响

一个对象如果计算过哈希码，就应该一直保持该值不变(强烈推荐但不强制，因为用户可以重载hashCode()方法按自己的意愿返回哈希码)。

在Java中，如果类没有重写hashCode()，那么会自动继承自Object::hashCode()，Object::hashCode()就是一致性哈希，只要计算过一次，就会将哈希码写入到对象头中，且永远不会改变。

和具体的哈希算法有关，JVM里有五种哈希算法，通过参数-XX:hashCode=[0|1|2|3|4]指定。

只要对象计算过一致性哈希，偏向模式就置为0了，也就意味着该对象锁不能再偏向了，最低也会膨胀会轻量级锁。
如果对象锁处于偏向模式时遇到计算一致性哈希请求，那么会跳过轻量级锁模式，直接膨胀为重量级锁。

锁膨胀为轻量级或重量级锁后，Mark Word中保存的分别是线程栈帧里的锁记录指针和重量级锁指针，已经没有位置再保存哈希码，GC年龄了，那么这些信息被移动到哪里去了呢？

升级为轻量级锁时，JVM会在当前线程的栈帧中创建一个锁记录(Lock Record)空间，用于存储锁对象的Mark Word拷贝，哈希码和GC年龄自然保存在此，释放锁后会将这些信息写回到对象头。

升级为重量级锁后，Mark Word保存的重量级锁指针，代表重量级锁的ObjectMonitor类里有字段记录无锁状态下的Mark Word，锁释放后也会将信息写回到对象头。

代码实战，跳过偏向锁，直接膨胀轻量级锁

public static void main(String[] args) {
	sleep(5000);
	Lock lock = new Lock();

	//没有重写，一致性哈希，重写后无效
	lock.hashCode();

	synchronized (lock){
		System.err.println("本应是偏向锁，但是由于计算过一致性哈希，会直接膨胀为轻量级锁");
		print(lock);
	}
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

在这里插入图片描述

偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁

public static void main(String[] args) {
	sleep(5000);
	Lock lock = new Lock();

	synchronized (lock){
		//没有重写，一致性哈希，重写后无效
		lock.hashCode();
		System.err.println("偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁");
		print(lock);
	}
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

在这里插入图片描述

4、锁性能测试

这里只做了一个简单的测试，实际应用环境比测试环境要复杂的多。

单线程下，各类型锁性能测试：

public class PerformanceTest {
	final static int TEST_COUNT = 100000000;
	static class Lock{}

	public static void main(String[] args) {
		sleep(5000);
		System.err.println("各类型锁性能测试");
		Lock lock = new Lock();
		long start;
		long end;

		start = System.currentTimeMillis();
		for (int i = 0; i < TEST_COUNT; i++) {

		}
		end = System.currentTimeMillis();
		System.out.println("无锁:" + (end - start));

		//偏向锁
		biasedLock(lock);
		start = System.currentTimeMillis();
		for (int i = 0; i < TEST_COUNT; i++) {
			synchronized (lock) {}
		}
		end = System.currentTimeMillis();
		System.out.println("偏向锁耗时:" + (end - start));

		//轻量级锁
		lightweightLock(lock);
		start = System.currentTimeMillis();
		for (int i = 0; i < TEST_COUNT; i++) {
			synchronized (lock) {}
		}
		end = System.currentTimeMillis();
		System.out.println("轻量级锁耗时:" + (end - start));

		//重量级锁
		weightLock(lock);
		start = System.currentTimeMillis();
		for (int i = 0; i < TEST_COUNT; i++) {
			synchronized (lock) {}
		}
		end = System.currentTimeMillis();
		System.out.println("重量级锁耗时:" + (end - start));
	}

	static void biasedLock(Object o){
		synchronized (o){}
	}

	//将锁升级为轻量级
	static void lightweightLock(Object o){
		biasedLock(o);

		Thread thread = new Thread(() -> {
			synchronized (o) {}
		});
		thread.start();
		try {
			thread.join();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}

	//将锁升级为重量级
	static void weightLock(Object o){
		lightweightLock(o);

		Thread t1 = new Thread(() -> {
			synchronized (o){
				sleep(1000);
			}
		});
		Thread t2 = new Thread(() -> {
			synchronized (o){
				sleep(1000);
			}
		});
		t1.start();
		t2.start();
		try {
			t1.join();
			t2.join();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
	
	static void sleep(long l){
		try {
			Thread.sleep(l);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
各类型锁性能测试
无锁:6
偏向锁耗时:252
轻量级锁耗时:2698
重量级锁耗时:1471

  • 1
  • 2
  • 3
  • 4
  • 5

由于是单线程，不涉及锁竞争，重量级锁反而比轻量级锁更快，因为不需要OS对线程进行额外的调度，线程无需挂起和唤醒，而且不用拷贝Mark Word。

在多线程竞争环境下，重量级锁性能下降是毋庸置疑的，如下测试：

public static void main(String[] args) throws InterruptedException {
	System.err.println("多线程测试");
	Lock lock = new Lock();
	long start;
	long end;

	//轻量级锁
	lightweightLock(lock);
	start = System.currentTimeMillis();
	for (int i = 0; i < TEST_COUNT; i++) {
		synchronized (lock) {}
	}
	end = System.currentTimeMillis();
	System.out.println("轻量级锁耗时:" + (end - start));

	//重量级锁
	weightLock(lock);
	Thread t1 = new Thread(() -> {
		for (int i = 0; i < TEST_COUNT / 2; i++) {
			synchronized (lock) {}
		}
	});
	Thread t2 = new Thread(() -> {
		for (int i = 0; i < TEST_COUNT / 2; i++) {
			synchronized (lock) {}
		}
	});
	t1.start();
	t2.start();
	start = System.currentTimeMillis();
	t1.join();
	t2.join();
	end = System.currentTimeMillis();
	System.out.println("重量级锁耗时:" + (end - start));
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
多线程测试
轻量级锁耗时:2581
重量级锁耗时:4460

  • 1
  • 2
  • 3

实际的应用环境远比测试环境复杂的多，锁性能和线程竞争的激烈程度、锁占用的时间也有很大关系，测试结果仅供参考。

你可能感兴趣的文章：

程序员小潘
微信公众号
专注于Java后端技术分享~
注：本文转载自blog.csdn.net的程序员小潘的文章"https://javap.blog.csdn.net/article/details/104506461"。版权归原作者所有，此博客不拥有其著作权，亦不承担相应法律责任。如有侵权，请联系我们删除。
复制链接
相关推荐
发表评论

评论记录：

未查询到任何数据！