无锁
在JDK 5之前Java语言是靠synchronized关键字保证同步的,这会导致有锁
锁机制存在以下问题:
(1)在多线程竞争下,加锁、释放锁会导致比较多的上下文切换和调度延时,引起性能问题。
(2)一个线程持有锁会导致其它所有需要此锁的线程挂起。
(3)如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置,引起性能风险。
volatile是不错的机制,但是volatile不能保证原子性。因此对于同步最终还是要回到锁机制上来。
独占锁是一种悲观锁,synchronized就是一种独占锁,会导致其它所有需要锁的线程挂起,等待持有锁的线程释放锁。而另一个更加有效的锁就是乐观锁。所谓乐观锁就是,每次不加锁而是假设没有冲突而去完成某项操作,如果因为冲突失败就重试,直到成功为止。乐观锁用到的机制就是CAS,Compare and Swap。
无锁的原理
无锁的非堵塞算法采用一种比较交换技术CAS(compare and swap)来鉴别线程冲突,一旦检测到冲突,就充实当前操作指导没有冲突为止。CAS基于硬件实现,不需要进入内核,不需要切换线程,因此可以获得更高的性能。但对于资源竞争严重的情况,CAS自旋的概率会比较大,从而浪费更多的CPU资源。
CAS是项乐观锁技术,当多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能更新变量的值,而其它线程都失败,失败的线程并不会被挂起,而是被告知这次竞争中失败,并可以再次尝试。
CAS(比较并交换)是CPU指令级的操作,只有一步原子操作,CAS有3个操作数,内存值V,旧的预期值A,要修改的新值B。当且仅当预期值A和内存值V相同时,将内存值V修改为B,否则什么都不做。CAS语义是“我认为V的值应该是A,如果是,那么就将V的值更新成B, 否则不更新,并告诉V的实际是是多少”。
伪代码可以这样表示:
do{
备份旧数据;
基于旧数据构造新数据;
}while(!CAS( 内存地址,备份的旧数据,新数据 ))
就是指当两者进行比较时,如果相等,则证明共享数据没有被修改,替换成新值,然后继续往下运行;如果不相等,说明共享数据已经被修改,放弃已经所做的操作,然后重新执行刚才的操作。容易看出 CAS 操作是基于共享数据不会被修改的假设,采用了类似于数据库的 commit-retry 的模式。当同步冲突出现的机会很少时,这种假设能带来较大的性能提升。
有没有可能在判断V和E相同后,正要赋值时,切换了线程,更改了值。造成了数据不一致呢?
事实上,这个担心是多余的。CAS整一个操作过程是一个原子操作,它是由一条CPU指令完成的。在java中实现CAS的类也必定是一个原子性的操作,可以在java代码看到源码,cas的实现过程是navite,直接调用本地脚本处理的 cmpxchg,所以是原子的,不必担心线程安全
无锁的缺点
虽然CAS有效的解决了原子操作的问题,但是其仍然有三个劣势:
1、ABA问题:因为CAS需要在操作前检查下值有没有发生变化,如果没有则更新。但是如果一个值开始的时候是A,变成了B,又变成了A,那么使用CAS进行检查的时候会发现它的值没有发生变化,但是事实却不是如此。
ABA问题的解决思路是使用版本号,如A-B-A变成1A-2B-3A
2、循环时间长开销大:自旋CAS如果长时间不成功,会给CPU带来非常大的执行开销。
3、只能保证一个共享变量的原子操作:对一个共享变量可以使用CAS进行原子操作,但是多个共享变量的原子操作就无法使用CAS,这个时候只能使用锁。
java中无锁类
1.AtomicInteger
AtomicInteger和Integer一样,都继承与Number类
public class AtomicInteger extends Number implements java.io.Serializable
AtomicInteger里面有很多CAS操作,典型的有:
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
其实偏移量为valueOffset的变量就是value这里来解释一下unsafe.compareAndSwapInt方法,他的意思是,对于this这个类上的偏移量为valueOffset的变量值如果与期望值expect相同,那么把这个变量的值设为update。
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
我们此前说过,CAS是有可能会失败的,但是失败的代价是很小的,所以一般的实现都是在一个无限循环体内,直到成功为止。
public final int getAndIncrement() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return current;
}
}
2.Unsafe
从类名就可知,Unsafe操作是非安全的操作,比如:
- 根据偏移量设置值(在刚刚介绍的AtomicInteger中已经看到了这个功能)
- park()(把这个线程停下来,在以后的Blog中会提到)
- 底层的CAS操作
非公开API,在不同版本的JDK中,可能有较大差异
3.AtomicReference
前面已经提到了AtomicInteger,当然还有AtomicBoolean,AtomicLong等等,都大同小异。
这里要介绍的是AtomicReference。
AtomicReference是一种模板类
public class AtomicReference<V> implements java.io.Serializable
比如String它可以用来封装任意类型的数据。
public class Test
{
public final static AtomicReference<String> atomicString = new AtomicReference<String>("hosee");
public static void main(String[] args)
{
for (int i = 0; i < 10; i++)
{
final int num = i;
new Thread() {
public void run() {
try
{
Thread.sleep(Math.abs((int)Math.random()*100));
}
catch (Exception e)
{
e.printStackTrace();
}
if (atomicString.compareAndSet("hosee", "ztk"))
{
System.out.println(Thread.currentThread().getId() + "Change value");
}else {
System.out.println(Thread.currentThread().getId() + "Failed");
}
};
}.start();
}
}
}
结果
10Failed
13Failed
9Change value
11Failed
12Failed
15Failed
17Failed
14Failed
16Failed
18Failed
可以看到只有一个线程能够修改值,并且后面的线程都不能再修改。
5.AtomicStampedReference
我们会发现CAS操作还是有一个问题的
比如之前的AtomicInteger的incrementAndGet方法
public final int incrementAndGet() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next;
}
}
假设当前value=1当某线程int current = get()执行后,切换到另一个线程,这个线程将1变成了2,然后又一个线程将2又变成了1。此时再切换到最开始的那个线程,由于value仍等于1,所以还是能执行CAS操作,当然加法是没有问题的,如果有些情况,对数据的状态敏感时,这样的过程就不被允许了。
此时就需要AtomicStampedReference类。
其内部实现一个Pair类来封装值和时间戳。
private static class Pair<T> {
final T reference;
final int stamp;
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
static <T> Pair<T> of(T reference, int stamp) {
return new Pair<T>(reference, stamp);
}
}
这个类的主要思想是加入时间戳来标识每一次改变。
//比较设置 参数依次为:期望值 写入新值 期望时间戳 新时间戳
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
Pair<V> current = pair;
return
expectedReference == current.reference &&
expectedStamp == current.stamp &&
((newReference == current.reference &&
newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}
当期望值等于当前值,并且期望时间戳等于现在的时间戳时,才写入新值,并且更新新的时间戳。
这里举个用AtomicStampedReference的场景,可能不太适合,但是想不到好的场景了。
场景背景是,某公司给余额少的用户免费充值,但是每个用户只能充值一次。
public class Test
{
static AtomicStampedReference<Integer> money = new AtomicStampedReference<Integer>(
19, 0);
public static void main(String[] args)
{
for (int i = 0; i < 3; i++)
{
final int timestamp = money.getStamp();
new Thread()
{
public void run()
{
while (true)
{
while (true)
{
Integer m = money.getReference();
if (m < 20)
{
if (money.compareAndSet(m, m + 20, timestamp,
timestamp + 1))
{
System.out.println("充值成功,余额:"
+ money.getReference());
break;
}
}
else
{
break;
}
}
}
};
}.start();
}
new Thread()
{
public void run()
{
for (int i = 0; i < 100; i++)
{
while (true)
{
int timestamp = money.getStamp();
Integer m = money.getReference();
if (m > 10)
{
if (money.compareAndSet(m, m - 10, timestamp,
timestamp + 1))
{
System.out.println("消费10元,余额:"
+ money.getReference());
break;
}
}else {
break;
}
}
try
{
Thread.sleep(100);
}
catch (Exception e)
{
// TODO: handle exception
}
}
};
}.start();
}
}
解释下代码,有3个线程在给用户充值,当用户余额少于20时,就给用户充值20元。有100个线程在消费,每次消费10元。用户初始有9元,当使用AtomicStampedReference来实现时,只会给用户充值一次,因为每次操作使得时间戳+1。运行结果:
充值成功,余额:39
消费10元,余额:29
消费10元,余额:19
消费10元,余额:9
如果使用AtomicReference<Integer>或者 Atomic Integer来实现就会造成多次充值。
充值成功,余额:39
消费10元,余额:29
消费10元,余额:19
充值成功,余额:39
消费10元,余额:29
消费10元,余额:19
充值成功,余额:39
消费10元,余额:29
6.AtomicIntegerArray
与AtomicInteger相比,数组的实现不过是多了一个下标。
public final boolean compareAndSet(int i, int expect, int update) {
return compareAndSetRaw(checkedByteOffset(i), expect, update);
}
它的内部只是封装了一个普通的array
private final int[] array;
7.AtomicIntegerFieldUpdater
AtomicIntegerFieldUpdater类的主要作用是让普通变量也享受原子操作。
就比如原本有一个变量是int型,并且很多地方都应用了这个变量,但是在某个场景下,想让int型变成AtomicInteger,但是如果直接改类型,就要改其他地方的应用。AtomicIntegerFieldUpdater就是为了解决这样的问题产生的。
public class Test
{
public static class V{
int id;
volatile int score;
public int getScore()
{
return score;
}
public void setScore(int score)
{
this.score = score;
}
}
public final static AtomicIntegerFieldUpdater<V> vv = AtomicIntegerFieldUpdater.newUpdater(V.class, "score");
public static AtomicInteger allscore = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException
{
final V stu = new V();
Thread[] t = new Thread[10000];
for (int i = 0; i < 10000; i++)
{
t[i] = new Thread() {
@Override
public void run()
{
if(Math.random()>0.4)
{
vv.incrementAndGet(stu);
allscore.incrementAndGet();
}
}
};
t[i].start();
}
for (int i = 0; i < 10000; i++)
{
t[i].join();
}
System.out.println("score="+stu.getScore());
System.out.println("allscore="+allscore);
}
}
上述代码将score使用 AtomicIntegerFieldUpdater变成 AtomicInteger。保证了线程安全。
这里使用allscore来验证,如果score和allscore数值相同,则说明是线程安全的。
小说明:
- Updater只能修改它可见范围内的变量。因为Updater使用反射得到这个变量。如果变量不可见,就会出错。比如如果某变量申明为private,就是不可行的。
- 为了确保变量被正确的读取,它必须是volatile类型的。如果我们原有代码中未申明这个类型,那么简单得申明一下就行,这不会引起什么问题。
- 由于CAS操作会通过对象实例中的偏移量直接进行赋值,因此,它不支持static字段(Unsafe.objectFieldOffset()不支持静态变量)。