Java并发基础：共享资源存在的问题

溪午闻璐

已于 2022-01-22 12:29:00 修改

阅读量749

点赞数

分类专栏： Java并发基础文章标签： java 开发语言后端

于 2022-01-21 17:09:59 首次发布

本文链接：https://blog.csdn.net/sssxlxwbwz/article/details/122604269

版权

Java并发基础专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、共享资源带来的问题

由于CPU分时操作的原理，多个线程在操作共享资源时会带来问题：

public class App 
{
    //共享资源
    static int counter = 0;
    public static void main( String[] args ) throws InterruptedException {
        Thread t1 = new Thread(()->{
            for(int i=0;i<5000;i++){
                counter++;
            }
        },"t1");

        Thread t2 = new Thread(()->{
            for(int i=0;i<5000;i++){
                counter--;
            }
        },"t2");

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println("counter结果："+counter);
    }
}

以上代码创建了两个线程t1和t2，他们都会操作共享资源counter,其中t1线程对counter执行5000次自加操作，t2线程对counter执行5000次自减操作。按常理，最终的结果应该是0，但是实际运行时会发现，结果并不一定是0。这就是由CPU分时系统，线程上下文切换所带来的线程安全问题。

1.1 问题分析

以上代码的结果可能是负数、零、正数。之所以会产生不同的结果，是因为Java对静态变量的自增，自减并不是原子操作。

对于i++而言（i为静态变量），实际会产生如下的JVM字节码指令：

getstatic i // 获取静态变量i的值
iconst_1 // 准备常量1
iadd // 自增
putstatic i // 将修改后的值存入静态变量i

对于i--而言（i为静态变量），类似的字节码为：

getstatic i // 获取静态变量i的值
iconst_1 // 准备常量1
isub // 自减
putstatic i // 将修改后的值存入静态变量i

Java的内存模型如下，完成静态变量的自增，自减需要在主存和工作内存中进行数据交换，如下图所示：

上图中，静态变量存储在主内存中，多个线程都可以读取其值。但是，要对i进行计算，是在线程内部进行的。如，线程1读取内存中静态变量的值，然后做i++操作，操作完将i的结果写入主内存。线程2一样，读取主内存i的值，然后做i--操作，操作完成后将结果写入主内存。

如果是单线程按顺序执行以上i++和i--的八行指令码，那么不会出现任何问题，其结果是0。但是，由于cpu分时系统的存在，如果是多线程执行以上8行指令码，就可能存在指令的交错执行，导致以下问题：

出现结果为负数的情况：如下图所示，线程2首先获取到静态变量i的值0，然后准备常数1，然后执行减法操作，此时在线程内部，i的结果为0-1=-1，但是，此时，在线程2将i的结果写入主内存之前，发生了线程之间的上下文切换，线程2保留状态，线程1开始执行。线程1首先从主内存获取到静态变量i的值，值为0（因为此时线程2并没有将i=-1的结果写入主内存中，主内存中的i依然为0）。然后线程1准备常数1，然后再线程内部进行加法，此时线程内部i=1,然后线程1将线程中的i=1写入主内存中，此时主内存中的i的值为1。但是，紧接着又发生线程之间的上下文切换，线程2继续执行，线程2将其再线程内部计算的i的结果-1写入主内存中，因此，主内存中的i的值就由1变成了-1。最终的执行结果就为负数-1。

出现结果为正数的情况：与以上负数情况相似，都是由于线程之间的上下文切换，导致指令交错执行，最终导致结果不符合预期。

1.2 临界区Critical Section

一个程序运行多个线程本身是没有问题的，之所以出现上述的问题，是因为多个线程访问共享资源。分析以上问题，会发现多个线程读取共享资源其实也没有问题，但是在多个线程对共享资源读写操作时发生指令交错，就会出现问题。

一段代码块内如果存在对共享资源的多线程读写操作，称这段代码块为临界区

static int counter = 0;
 
static void increment() 
// 临界区
{    
    counter++;
}
 
