今天深度学习一下《Java并发编程的艺术》的第1章并发编程的挑战,深入理解Java多线程,看看多线程中的坑。

注意,哈肯的程序员读书笔记并不是抄书,而是将书中精华内容和哈肯的开发经验相结合,给你系统地讲述我对相关知识理解。如果你发现哈肯讲的内容跟书中内容差异很大也不足为奇。

1 多线程的使用场景

在实际的商业系统中,为了提升程序的性能,我们经常会使用到多线程。java多线程也是后台开发岗、Android开发岗招聘面试和笔试时的热门问题。至少,到目前为止我面试过的200多位开发同学时,以及我曾经的几次求职被面试时,多半都会问java多线程并发相关的问题。

2 多线程的缺点

多线程能充分利用多核CPU的特性,但并不意味着多线程就一定比单线程更快,并发编程也存在许多限制和挑战,例如多线程间的上下文切换会有开销、多线程中的数据一致性问题、线程死锁问题、系统资源限制。

2.1 上下文切换的开销

(1)上下文切换的开销

CPU使用时间片算法,将处理时间轮着分配给不同的线程,所以即使是单核CPU也支持多线程,这个时间片非常短,一般是几十毫秒(ms),CPU不停的切换线程执行,让我们感觉多个线程是同时执行的。CPU在切换线程前会保存上一个任务的状态,以便下次切换回这个线程时,可以正常继续执行。我们把线程的状态保存到再加载的过程称为一次上下文切换。

《Java并发编程的艺术》作者写了一段程序,让2个线程同时不断地做变量自增操作,结果证明用2个线程并行甚至比单线程串行更慢一些。通过使用Lmbench3测量上下文切换的时长,发现上述多线程代码中每秒高达1000多次的线程上下文切换。因此不是多线程就一定更快,还要看在线程中干了什么。

(2)如何减少上下文切换

减少上下文切换的方法有:无锁并发编程、CAS算法、减少不必要的线程、使用协程。

  • 无锁并发编程。多线程竞争锁时,会引起上下文切换,通过避免使用锁,可以减少线程的切换,例如将数据用ID分段,不同的线程处理不同段的数据。
  • CAS算法。Java的Atomic包使用CAS算法来更新数据,而不需要加锁。
  • 减少不必要的线程。当任务很少时,尽量减少不必要的线程,避免造成大量线程都处于等待状态。
  • 协程:在单线程里实现多任务的调度,并在单线程里维持多个任务间的切换。

2.2 多线程中的数据一致性问题

(1)线程中访问外部数据的过程

每个线程都有自己的栈,保存线程中创建的局部变量,如果线程中使用到外部的变量,则线程通常会把改外部变量复制一份到线程栈中,当修改完后,再将数据同步回外部。

(2)线程内操作的原子性问题

一个操作会由多个cpu指令构造。例如,创建对象操作大致分为几步:为对象分配内存、成员变量的值初始化、调用构造方法、返回对象的引用;又例如,线程中对一个外部变量的赋值(修改)操作大致分为几步:在当前线程栈创建变量副本,修改变量值,将变量值的修改同步回外部,由于CPU的时间片机制,每个线程获得时间片后,能执行的指令数量是有限的,可能一个操作还未完成,而时间片到了,需要保存上下文并切换到下一个线程。因此,无法保证操作的原子性。

(3)共享数据的可见性问题

观察上述的原子性问题中的例子,线程中对一个外部变量的赋值,可能线程A中刚创建了外部变量的副本,而线程B已经对该外部变量进行了修改,但线程A中是不知道的。即,一个线程对共享数据的修改,不能立刻被其他线程所看见,这就引起了数据一致性的问题。

(4)有序性问题

CPU单个核中,包含多个ALU单元(Arithmetic Logic Unit,即算术逻辑单元),用来执行算数运算和逻辑运算。目前Intel的Haswell架构的CPU(第四代酷睿处理器开始)有4个ALU单元。所以单核CPU在同一时刻是同时执行多个指令的。CPU会把多条指令进行重排序,把没有依赖关系的指令同时放到各ALU中执行。例如3个操作按如下顺序写代码 a=1; b=2; c=a+b; 由于a=1和b=2不存在依赖关系,2个指令可能会被重排序,而c=a+b存在依赖关系,这个指令一定会在前2个指令执行完后再执行,最终一定是c=3。请看如下代码:

