Java并发编程的艺术(十二)——线程安全

时间:2022-05-03
本文章向大家介绍Java并发编程的艺术(十二)——线程安全,主要内容包括1. 什么是『线程安全』?、2. 线程安全的几种程度、2.2. 相对的线程安全、2.3. 线程对立、3. 实现线程安全的方法、3.2. 非阻塞同步、无同步方案、基本概念、基础应用、原理机制和需要注意的事项等,并结合实例形式分析了其使用技巧,希望通过本文能帮助到大家理解应用这部分内容。

1. 什么是『线程安全』?

如果一个对象构造完成后,调用者无需额外的操作,就可以在多线程环境下随意地使用,并且不发生错误,那么这个对象就是线程安全的。

2. 线程安全的几种程度

线程安全性的前提:对『线程安全性』的讨论必须建立在对象内部存在共享变量这一前提,若对象在多条线程间没有共享数据,那这个对象一定是线程安全的!

2.1. 绝对的线程安全

上述线程安全性的定义即为绝对线程安全的情况,即:一个对象在构造完之后,调用者无需任何额外的操作,就可以在多线程环境下随意使用。 绝对的线程安全是一种理想的状态,若要达到这一状态,往往需要付出巨大的代价。 通常并不需要达到绝对的线程安全。

2.2. 相对的线程安全

我们通常所说的『线程安全』即为『相对的线程安全』,JDK中标注为线程安全的类通常就是『相对的线程安全』,如:Vector、HashTable、Collections.synchronizedXXX。 对于相对线程安全的类,使用它们时一般不需要使用额外的保障措施,但对于一些特定的使用场景,仍然需要额外的操作来保证线程安全,如:

// 读线程
Thread t1 = new Thread( new Runnable(){
    public void run(){
        for(int i=0; i<vector.size(); i++){
            System.out.println( vector.get(i) );
        }
    }
}).start();

// 写线程
Thread t2 = new Thread( new Runnable(){
    public void run(){
        for(int i=0; i<vector.size(); i++){
            vector.remove(i);
        }
    }
}).start();

vector是一个线程安全的容器,它所提供的方法均为同步方法,但上述代码仍然会出现线程安全性问题: 若线程1读了一半的元素后暂停,线程2开始执行,并删除了所有的元素,然后线程1继续执行,此时发生角标越界异常! 修改方案:加上额外的同步

// 读线程
Thread t1 = new Thread( new Runnable(){
    public void run(){
        synchronized( vector ){
            for(int i=0; i<vector.size(); i++){
                System.out.println( vector.get(i) );
            }
        }
    }
}).start();

// 写线程
Thread t2 = new Thread( new Runnable(){
    public void run(){
        synchronized( vector ){
            for(int i=0; i<vector.size(); i++){
                vector.remove(i);
            }
        }
    }
}).start();

2.3. 线程对立

线程对立指的是:不论调用者采用何种同步措施,都无法达到线程安全的目的。 如Thread类的suspend、resume方法就是线程对立的方法。 suspend方法会暂停线程,但它不会释放资源,若resume需要请求到该资源才会被运行的话,系统就会进入死锁状态。

3. 实现线程安全的方法

3.1. 互斥同步

同步指的是同一时刻,只有一条线程操作『共享变量』。

实现同步的方式有很多:互斥访问、CAS操作。 互斥会引起阻塞,当一条线程请求一个已经被另一线程使用的锁时,就会进入阻塞态;而进入阻塞态会涉及上下文切换。因此,使用互斥来实现同步的开销是很大的。

互斥同步(阻塞式同步)是一种『悲观锁』,即它认为总是存在多条线程竞争资源的情况,因此它不管当前是不是真的有多条线程在竞争共享资源,它总是先上锁,然后再处理。

Java中有两种实现互斥同步的方式:synchronized和ReentrantLock。

  1. synchronized
    • 编译器会在synchronized同步块的开始和结束位置加上monitorenter和monitorexit指令;
    • 这两个指令需要一个reference类型的参数来指名要锁定和解锁的对象;
    • 若同步块没有明确指定锁对象,那么就使用当前对象或当前类的Class对象;
    • 它是一把可重入的锁,即:当前线程在已经获得锁的情况下,可以再次获取该锁,因此不会出现当前线程把自己锁死的情况;
  2. ReentrantLock 它也是一把可重入的锁,但比synchronized多如下功能:
    • 等待可中断:若一条线程长时间占用锁不释放,那被阻塞的线程可以选择放弃等待,而去做别的事;这对于要处理长时间的同步块时是很有帮助的。
    • 可实现公平锁:synchronized是一种非公平锁,即:被阻塞的线程竞争锁是随机的;而公平锁是根据被阻塞线程先来后到的顺序给予锁。ReentrantLock默认是非公平锁,可以通过构造函数构造公平锁。
    • 可以绑定多个条件:synchronized可使用wait/notify来实现等待/通知机制,但一个synchronized同步块只能使用一次,若要使用多次,就需要嵌套同步块;但ReentrantLock可以通过newCondition创建多个条件。

synchronized和ReentrantLock如何选择? 优先选择synchronized! JDK1.6已经对synchronized做了很多优化,性能与ReentrantLock相差不大。在条件允许的请况下应优先选择synchronized。

3.2. 非阻塞同步

它是一种『乐观锁』,即它总是认为当前没有线程使用共享资源,因此它不管当前的状态,直接操作共享资源,若发现产生了冲突,那么再采取补偿措施(如:CAS的补偿措施就是不断尝试,直到不发生冲突为止),这种方式线程无需进入阻塞态(挂起态),因此称为『非阻塞同步』。

JUC中各种整形原子类的自增、自减等操作就使用了CAS。

CAS操作过程:CAS操作存在3个值:共享变量V、预期的旧值A、新值B,若V与A相同,则将V更新成B,否则就不更新,继续循环比较,直到更新完成为止。

CAS操作可能引发的问题:ABA问题。 若V一开始的值为A,但在准备赋新值的过程中A变成了B,又变成了A,而CAS操作误认为V没有被改过。

无同步方案

『阻塞式同步』和『非阻塞式同步』都是同一时刻只让一条线程处理共享数据,而下面的方案使得多条线程之间不存在共享数据,从而无需同步。

  1. 可重入代码 如果一块代码段只要输入的值一样其结果就一样的话,这段代码就叫『可重入代码』。 这一类代码天生具有线程安全性,线程随意切换结果都一样。
  2. 线程封闭 线程封闭:把所有涉及共享变量操作的任务都放在一个线程中运行。 这样就不存在多条线程同时处理共享变量了,从而达到了线程安全目的。

WEB服务器采用的就是这种方式,它把每个请求封装在一条线程中处理,从而不存在线程安全性问题。

  1. 不可变对象 如果是共享的基本数据类型变量,只要被final修饰,它就是不可变的; 如果是共享的对象,那就要确保它内部的共享成员变量不会被它的行为所改变。 PS:保证对象内部共享变量不会被改变的方法有很多,最简单粗暴的方式就是将所有共享变量用final修饰。

不可变对象一定是线程安全的。