三.多线程JUC篇-3.3 AtomicReference和AtomicStampReference

分手后的思念是犯贱 2022-11-22 00:16 68阅读 0赞

1.  虽然无锁比较交换让代码看起来比直接加锁复杂一点点，但是无锁比较交换能提供更高的效率，没错，且不存在死锁问题，但是无锁操作不是所有场景下都是安全的。
2.  先用最简单直白的概括回顾下CAS，有三个参数V，E，N，只有当“预期值”E和对象V的值相等时，才把V的值更新为“更新值”N。可以看到，是否修改V的值，取决于V的值和E是否相等，如果不相等，那么程序就会重新读取V的值，直到V的值与E相等后，才做修改操作(当然也可以放弃等待)。
3.  这样做看似没什么问题，但是在某些特定场景下，和实际应用中，是存在一些问题的，因为在多线程环境下，一个对象可能会被多个线程访问，修改，且修改的值是不确定的，所以无锁比较交换操作下可能出现的问题是以下这个情景：
    
    (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，直到与期望值相等，或是放弃，这种做法有一个问题，就是只看结果，而忽略了过程的改变。
4.  在某些特定场景中，忽略过程是会出问题的，例如我们看一个多线程操作同一个栈的例子：
    
        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修改后的栈状态冲突，可能会发生意想不到的灾难。
5.  解决的方法就是要“关注”这个过程信息，Java的atomic包中提供了AtomicStampedReference，与AtomicReference不同，它多了两个参数excpectedStamp和newStamp。这两个参数比较多人称它为版本号，也有人称它为时间戳，使用方法是这样：  
    AtomicStampedReference.compareAndSet(expectedReference,newReference,oldStamp,newStamp);