继续讲CAS算法，上篇文章我们知道，CAS算法底层实现，是通过CPU的原子指令来实现。
那么这里又有一个情景：
话说，有一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出A，并且two进行了一些操作变成了B，然后two又将V位置的数据变成A，这时候线程one进行CAS操作发现内存中仍然是A，然后one操作成功。
尽管线程one的CAS操作成功，但是不代表这个过程就是没有问题的。
为什么这样说？我们来想象这样的场景：
在你非常渴的情况下你发现一个盛满水的杯子，你一饮而尽。之后再给杯子里重新倒满水。然后你离开，当杯子的真正主人回来时看到杯子还是盛满水，他当然不知道是否被人喝完重新倒满。这个时候，问题就来了。这杯水已经不是之前的那杯水了。用本山大叔的话来说就是，你大爷还是你大爷，但你大妈已经不是你大妈了！
那么怎么解决这个ABA问题呢？
答案是：版本号。
在这个共享数据区加个版本号，每个线程修改时，都要拿出之前取得的版本号，来进行比较，如果版本号一致，则进行修改，并将版本号+1（当然加多少或减多少都是可以自己定义的）。
实际上，这也是很重要的一个保持数据一致性的设计思想，比如zookeeper，也是用这种机制来保持数据一致性。
为了解决ABA问题，伟大的java为我们提供了AtomicMarkableReference和AtomicStampedReference类。
还是回到上面喝水的例子，如果你是程序员的话，杯子的主人刚好也是你的好基友的话，他会在杯子下放个纸条，上面写上“0”，你喝完水后，把“0”改为“1”，然后你的好基友再回来一看，就知道你已经喝过他的水杯。这时候，他要不要再喝，就很考验你的之间的“基情”了！
下面是演示AtomicStampedReference用法的相关代码：
本人精通java高并发，DDD，微服务等技术实践，以及python，golang技术栈。 本人姓名郭莹城，坐标深圳，前IBM架构师、咨询师、敏捷开发技术教练，前IBM区块链研究小组成员、十四年架构设计工作经验，《区块链核心技术与应用》作者之一， 现有成熟团队提供区块链开发相关业务（公链，交易所，钱包，Dapp,智能合约）。 工作微信&QQ：360369487，交易所开发与区块链钱包开发业务，加我注明：博客园+开发，想学习golang和rust的同学，也可以加我微信，备注：博客园+golang或博客园+rust,谢谢！
有疑问加站长微信联系（非本文作者）