static void decrement() 
// 临界区
{    
    counter--;
}

1.3 竞态条件 Race Condition

多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件。

二、解决方案

为了避免临界区的竞态条件发生，有多种手段可以达到目的。

阻塞式的解决方案：synchronized，Lock
非阻塞式的解决方案：原子变量

2.1 synchronized解决方案

synchronized俗称的【对象锁】，它采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】，其它线程再想获取这个【对象锁】时就会阻塞住。这样就能保证拥有锁的线程可以安全的执行临界区内的代码，不用担心线程上下文切换。

synchronized语法：

synchronized(对象) // 线程1，线程2(blocked)
{
临界区
}

public class App 
{
    static int counter = 0;
    static Object lock = new Object();

    public static void main( String[] args ) throws InterruptedException {
        Thread t1 = new Thread(()->{
            for(int i=0;i<5000;i++){
                //使用synchronized加锁
                synchronized (lock) {
                    counter++;
                }
            }
        },"t1");

        Thread t2 = new Thread(()->{
            for(int i=0;i<5000;i++){
                //使用synchronized加锁
                synchronized (lock) {
                    counter--;
                }
            }
        },"t2");

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println("counter结果："+counter);
    }
}

以上代码是对第一节代码的修改，分析以上代码，首先我们创建了lock对象，相当于一个锁。通过synchronized 关键字线程t1和线程t2在执行临界区代码时，必须持有lock对象，否则会阻塞。

当线程t1开始执行counter++操作的时候，他会持有lock对象，此时，若线程2要执行counter--操作，会发现lock锁已经被持有了，线程t2就会阻塞住，直到t1执行完counter++操作，释放了lock对象，线程t2获取到lock对象，才能执行counter--操作。同理，此时线程1若要执行counter++操作，由于得不到lock对象，也会阻塞住，直到线程t2执行完counter--操作，释放lock对象。

可以做这样的类比：

synchronized(对象) 中的对象，可以想象为一个房间（room），有唯一入口（门）房间只能一次进入一人进行计算，线程 t1，t2 想象成两个人
当线程 t1 执行到 synchronized(room) 时就好比 t1 进入了这个房间，并锁住了门拿走了钥匙，在门内执行 count++ 代码
这时候如果 t2 也运行到了 synchronized(room) 时，它发现门被锁住了，只能在门外等待，发生了上下文切换，阻塞住了
这中间即使 t1 的 cpu 时间片不幸用完，被踢出了门外（不要错误理解为锁住了对象就能一直执行下去哦），这时门还是锁住的，t1 仍拿着钥匙，t2 线程还在阻塞状态进不来，只有下次轮到 t1 自己再次获得时间片时才能开门进入
当 t1 执行完 synchronized{} 块内的代码，这时候才会从 obj 房间出来并解开门上的锁，唤醒 t2 线程把钥匙给他。t2 线程这时才可以进入 obj 房间，锁住了门拿上钥匙，执行它的 count--代码

图示如下：

结论：

synchronized实际是利用对象锁保证了临界区内代码的原子性，临界区内的代码对外是不可分割的，不会被线程切换所打断。

以面向对象思路优化上述代码：

把需要保护的共享变量放入一个类中。

public class App 
{
    static Room room = new Room();
    public static void main( String[] args ) throws InterruptedException {
        Thread t1 = new Thread(()->{
            for(int i=0;i<5000;i++){
                room.increment();
            }
        },"t1");
        Thread t2 = new Thread(()->{
            for(int i=0;i<5000;i++){
                room.decrement();
            }
        },"t2");
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println("counter结果："+room.getCounter());
    }
}

class Room{
    private int counter = 0;
    //自加操作
    public void increment(){
        synchronized (this){
            counter++;
        }
    }
    //自减操作
    public void decrement(){
        synchronized (this){
            counter--;
        }
    }
    //获取结果
    public int getCounter(){
        synchronized (this){
            return counter;
        }
    }
}