热门话题volatile 变量的++ 操作不是线程安全的
实例验证一下
private volatile int counter = 0;
static final int MAX_VALUE = 1000;
static final int threadCount = 50;
//hashSet不是线程安全的，可以用AtomicInteger验证。
//private Set<Integer> resultSet = new HashSet<Integer>(MAX_VALUE);
private ConcurrentHashMap<Integer,Integer> concurrentHashMap = new ConcurrentHashMap(threadCount* MAX_VALUE);
private Set<Integer> resultSet = Collections.synchronizedSet(new HashSet<Integer>(threadCount* MAX_VALUE));
private AtomicInteger atomicCounter = new AtomicInteger(0);
/**
* 测试多线程环境下，int类型的++不是原子性操作，会带来线程安全的问题
* 案例：int 类型的counter 从 0 开始执行++操作，直到counter的值达到10万，
* 分析：因为int 变量的++的操作，本身不是原子性，所以会产生线程安全问题，举例来说
* i 此时为 10，两个线程同时读到i的值为10，
* thread1： i++ i的值为11
* thread2： i++ i的值也为11；
* 我们用去重容器来存储++后的值，如果容器中的元素个数为10万，索命多线程下，每次+1都正常；若容器中元素个数小于10万，说明有重复的值。每次+1的操作不是线程安全的。
* 去重容器通过size（） 获取大小，方便的从个数上来判断出是否有重复，但是不能直观的知道到底是哪个重复了。
* 还可以借助 ConcurrentHashMap.put方法的返回值 非null的情况下，就是重复的值。
*
* 比如出现如下结果：表明 15号和12号线程都出现了counter=11的情况，
* 15 : 11 has already exits
* 12 :11
* 问题是 concurrentHashMap resultSet 两个的大小不同，concurrentHashMap的结果是正确的，resultSet的size（）值不正确。
*/
@Test
public void testNotAtomicOptWithConcurrentHashMap() throws InterruptedException {
//5个线程通知开工
Thread[] threads = new Thread[threadCount];
for (int i = 0; i < threadCount; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
int i = 0;
while (i++ < MAX_VALUE) {
//counter +=1;
counter++;
resultSet.add(counter);
Integer oldValue = concurrentHashMap.put(counter, counter);
if(oldValue != null){
System.out.println(Thread.currentThread().getId() + " : " + counter + " has already exits");
}else {
System.out.println(Thread.currentThread().getId() + " :" + counter);
}
}
}
});
threads[i].start();
}
for(int i=0;i<threadCount;i++){
threads[i].join();
}
//size()返回的是容器中元素的个数，而不是容器的初始大小。
System.out.println(resultSet.size()); //概率事件 ： 小于 MAX_VALUE
System.out.println(concurrentHashMap.size()); //概率事件 ： 小于 MAX_VALUE;
}
*结果：
省略---
16 :518
14 : 517 has already exits
19 :517
18 :516
再省略---
33 :49997
33 :49998
49993 //set的大小
49927 //xxxmap的大小
image.png
set和map里的元素是不连续的有缺失的。
map里缺失的更多一些。
所谓的相加总数是指put的次数没有少；
悬疑
按理说set和map里都没有重复的呀，可是为set和map容器中元素个数不一样呢？
先放到hashmap容器再放set容器也不行，总是不一样。
解决悬疑
两个容器里的元素肯定都是不重复的，这个不一致的现象还是要 按竞态条件（并发基本概念）的角度来考虑。
举例来说，所有线程set往里边放的时候，counter的值还是1，map.put的时候，counter的值就变成了2，所以map往容器放的就漏掉了1的情况；那么在put的时候本该有线程放1进去，结果都放的是2，就进入了key已存在的逻辑。
这种情况跟++的结果不确定是一样的本质原因；即你在使用它的时候，它的因为多线程对函数调用顺序的原因而导致这个值在使用的时候是不确定的。
/**
* 上个实例中往容器里放的时候都是直接操作的counter对象，counter对象作为竞态变量在运行时每一次使用时的值是不确定的，
* 使用局部变量来存储counter的值，容器都对这个局部变量操作，这样容器最终元素的个数就一致了。疑问还是有的，是不是可以按照竞态条件来考虑，需要进一步确认
*
* @throws InterruptedException
*/
@Test
public void testNotAtomicOptWithConcurrentHashMap_v2() throws InterruptedException {
//5个线程通知开工
Thread[] threads = new Thread[threadCount];
for (int i = 0; i < threadCount; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
int i = 0;
while (i++ < MAX_VALUE) {
//加个局部变量。这样能解决容器了元素个数不同的问题。
int tempNum = counter++;
Integer oldValue = concurrentHashMap.put(tempNum, tempNum);
resultSet.add(tempNum);
if(oldValue != null){
System.out.println(Thread.currentThread().getId() + " : " + tempNum + " has already exits");
}else {
System.out.println(Thread.currentThread().getId() + " :" + tempNum);
}
}
}
});
threads[i].start();
}
for(int i=0;i<threadCount;i++){
threads[i].join();
}
//size()返回的是容器中元素的个数，而不是容器的初始大小。
System.out.println(resultSet.size()); //概率事件 ： 小于 MAX_VALUE
System.out.println(concurrentHashMap.size()); //概率事件 ： 小于 MAX_VALUE;
}
上半场总结
++ 问题 和 两个容器的元素个数不同的问题，本质是相同的是竞态变量的读写操作的必然现象，只是从两个不同的维度来拆开分析。
- ++ 问题 是漏读了最新值。
两个线程都拿旧值进行++，其实第二线程应该用第一个线程++后的新值的基础上进行++；所以这是漏读。 - 容器大小不同 后调用的容器是漏写了旧值。
a容器写的时候读到的值是 1，紧接着b容器写的时候读到的值是2，b写了2却漏掉了1；所以这是漏写。
下半场开始使用atomic轻松解决漏读的操作，但是写的时候还是要自己注意的。
- 实例1 AtomicInteger自增来替换++问题
/**
* 多线程的++情况，使用AtomicInteger 来测试验证。这里使用了局部变量，每个循环里，只读取counter一次。
* 容器中都不会缺失
*
* @throws InterruptedException
*/
@Test
public void testAtomicIntegerThreadSafe() throws InterruptedException {
//5个线程通知开工
Thread[] threads = new Thread[threadCount];
for (int i = 0; i < threadCount; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
int i = 0;
while (i++ < MAX_VALUE) {
int iresult = atomicCounter.addAndGet(1);
resultSet.add(iresult);
Integer oldValue = concurrentHashMap.put(iresult, iresult);
if(oldValue != null){
System.out.println(Thread.currentThread().getId() + " : " + iresult + " has already exits");
}else {
System.out.println(Thread.currentThread().getId() + " :" + iresult);
}
}
}
});
threads[i].start();
}
for(int i=0;i<threadCount;i++){
threads[i].join();
}
//Thread.sleep(10000);
//size()返回的是容器中元素的个数，而不是容器的初始大小。
System.out.println(resultSet.size()); //概率事件 ： 小于 MAX_VALUE
System.out.println(concurrentHashMap.size()); //概率事件 ： 小于 MAX_VALUE;
}
为什么Atomic就能解决漏读的情况呢
- 循环 + CAS
- CAS避免漏读的情况下，去做写操作（只有根据最新的值所做的写操作才有效）。
- while循环就是给我们不断去获取最新值的机会。
- 源码证明AtomicInteger中拿出来两个举例：
public final int getAndUpdate(IntUnaryOperator updateFunction) {
int prev, next;
do {
prev = get();
next = updateFunction.applyAsInt(prev);
} while (!compareAndSet(prev, next));
return prev;
}
public final int updateAndGet(IntUnaryOperator updateFunction) {
int prev, next;
do {
prev = get();
next = updateFunction.applyAsInt(prev);
} while (!compareAndSet(prev, next));
return next;
}
漏写的问题依然存在
注意 注意 如果不用局部变量只读取一次，而是多次读取，那就会出现(⊙o⊙)…
/**
* 多线程的++情况，使用AtomicInteger 来测试验证。每个循环里，多次读取counter。
* 容器里依然会缺失。
*
* @throws InterruptedException
*/
@Test
public void testAtomicIntegerThreadSafe_v2() throws InterruptedException {
//5个线程通知开工
Thread[] threads = new Thread[threadCount];
for (int i = 0; i < threadCount; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
int i = 0;
while (i++ < MAX_VALUE) {
resultSet.add(atomicCounter.addAndGet(1));
Integer oldValue = concurrentHashMap.put(atomicCounter.get(), atomicCounter.get());
if(oldValue != null){
System.out.println(Thread.currentThread().getId() + " : " + atomicCounter.get() + " has already exits");
}else {
System.out.println(Thread.currentThread().getId() + " :" + atomicCounter.get());
}
}
}
});
threads[i].start();
}
for(int i=0;i<threadCount;i++){
threads[i].join();
}
//Thread.sleep(10000);
//size()返回的是容器中元素的个数，而不是容器的初始大小。
System.out.println(resultSet.size()); //概率事件 ： 小于 MAX_VALUE
System.out.println(concurrentHashMap.size()); //概率事件 ： 小于 MAX_VALUE;
}
可怕的结果
31 :49999
31 :50000
set 里是50000个元素
map里是49947个元素
传送门：ClassLoader串烧
传送门：阿里开源框架JVM-Sandbox源码梳理
