并发编程原理与实战(二十三)StampedLock应用实战与其他锁性能对比分析
上一篇我们学习了StampedLock邮戳锁引入背景以及邮戳锁的三种锁模式、邮戳锁的特性以及邮戳锁的核心api。本来就来进一步学习邮戳锁的具体使用。
首先我们先来分析官方提供的实例,分析StampedLock的主要api方法的使用方法。官方提供的例子是多线程环境下更新点的坐标并计算到原点的距离,这个功能在日常的业务开发中并不是很常见,但不妨碍我们对相关api使用的了解。
多线程更新坐标并计算到原点的距离
核心需求分析
1、线程安全的更新坐标值
- 写操作需独占锁保证原子性,防止并发修改导致数据错乱
- 使用
writeLock()
获取写锁,更新后通过unlockWrite(stamp)
释放写锁。
2、高效的距离计算
- 优先采用乐观读(
tryOptimisticRead
)减少锁竞争,以便适合高频读取的场景。 - 若检测到写冲突(
validate(stamp)
失败),降级为悲观读锁重新获取数据。
3、数据一致性保证
- 乐观读需拷贝共享变量到局部变量,避免验证后数据被修改。
- 悲观读锁与写锁互斥,确保强一致性但可能降低吞吐量。
代码实现
我们对官方提供的例子稍微做了改造和备注,如下:
public class Point {// 坐标点private static double x, y;// 创建邮戳锁private static final StampedLock sl = new StampedLock();// 一个独占锁方法(写锁是独占的)public static void move(double deltaX, double deltaY) {// 获取写锁long stamp = sl.writeLock();try {// 修改坐标x += deltaX;y += deltaY;System.out.printf("Thread %s moved to (%.1f, %.1f)%n", Thread.currentThread().getName(), x, y);} finally {// 根据邮戳释放写锁sl.unlockWrite(stamp);}}// 一个只读的方法// 从乐观读锁升级为读锁(悲观读)public static double distanceFromOrigin() {// 尝试乐观读锁,返回非0的stamp表示当前无写锁long stamp = sl.tryOptimisticRead();try {retryHoldingLock:// 获取共享读锁for (; ; stamp = sl.readLock()) {// 存在写锁则重试获取写锁if (stamp == 0L)continue retryHoldingLock;// 尽可能单纯的读操作double currentX = x;double currentY = y;//检查乐观读期间是否有写操作,返回true表示数据有效,若返回false,需升级为悲观读或重试if (!sl.validate(stamp))continue retryHoldingLock;//计算二维平面上点 (x, y) 到原点 (0, 0)double distance = Math.hypot(currentX, currentY);System.out.printf("Thread %s calculated distance: %.2f%n", Thread.currentThread().getName(), distance);return distance;}} finally {//判断邮戳代表的是否是读锁//if (StampedLock.isReadLockStamp(stamp))if (isReadLockStamp(stamp))//释放读锁sl.unlockRead(stamp);}}// 乐观读锁升级为写锁public static void moveIfAtOrigin(double newX, double newY) {long stamp = sl.tryOptimisticRead();try {retryHoldingLock:for (; ; stamp = sl.writeLock()) {if (stamp == 0L)continue retryHoldingLock;double currentX = x;double currentY = y;if (!sl.validate(stamp))continue retryHoldingLock;if (currentX != 0.0 || currentY != 0.0)break;//尝试将读锁升级为写锁,返回新stamp或0。stamp = sl.tryConvertToWriteLock(stamp);if (stamp == 0L)//升级失败重新获取写锁。continue retryHoldingLock;// 排他访问x = newX;y = newY;return;}} finally {//判断邮戳代表的是否是写锁//if (StampedLock.isWriteLockStamp(stamp))if (!isReadLockStamp(stamp))//释放写锁sl.unlockWrite(stamp);}}// 读锁升级为写锁public static void moveIfAtOrigin2(double newX, double newY) {long stamp = sl.readLock();try {while (x == 0.0 && y == 0.0) {//尝试将读锁升级为写锁,返回新stamp或0。long ws = sl.tryConvertToWriteLock(stamp);if (ws != 0L) {stamp = ws;x = newX;y = newY;break;} else {//升级失败先释放读锁,再获取写锁sl.unlockRead(stamp);stamp = sl.writeLock();}}} finally {//释放写锁sl.unlock(stamp);}}/**判断是否是读锁**/public static boolean isReadLockStamp(long stamp) {return (stamp & 0xFFL) != 0L;}
}
读写线程比例设计
例子中并没有提供怎么使用多线程来读写坐标的方法,所以我们来补充这个多线程读写的方法。既然StampedLock适合在读多写少的场景中使用,那么读线程要比写线程多,以便模拟高频读和低频写操作的场景,且写线程间隔时间应明显大于读线程(如5秒 vs 300ms)以观察锁竞争情况。基于上述分析,我们增加一个main函数来测试下上述代码。
public static void main(String[] args) {//创建1个写线程new Thread(() -> {for (; ; ) {move(2.0, 2.0);try {//5秒写一次坐标Thread.sleep(5000);} catch (InterruptedException e) {e.printStackTrace();}}}).start();//创建9个读线程for (int i = 0; i < 9; i++) {new Thread(() -> {for (; ; ) {distanceFromOrigin();try {//300毫秒秒读一次坐标Thread.sleep(300);} catch (InterruptedException e) {e.printStackTrace();}}}).start();}
}
main函数中,我们创建一个线程不断的移动坐标,每5秒执行一次移动坐标操作(写操作);创建9个读线程不断读坐标值并计算到圆点的距离,每300毫秒秒读一次坐标。观察下运行结果:
Thread Thread-0 moved to (2.0, 2.0)
Thread Thread-2 calculated distance: 2.83
Thread Thread-4 calculated distance: 2.83
Thread Thread-5 calculated distance: 2.83
Thread Thread-7 calculated distance: 2.83
Thread Thread-6 calculated distance: 2.83
Thread Thread-8 calculated distance: 2.83
Thread Thread-1 calculated distance: 2.83
Thread Thread-3 calculated distance: 2.83
Thread Thread-9 calculated distance: 2.83
...
Thread Thread-0 moved to (4.0, 4.0)
Thread Thread-8 calculated distance: 5.66
Thread Thread-7 calculated distance: 5.66
Thread Thread-5 calculated distance: 5.66
Thread Thread-3 calculated distance: 5.66
Thread Thread-1 calculated distance: 5.66
Thread Thread-2 calculated distance: 5.66
Thread Thread-4 calculated distance: 5.66
Thread Thread-9 calculated distance: 5.66
...
从运行结果可以看出,写操作和读操作是互斥的,数据没有任何错乱。
乐观读性能分析
乐观锁实现
那问题来了,这个例子中怎么体现使用StampedLock的乐观读后带来的性能提升?所以我们得用之前已经掌握的锁来读操作来进行对比。首先先对distanceFromOrigin()方法进行改造,增加读取耗时打印,如下:
// 一个只读的方法
// 从乐观读锁升级为读锁(悲观读)
public static double distanceFromOrigin() {long startTime = System.currentTimeMillis();// 尝试乐观读锁,返回非0的stamp表示当前无写锁long stamp = sl.tryOptimisticRead();double distance = 0;try {retryHoldingLock:// 获取共享读锁for (; ; stamp = sl.readLock()) {// 存在写锁则重试获取写锁if (stamp == 0L)continue retryHoldingLock;// 尽可能单纯的读操作double currentX = x;double currentY = y;//检查乐观读期间是否有写操作,返回true表示数据有效,若返回false,需升级为悲观读或重试if (!sl.validate(stamp))continue retryHoldingLock;//计算二维平面上点 (x, y) 到原点 (0, 0)distance = Math.hypot(currentX, currentY);System.out.printf("Thread %s calculated distance: %.2f%n", Thread.currentThread().getName(), distance);break;}} finally {//判断邮戳代表的是否是读锁//if (StampedLock.isReadLockStamp(stamp))if (isReadLockStamp(stamp))//释放读锁sl.unlockRead(stamp);long endTime = System.currentTimeMillis();System.out.println("Thread "+Thread.currentThread().getName()+" calculated distance cost time: "+(endTime-startTime));return distance;}
}
运行结果如下:
Thread Thread-1 calculated distance: 0.00
Thread Thread-0 moved to (2.0, 2.0)
Thread Thread-1 calculated distance cost time: 37
Thread Thread-2 calculated distance: 2.83
Thread Thread-2 calculated distance cost time: 29
Thread Thread-9 calculated distance: 2.83
Thread Thread-8 calculated distance: 2.83
Thread Thread-8 calculated distance cost time: 26
Thread Thread-7 calculated distance: 2.83
Thread Thread-7 calculated distance cost time: 26
Thread Thread-6 calculated distance: 2.83
Thread Thread-6 calculated distance cost time: 27
Thread Thread-5 calculated distance: 2.83
Thread Thread-5 calculated distance cost time: 27
Thread Thread-4 calculated distance: 2.83
Thread Thread-4 calculated distance cost time: 30
Thread Thread-3 calculated distance: 2.83
Thread Thread-3 calculated distance cost time: 31
Thread Thread-9 calculated distance cost time: 25
独占锁synchronized实现
下面使用synchronized对读取坐标过程加锁,代码如下:
public static double distanceFromOrigin2() {long startTime = System.currentTimeMillis();double distance = 0;synchronized (Point.class) {// 尽可能单纯的读操作double currentX = x;double currentY = y;distance = Math.hypot(currentX, currentY);System.out.printf("Thread %s calculated distance: %.2f%n", Thread.currentThread().getName(), distance);}long endTime = System.currentTimeMillis();System.out.println("Thread " + Thread.currentThread().getName() + " calculated distance cost time: " + (endTime - startTime));return distance;
}
main方法中读线程改成调用该方法
//创建10个读线程
for (int i = 0; i < 9; i++) {new Thread(() -> {for (; ; ) {//distanceFromOrigin();distanceFromOrigin2();try {//300毫秒秒写一次坐标Thread.sleep(300);} catch (InterruptedException e) {e.printStackTrace();}}}).start();
}
看看运行结果
Thread Thread-0 moved to (2.0, 2.0)
Thread Thread-2 calculated distance: 2.83
Thread Thread-2 calculated distance cost time: 31
Thread Thread-9 calculated distance: 2.83
Thread Thread-9 calculated distance cost time: 8
Thread Thread-8 calculated distance: 2.83
Thread Thread-8 calculated distance cost time: 9
Thread Thread-7 calculated distance: 2.83
Thread Thread-7 calculated distance cost time: 14
Thread Thread-6 calculated distance: 2.83
Thread Thread-6 calculated distance cost time: 31
Thread Thread-5 calculated distance: 2.83
Thread Thread-5 calculated distance cost time: 32
Thread Thread-4 calculated distance: 2.83
Thread Thread-4 calculated distance cost time: 33
Thread Thread-3 calculated distance: 2.83
Thread Thread-3 calculated distance cost time: 34
Thread Thread-1 calculated distance: 2.83
Thread Thread-1 calculated distance cost time: 34
从运行结果看,synchronized的性能视乎更好,可能因为synchronized内部已经做了优化的结果。我们换成ReentrantLock看看。
// 一个只读的方法
// ReentrantLock实现
public static double distanceFromOrigin3() {long startTime = System.currentTimeMillis();double distance = 0;lockObject.lock();try {// 尽可能单纯的读操作double currentX = x;double currentY = y;distance = Math.hypot(currentX, currentY);} finally {lockObject.unlock();}System.out.printf("Thread %s calculated distance: %.2f%n", Thread.currentThread().getName(), distance);long endTime = System.currentTimeMillis();System.out.println("Thread " + Thread.currentThread().getName() + " calculated distance cost time: " + (endTime - startTime));return distance;
}
运行结果
Thread Thread-0 moved to (2.0, 2.0)
Thread Thread-1 calculated distance: 2.83
Thread Thread-2 calculated distance: 2.83
Thread Thread-2 calculated distance cost time: 38
Thread Thread-3 calculated distance: 2.83
Thread Thread-3 calculated distance cost time: 34
Thread Thread-4 calculated distance: 2.83
Thread Thread-4 calculated distance cost time: 35
Thread Thread-5 calculated distance: 2.83
Thread Thread-5 calculated distance cost time: 35
Thread Thread-6 calculated distance: 2.83
Thread Thread-6 calculated distance cost time: 31
Thread Thread-7 calculated distance: 2.83
Thread Thread-7 calculated distance cost time: 32
Thread Thread-8 calculated distance: 2.83
Thread Thread-8 calculated distance cost time: 31
Thread Thread-9 calculated distance: 2.83
Thread Thread-9 calculated distance cost time: 31
Thread Thread-1 calculated distance cost time: 39
换成ReentrantLock后,从运行结果可以看出,耗时明细长了,都在30毫秒以上,这从侧面印证乐观锁的性能确实比ReentrantLock好。
总结
本文通过官方提供的多线程更新坐标并计算到原点的距离这个例子,说明了StampedLock的应用,然后通过设计不同的读写线程,分析读写坐标时的数据一致性,最后通过用ReentrantLock和synchronized分别对读取坐标进行加锁,对比了与StampedLock 乐观锁实现的耗时。通过该例子,进一步加深了对StampedLock 的理解。