这是一个真实案例,曾经惹出硕大风波,故事的起因却很简单,就是需要实现一个简单的计数器,每次取值然后加1,于是就有了下面这段代码:
private int counter = 0;
public int getCount ( ) {
return counter++;
}
这个计数器被用于生成一个sessionId,这个sessionID用于和外部计费系统交互,这个sessionId理所当然的要求保证全局唯一而不重复。但是很遗憾,上面的代码最终被发现会产生相同的id,因此会造成一些请求莫名其妙的报错.....更痛苦的是,上面这段代码是一个来自其他部门开发的工具类,我们当时只是拿了它的jar包来调用,没有源码,更没有想这里面会有如此低级而可怕的错误。
由于重复的sessionId,造成有个别请求失败,虽然出现概率极低,经常跑一天测试都不见得能重现一次。因为是和计费相关,因此哪怕是再低的概率出错,也不得不要求解决。实际情况是,项目开发到最后阶段,都开始做发布前最后的稳定性测试了,在7*24小时的连续测试中,这个问题往往在测试开始几天后才重现,将当时负责trouble shooting的同事折腾的很惨......经过反复的查找,终于有人怀疑到这里,反编译了那个jar包,才看到上面这段出问题的代码。
这个低级的错误,源于一个java的基本知识:
++操作,无论是i++还是++i,都不是原子操作!
而一个非原子操作,在多线程并发下会有线程安全的问题:这里稍微解释一下,上面的"++"操作符,从原理上讲它其实包含以下:计算加1之后的新值,然后将这个新值赋值给原变量,返回原值。类似于下面的代码
private int counter = 0;
public int getCount ( ) {
int result = counter;
int newValue = counter + 1; // 1. 计算新值
counter = newValue; // 2. 将新值赋值给原变量
return result;
}
多线程并发时,如果两个线程同时调用getCount()方法,则他们可能得到相同的counter值。为了保证安全,一个最简单的方法就是在getCount()方法上做同步:
private int counter = 0;
public synchronized int getCount ( ) {
return counter++;
}
这样就可以避免因++操作符的非原子性而造成的并发危险。
我们在这个案例基础上稍微再扩展一下,如果这里的操作是原子操作,就可以不用同步而安全的并发访问吗?我们将这个代码稍作修改:
private int something = 0;
public int getSomething ( ) {
return something;
}
public void setSomething (int something) {
this.something = something;
}
假设有多线程同时并发访问getSomething()和setSomething()方法,那么当一个线程通过调用setSomething()方法设置一个新的值时,其他调用getSomething()的方法是不是立即可以读到这个新值呢?这里的"this.something = something;" 是一个对int 类型的赋值,按照java 语言规范,对int的赋值是原子操作,这里不存在上面案例中的非原子操作的隐患。
但是这里还是有一个重要问题,称为"内存可见性"。这里涉及到java内存模型的一系列知识,限于篇幅,不详尽讲述,不清楚这些知识点的可以自己翻翻资料,最简单的办法就是google一下这两个关键词"java 内存模型", "java 内存可见性"。或者,可以参考这个帖子"java线程安全总结", http://www.iteye.com/topic/806990。
解决这里的"内存可见性"问题的方式有两个,一个是继续使用 synchronized 关键字,代码如下
private int something = 0;
public synchronized int getSomething ( ) {
return something;
}
public synchronized void setSomething (int something) {
this.something = something;
}
另一个是使用volatile 关键字,
private volatile int something = 0;
public int getSomething ( ) {
return something;
}
public void setSomething (int something) {
this.something = something;
}
使用volatile 关键字的方案,在性能上要好很多,因为volatile是一个轻量级的同步,只能保证多线程的内存可见性,不能保证多线程的执行有序性。因此开销远比synchronized要小。
让我们再回到开始的案例,因为我们采用直接在 getCount() 方法前加synchronized 的修改方式,因此不仅仅避免了非原子性操作带来的多线程的执行有序性问题,也"顺带"解决了内存可见性问题。
OK,现在可以继续了,前面讲到可以通过在 getCount() 方法前加synchronized 的方式来解决问题,但是其实还有更方便的方式,可以使用jdk 5.0之后引入的concurrent包中提供的原子类,java.util.concurrent.atomic.Atomic***,如AtomicInteger,AtomicLong等。
private AtomicInteger counter = new AtomicInteger(0);
public int getCount ( ) {
return counter.incrementAndGet();
}
Atomic类不仅仅提供了对数据操作的线程安全保证,而且提供了一系列的语义清晰的方法如incrementAndGet(),getAndIncrement,addAndGet(),getAndAdd(),使用方便。更重要的是,Atomic类不是一个简单的同步封装,其内部实现不是简单的使用synchronized,而是一个更为高效的方式CAS (compare and swap) + volatile,从而避免了synchronized的高开销,执行效率大为提升。限于篇幅,关于“CAS”原理就不在这里讲诉。
因此,出于性能考虑,强烈建议尽量使用Atomic类,而不要去写基于synchronized关键字的代码实现。
最后总结一下,在这个帖子中我们讲诉了一下几个问题:
1. ++操作不是原子操作
2. 非原子操作有线程安全问题
3. 并发下的内存可见性
4. Atomic类通过CAS + volatile可以比synchronized做的更高效,推荐使用
分享到:
相关推荐
- 对于高并发场景,推荐使用原子类`java.util.concurrent.atomic`,而非`synchronized`关键字。 5. **数据访问**: - 使用JDBC时,推荐使用连接池管理数据库连接,如Druid或HikariCP。 - 避免使用`SELECT *`,...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 ...
- `java.util.concurrent.atomic`包中的原子类提供了线程安全的操作。 通过阅读和理解JDK1.8 API中文百度翻译版,开发者能够充分利用Java 1.8提供的各种特性和优化,编写出更高效、更易维护的代码。这份文档是每个...
介绍`java.util.concurrent`包中的关键组件,如`ExecutorService`、`ScheduledExecutorService`、`Future`等,并阐述它们在并发编程中的作用。 - **第2章:Synchronized关键字详解** 探讨为什么需要同步机制、`...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 ...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 ...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 JAR ...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 JAR...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 ...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 ...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 JAR ...
java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 JAR ...
- **原因:** Java中的char类型使用Unicode编码,一个char占2个字节,足够存放一个中文字符。 **8. 实现接口与继承类的最大区别?** - **接口:** 只能包含抽象方法和默认方法,提供一种标准的行为模式。 - **继承:*...
3. **锁与同步**:深入学习Java中的锁机制,如`synchronized`关键字,`java.util.concurrent.locks`包中的锁,以及原子变量(`java.util.concurrent.atomic`包),这些都是保证多线程数据一致性的重要手段。...