public class VolatileTest {
    private int a = 1;
    private boolean status = false;

    public void setStatus() {
        a = 2;
        status = true;
    }
 
    public void test() {
        if (status) {
            int b = a + 1;
            System.out.print(b);
        }
    }
}

(5)如何解决多线程的数据一致性问题

由于以上4点,引发了多线程中数据的一致性问题。解决办法主要有2个:

  • 使用volatile关键字。相对synchronized来说,volatile是一种轻量级的同步机制,有2个作用:一是保证共享变量对所有线程的可见性,即本地副本修改后会强制刷新回外部;二是禁止指令重排序优化。但要注意volatile只对单个变量读/写操作具有原子性,对i++这种复合操作(取值、加1、赋值)是无法保证其原子性的。要保证多线程中i++这种复合操作的原子性,可以改用CAS的实现类,例如用AtomicInteger代替int。
  • 加锁。通过锁来实现同一时间只有1个线程可以访问共享变量。

2.3 线程死锁问题

死锁产生需要同时满足4个条件:

  • 资源的互斥使用,即当资源被一个线程占有时,别的线程不能用。
  • 不可抢占,即资源请的求者不能从使用者手上强制夺取资源,只能等待对方释放。
  • 请求和保持,即在请求其他资源的同时还保持对现有资源的占有。
  • 循环等待,例如线程1持有资源A,请求资源B,而线程2持有资源B,请求资源A。

下面的代码演示对资源的请求和保持,持有res1不释放,同时对res2进行请求:

synchronized (res1) {
   ... // 执行一些操作 
   synchronized (res2) {
      ...
   }
}

解决死锁的方法

只要让产生死锁的4个条件中任何一个不成立,就可以避免死锁。具体做法通常有:

  • 使用Lock接口的tryLock()。
  • 避免一个线程中同时获得多个锁。例如上面代码所示,同时获得res1和res2的锁才能完成执行。
  • 避免一个锁中占用多个资源,即要缩小锁的范围。

Lock接口包含4个给对象加锁的方法,如下所示:

public interface Lock {
     /**阻塞,直到另外一个线程释放锁*/
    void lock();
    
    /**以可被中断的方式获取锁。调用正在等待获得锁的线程的interrupt()方法可中断*/
    void lockInterruptibly() throws InterruptedException;
    
    /**非阻塞,尝试的获取锁,如果获取到则返回true,否则返回false*/
    boolean tryLock();
    /**阻塞,试图获取锁,最多阻塞等待指定时间,如果获取到则返回true,否则返回false*/
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    
    void unlock();
    ...
}
Lock lock = new ReentrantLock();
if(lock.tryLock()) {
    //成功获得锁
    try{
        ...
    } catch(Exception ex){
     
    } finally{
         lock.unlock();   //释放锁
    } 
} else {
    //不能获取锁
    ...
}
class Account {
    private int money;
    synchronized boolean transfer(Account target, int money){
        if (this.money > money) {
            this.money -= money;
            target.money += money;
            return true;
        }
        return false;
    } 
}

理解Java多线程之并发编程

class Account {
    private int money;
    boolean transfer(Account target, int money){
        synchronized(Account.class) {
            if (this.money > money) {
              this.money -= money;
              target.money += money;
              return true;
            }
        }
        return false;
    } 
}

2.4 系统资源限制

系统的资源总是有限的,无节制地创建大量的线程,只会造成大量的线程上下文切换的开销,并不能实际提高程序的效率。按照大家的常规经验,如果是IO密集型,则线程池的核心线程数宜为2N+1;如果是
CPU密集型,则线程池核心线程数宜为N+1;其中N为CPU核数。

原文地址:https://blog.51cto.com/u_13146445/6031966

相关文章: