示例: JAVA多线程模拟用户行为(100个用户),每个用户访问10次网站、简单模拟下CAS 最终已源码为准(CAS)
-
常规写法
import java.util.concurrent.CountDownLatch; import java.util.concurrent.TimeUnit; public class Demo { // 总访问量 static int count = 0; //模拟访问的方法 public static void request() throws InterruptedException { // 模拟耗时5毫秒 TimeUnit.MICROSECONDS.sleep(5); count++; } /** * 示例: 模拟用户行为(100个用户),每个用户访问10次网站 */ public static void main(String[] args) throws InterruptedException { // 开始时间 long startTime = System.currentTimeMillis(); // 100个用户 int threadSize = 100; //栅栏 保证100个线程全部执行完毕 CountDownLatch countDownLatch = new CountDownLatch(threadSize); for (int i = 0; i < threadSize; i++) { new Thread(() -> { try { // 模拟 每个用户访问10次网站 for (int y = 0; y < 10; y++) { request(); } } catch (InterruptedException e) { e.printStackTrace(); } finally { countDownLatch.countDown(); } }).start(); } // 怎么保证100个线程,结束后,在执行后面的代码? countDownLatch.await(); long endTime = System.currentTimeMillis(); System.out.println(Thread.currentThread().getName() + ",耗时: " + (+endTime - startTime)+", count = " + count); } }
main,耗时: 278, count = 998 main,耗时: 86, count = 995 main,耗时: 90, count = 997 main,耗时: 92, count = 996
可以直接观察到每次统计 Count 的数值没有得到我们想要的 访问量1000,并且访问量每次都不一样
- 分析原因 为什么多线程会出现这种问题
经过分析后加入synchronized 进行尝试
//模拟访问的方法 加入 synchronized
public synchronized static void request() throws InterruptedException {
// 模拟耗时5毫秒
TimeUnit.MICROSECONDS.sleep(5);
count++;
}
结果展示如下
main,耗时: 2017, count = 1000
main,耗时: 2000, count = 1000
count 和我们的预期访问值是一样的,但是注意一点 耗时却是成倍的增长,如果是在我们项目中这样写 绝对会影响我们代码的执行效率
效果不理想继续想处理方案 并且查询为啥会这么慢
最后处理方案
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
public class Demo {
// 总访问量 volatile这个就不用说了吧
volatile static int count = 0;
public static int getCount() {
return count;
}
/**
* 此处进行考虑为何在当前方法加入 synchronized 会这么耗时
* Q:耗时太长的原因是什么呢?
* A: 程序中request() 使用synchronized关键字修饰,保证了并发的情况下,request方法同一时刻只允许一个线程进去
* request加锁相当于串行执行了,count的结果和我们预期的一致,但是耗时太长了
* <p>
* Q: 如何解决耗时长的问题?
* A: count ++ 操作实际上分3步来完成的! (jvm执行引擎)
* 1:获取count的值,记做A: A= count
* 2:将A值+1, 得到B: B = A +1;
* 3: 将B的值赋值给count
* 升级第三步的实现:
* 1: 获取锁
* 2:获取count的最新值 记做LV
* 3:判断LV是否为A,如果相等,则将B的值赋值给count,并返回true,否则返回false
* 4: 释放锁
*/
//模拟访问的方法
public static void request() throws InterruptedException {
// 模拟耗时5毫秒
TimeUnit.MICROSECONDS.sleep(5);
/**
* Q: 分析一下问题出现在哪里?
* A:count ++ 操作实际上分3步来完成的! (jvm执行引擎)
* 1:获取count的值,记做A: A= count
* 2:将A值+1, 得到B: B = A +1;
* 3: 将B的值赋值给count
*
* 如果A,B 俩个线程同时执行count++,他们通知执行上面的第一步,得到的count值是一样的
* 3步执行结束后,count只加1,导致count结果不正确
* Q: 怎么解决结果不正确的问题?
* A: 对count++ 操作的时候,我们让多个线程排队处理 多个线程同事到达request()方法的时候
* 只能允许一个线程进入操作,其他线程等待,等待里面的处理完毕后,下一个线程在进去处理
* 这样操作count++ 就是排队进行的,这样的话结果一定是正确的
*
* Q: 怎么实现排队效果?
* A: Java中synchronized关键字和ReentrantLock 都可以实现对资源加锁,保证并发正确性
* 多线程的情况在就可以保证被锁住的资源被“串行”访问
*/
// count++;
int expectCount; // 表示期望值
//成功返回True 证明成功,不需要继续迭代, 失败则返回False,我们需要重新获取当前值 进行重复操作一次... 所以当前操作我们进行取反操作
// 想要修改的值 期望值(想要修改的值+1)
while (!compareAndSwap((expectCount = getCount()), expectCount + 1)) {
}
}
/**
* compareAndSwap :比较并替换
*
* @param expectCount 期望值 Count
* @param newCount 需要count 赋值的新值
* @return 成功返回True 失败返回False
*/
public static synchronized boolean compareAndSwap(int expectCount, int newCount) {
// 判断期望值是否和当前值expectCount是否一致,如果一致 将 newCount 赋值给count
if (getCount() == expectCount) {
count = newCount;
return true;
}
return false;
}
/**
* 示例: 模拟用户行为(100个用户),每个用户访问10次网站
*/
public static void main(String[] args) throws InterruptedException {
// 开始时间
long startTime = System.currentTimeMillis();
// 100个用户
int threadSize = 100;
//栅栏 保证100个线程全部执行完毕
CountDownLatch countDownLatch = new CountDownLatch(threadSize);
for (int i = 0; i < threadSize; i++) {
new Thread(() -> {
try {
// 模拟 每个用户访问10次网站
for (int y = 0; y < 10; y++) {
request();
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
countDownLatch.countDown();
}
}).start();
}
// 怎么保证100个线程,结束后,在执行后面的代码?
countDownLatch.await();
long endTime = System.currentTimeMillis();
System.out.println(Thread.currentThread().getName() + ",耗时: " + (+endTime - startTime) +
", count = " + count);
}
}
此处结果为
main,耗时: 90, count = 1000
main,耗时: 94, count = 1000
由此可见 在合适地方用合适的锁
总结
在合适的地方,用合适方法去处理这些问题
个人认为大厂为何会问一些源码次实现原理也是同样的想法
个人经验记录,如果有讲解不对的地方请指正 如果转载请说明出处