-
虽然无锁比较交换让代码看起来比直接加锁复杂一点点,但是无锁比较交换能提供更高的效率,没错,且不存在死锁问题,但是无锁操作不是所有场景下都是安全的。
-
先用最简单直白的概括回顾下CAS,有三个参数V,E,N,只有当“预期值”E和对象V的值相等时,才把V的值更新为“更新值”N。可以看到,是否修改V的值,取决于V的值和E是否相等,如果不相等,那么程序就会重新读取V的值,直到V的值与E相等后,才做修改操作(当然也可以放弃等待)。
-
这样做看似没什么问题,但是在某些特定场景下,和实际应用中,是存在一些问题的,因为在多线程环境下,一个对象可能会被多个线程访问,修改,且修改的值是不确定的,所以无锁比较交换操作下可能出现的问题是以下这个情景:
(1) 使用AtomicReference的无锁比较交换,假设对象V的初始值为0,线程T1要对对象V做修改操作,首先取得V的值为0保存到变量tmp中后,在做修改操作V.compareAndSet(tmp, tmp+1);之前,线程T1被阻塞了(可能cpu调度或时间片问题),此时另外的线程T2和T3也对这个对象V做修改操作,T2线程把V修改为1,接着T3线程把V修改回0,最后当T1线程唤醒继续执行修改操作,发现tmp的值为0,仍然为预期值,接着就对对象V写入新值。
(2) 上述这个场景我们可以发现,T1线程做compareAndSet()方法时,拿到的tmp其实是个新值,只是这个新值与旧值相等了,所以T1线程“以为”对象V没有做过修改,符和预期值。虽然从结果上看,这样做好像没什么问题,对于T1线程来说,它的任务就是当对象V的值等于期望值tmp(也就是为0)时,把它修改为1嘛。在这样的场景下可能是没问题,例如,如果你要做累加或累减操作,这样无锁比较交换是不会出错的,哪怕过程中有其他线程做过修改,只要对象的值不符合期望值,当前线程都不会对对象的值做修改,而是一直重复读取对象V,直到与期望值相等,或是放弃,这种做法有一个问题,就是只看结果,而忽略了过程的改变。
-
在某些特定场景中,忽略过程是会出问题的,例如我们看一个多线程操作同一个栈的例子:
package atomicstampedreference; import java.util.concurrent.atomic.AtomicReference; public class Stack { private AtomicReference<Node> stackTop = new AtomicReference<>(); //栈的存储结构 static class Node { int value; Node next; //指向下一个结点 //构造函数初始化 public Node(int value) { this.value = value; } } //无锁CAS入栈 public void push(Node newNode) { //无锁CAS操作,所以用一个死循环 for(;;) { Node tmpTop = stackTop.get(); //首先获得栈顶结点 newNode.next = tmpTop; //新栈顶结点的next指向旧的栈顶结点 //更新新的栈顶结点 if(stackTop.compareAndSet(tmpTop, newNode)) { return; } } } //无锁CAS出栈 public Node pop() { //同样死循环 for(;;) { Node tmpTop = stackTop.get(); //获得栈顶结点 //特殊情况判断 if(tmpTop == null) { System.out.println("错误!栈顶元素为空."); return null; } Node newTop = tmpTop.next; //保存栈中的新栈顶结点 //更新栈顶结点 if(stackTop.compareAndSet(tmpTop, newTop)) { tmpTop.next = null; return tmpTop; } } } //输出当前栈 public void printStack() { } }
package atomicstampedreference; public class UnSafeStack { public static void main(String[] args) { Stack stack = new Stack(); //实例化栈 Stack.Node node1 = new Stack.Node(1); Stack.Node node2= new Stack.Node(2); Stack.Node node3= new Stack.Node(3); //三个结点入栈 stack.push(node3); stack.push(node2); stack.push(node1); Thread T1 = new Thread(new Runnable() { @Override public void run() { Stack.Node tmp = stack.pop(); } }); Thread T2 = new Thread(new Runnable() { @Override public void run() { Stack.Node tmp1 = stack.pop(); Stack.Node tmp2 = stack.pop(); stack.push(tmp1); } }); T1.start(); T2.start(); } }
我们往栈中压入三个结点,值分别为int型1,2,3。在线程T1中做出栈操作中,取得当前栈顶元素后,先让线程T1阻塞,模拟cpu调度。此时另一个线程启动,做两次出栈操作和一次入栈操作,那么结点1和2都被出栈,栈中只剩结点3,然后在把结点1入栈,之后当前栈变成1->3,线程完成任务。然后我们让线程T1唤醒,继续它的任务,此时线程T1执行compareAndSet()方法,虽然方法重新获取一遍tmpTop的值,但发现发现栈顶元素的value还是等于1,与期望值相等,所以把结点1出栈,之后就出问题了,compareAndSet()方法操作是更新栈顶元素,此时线程T1会把栈顶元素也就是tmpTop更新为结点2。这与线程2修改后的栈状态冲突,可能会发生意想不到的灾难。
-
解决的方法就是要“关注”这个过程信息,Java的atomic包中提供了AtomicStampedReference,与AtomicReference不同,它多了两个参数excpectedStamp和newStamp。这两个参数比较多人称它为版本号,也有人称它为时间戳,使用方法是这样:
AtomicStampedReference.compareAndSet(expectedReference,newReference,oldStamp,newStamp);
三.多线程JUC篇-3.3 AtomicReference和AtomicStampReference
最新推荐文章于 2022-04-09 20:38:07 发布